Azure プライベートエンドポイント について

# はじめに
Azure の プライベートエンドポイント についてまとめました。

:::note info
記事は、以下の構成となっています。
- 前半 = 解説
- 後半 = ストレージアカウントをプライベートエンドポイント経由に構成するための構築手順
:::

本記事を読む前に、類似のサービス（サービスエンドポイント）との違いや、その他の Azure ネットワーク（パブリックインターネット、Microsoft グローバルネットワーク や、Azure PaaS、Azure VM の基本的な通信についてなど）をまとめた記事があります。先に そちらを参照いただき、全体像を掴んでいただくことをおススメします。

https://qiita.com/carol0226/items/c43bcb5def13c7e0ebac

---

# プライベートエンドポイント とは？
プライベートエンドポイントは、以下のような Azure の PaaS サービス または Private Link サービス へのアクセスを、パブリックインターネット経由ではなく、仮想ネットワーク経由で利用できるようにするものです。
① Azure Storage （ストレージアカウント）
② Azure Cosmos DB
③ Azure SQL データベース
④ Private Link サービスを使用する独自のサービス

上記の４項目は、以下の公開情報から抜粋しています。

**公開情報**

https://learn.microsoft.com/ja-jp/azure/private-link/private-endpoint-overview?wt.mc_id=mvp_407731

４項目のうち、①～③ は ストレージ関連です。いずれも、VM や、仮想ネットワークに統合（VNET統合）された App Service、オンプレミス環境 などから プライベート IP を使ってアクセスできるようになります。

④ の「Private Link サービスを使用する独自のサービス」については、自身が作成した Private Link サービスを公開し、利用者の仮想ネットワーク上に作成した プライベートエンドポイント 経由でのアクセスができるように構成できるようです。
つまり、プライベートエンドポイント に対応したサービスを独自に開発することができ、それを 利用者に プライベート IP 経由で 提供できるという事になります。（レアケースかと思うので、この記事では掘り下げません）

これを応用したものとして、Azure が提供するマネージドなサービスのうち、Private Link サービス を使って提供されているサービスも存在します。

**Private Link に対応した Azure の サービス**
私が検証済みの Private Link に対応した Azure の サービスは、以下の２つあります。
AVD は、以下に記事化してあります。

**AVD を プライベートエンドポイント経由で 閉域接続する**
https://qiita.com/carol0226/items/a405fcd075d0d459a672

Azure Monitor Private Link Scope は、２年前に検証したきりですが、ログのインジェストを プライベートエンドポイント経由で LogAnalytics へ送信できるサービスのため、よりセキュアにログを送信できるメリットがあります。これもいずれ、記事化したいと思っています。

**Azure Private Link を使用して、ネットワークを Azure Monitor に接続する**
https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/private-link-security?wt.mc_id=mvp_407731

---

# プライベートエンドポイントを利用するには？
プライベートエンドポイント のリソースを作成するだけでは、利用することができません。
必ず、名前解決と組み合わせて利用する必要があります。

下表のとおり、**対象のネットワーク** （下表の横列）ごとに、**必要なリソース** （下表の縦列）の組み合わせが存在します。

**どの組み合わせでも、名前解決 は必要**
プライベート DNS ゾーンを使うか、Hosts を使って名前解決を行う必要があります。　
プライベート DNS ゾーンは、外部ネットワークから 直接参照することができないため、さらに 追加構成が必要です。

|ネットワークの範囲 ▶<br>▼ 必要なリソース|仮想ネットワーク内|外部ネットワーク|
|:-:|:-:|:-:|
|プライベートエンドポイント|必須|必須|
|プライベート DNS ゾーン<br>を使った名前解決|可（推奨）|**※1<br>要追加構成**|
|Hosts を使った名前解決|可（オプション）|可（オプション）|
|対外接続ネットワーク<br>(VPN or ExpressRoute)|－|必須|

**公開情報**

https://learn.microsoft.com/ja-jp/azure/private-link/private-endpoint-dns?wt.mc_id=mvp_407731

**※1：要追加構成について**
外部ネットワークから、プライベート DNS ゾーン を直接参照することはできません。
そのため、以下のいずれかを 別途 準備する必要があります。
- プライベートリゾルバー
- Windows または Linux の VM による DNS サーバー
- ドメインコントローラー（AD 統合ゾーン）

上記の追加構成の DNS サーバーは、Azure DNS（プライべート DNS ゾーン）へ フォワードする設定が必要です。
外部ネットワークのホストは、上記で追加構成した DNS サーバーを参照するように構成して、間接的に プライべート DNS ゾーン の名前解決ができるようにする必要があります。

**公開情報**

https://learn.microsoft.com/ja-jp/azure/private-link/private-endpoint-dns-integration?wt.mc_id=mvp_407731

**Support Blog**

https://jpaztech.github.io/blog/network/dns-168-63-129-16/

---

# ステップごとの説明
プライベートエンドポイントと、名前解決の関係性を、図を使って 段階的に説明していきます。

## Before
ストレージアカウントは、Azure PaaS のサービスです。
PaaS のサービスへのアクセスは、既定では パブリック IP アドレスが使われる仕組みとなっています。

オンプレミス環境 および、Azure VM が、ストレージアカウント を参照する場合には、下図のように アクセスされています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/5f4383a6-77f4-acf5-1b17-bdfe5f8b5d80.png)

図を見てもらうと判りますが、いずれも まず 名前解決 が行われて、ストレージアカウント のパブリック IP アドレスを取得してから、パブリック IP アドレスに向かって通信が行われています。

ここで、Azure VM からアクセスする際に **送信接続 SNAT** を経由している点に注意してください。
**送信接続 SNAT** を経由する場合は、プライベート IP から、パブリック IP への SNAT 変換が行われます。

そのため、大規模環境で VM の台数が多かったり、AVD の複数セッションの利用によって、ユーザープロファイルなどが利用されていると、非常に多くの ファイル共有アクセスが発生して、SNAT のポート枯渇が発生するリスクが高まります。

加えて、社内のプライベートな通信なのに、パブリック経由で通信のやり取りが行われているのは、気持ち悪い・・・と感じる場合が多くあります（実際には、暗号化されていて、簡単には傍受できませんが・・・）

これらの課題を プライベート エンドポイント を活用すると、解決することができます。

---

## Step 1
プライベート エンドポイント を構成すると、VM からのアクセスが 以下の通信に変わります。

Azure VM の場合の名前解決は、プライベート DNS ゾーン によって行われ、このとき プライベート エンドポイント の IP アドレスが応答されます。そのため、Azure VM は プライベートエンドポイント経由で ストレージアカウントへアクセスするようになり、**送信接続 SNAT** を経由しなくなります。

※このとき、パブリック経由 の通信 には変化はなく、引き続き アクセスが可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/7966d774-fad0-98b2-4b2a-f9c1368822ae.png)

この場合は、Azure VM が 送信接続 SNAT を経由しない・・・という効果しかなく、外部からのアクセスが可能なため、セキュリティ面での効果は限定的です。

:::note info
Azure DNS から 外部 DNS へのフォワードは、プライベートエンドポイント の名前解決の際には使われなくなります。
引き続き、その他の インターネットサイトの名前解決の際には、フォワードが利用されます。
:::

---

## Step 2
続いて、ストレージアカウント の ネットワーク構成で パブリック IP からのアクセスをブロックします。
図は 赤い ✖ の箇所しか変化がありませんが、このように パブリック経由 の通信がブロックされるため、結果として プライベート経由のアクセスしか出来なくなり、セキュリティが高まります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/4b55181b-b09b-8006-9514-c8f9c4a02cb8.png)

---

## Step 3
プライベートエンドポイントは、外部からのアクセスにも対応しています。
S2S や P2S の VPN を構成して、外部から プライベートエンドポイントのある サブネット までのルーティングが確保されていれば、通信が可能になります。

なお、このとき 対外環境に対して、プライベート DNS ゾーン での名前解決が必要になりますが、Azure DNS は 外部から参照することができないため、間に プライベートリゾルバ（または 自前で DNS サーバー）の手配が必要になります。この点が、慣れていないと難しく感じるかもしれない点ですが、段階的に 理解していくと 納得いただけると思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/349966d5-1cd8-8df9-4976-32954a3f82cc.png)

---

# ストレージアカウント を プライベートエンドポイント経由のみに構成する手順
本章では、ストレージアカウントへのアクセスを プライベートエンドポイント だけに絞って、セキュリティを向上させる手順を紹介します。

※ SQL Database / Cosmos DB を構成する場合も、設定の考え方は 同一です。

## 1. パブリック インターネットからのアクセスをブロックする
この設定を行う事で、ストレージアカウントへの パブリック IP アドレス からのアクセスをブロックします。

この後に構成する プライベートエンドポイント 経由のアクセスのみを許可することで、ストレージへのアクセスに対する セキュリティを高めることができます。

以下の２パターンの構成についての違いを説明します。

**(a). 無効**
**(b). 選択した仮想ネットワークと IP アドレスから有効**

:::note warn
**注意**
以下の私の記事を参照して、Azure Virtual Desktop を構成した場合は、**(b)** を選択してください。
**(a)** を選択してしまうと、VM のデプロイ時に カスタムスクリプト を実行できません。
**Azure Virtual Desktop (AVD) マスターへの道**
https://qiita.com/carol0226/items/7318fdd7aff780f5177c
:::

**手順**
Azure Portal で 目的の ストレージアカウント のリソースを開きます。
左ペインから **セキュリティとネットワーク** 配下の **ネットワーク** を開き **ファイアウォールと仮想ネットワーク** のタブ を開きます。

---

### (a). 無効
下図のように構成することで、例外なく すべての パブリック IP アドレスからのアクセスをブロックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/5f5497b8-dcc2-8eb4-77fb-b55b37763233.png)

:::note info
**メリット**
一切の例外が認められないため、セキュリティは万全です。
:::

:::note warn
**注意点**
Azure Portal の 「ストレージブラウザー」からのアクセスもブロックされます。
Azure Backup でのバックアップ実施や、Azure Monitor（診断設定）によって、ストレージにログを保存することなどもブロックされます。
:::

---

### (b). 選択した仮想ネットワークと IP アドレスから有効
　「(a) 無効」の設定に加えて、以下のような 例外を設けることができます。
　　① 特定の パブリック IP アドレスからのアクセスを許可
　　② 信頼された Azure サービスからのアクセスを許可

※**仮想ネットワーク** という設定項目は サービスエンドポイント を許可するための項目です。プライベートエンドポイントとは関係ありません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/666bdbd1-7e38-9611-d53e-3457b03b8686.png)

#### ① 特定の パブリック IP アドレスからのアクセスを許可
図の **① クライアント IP アドレス ('xxxxx') の追加** のチェック欄を ON にすることで、Azure Portal のストレージブラウザ を使って、ストレージ上のデータにアクセスが可能になります。

**アドレス範囲** 欄に、ネットワークアドレス を指定します。
このように構成することで、指定した パブリック IP アドレス からの アクセスも許可されます。

**インターネットの IP 範囲からのアクセスを許可する**
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-network-security?wt.mc_id=mvp_407731#grant-access-from-an-internet-ip-range

#### ② 信頼された Azure サービスからのアクセスを許可
図の **② 信頼されたサービスの一覧にある Azure サービスがこのストレージ アカウントにアクセスすることを許可します。** のチェック欄を ON にします。

このように構成することで、以下の公開情報に記載されている 特定のサービスについて、アクセスが許可されます。

**信頼された Azure サービスにアクセスを許可する**
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-network-security?wt.mc_id=mvp_407731#grant-access-to-trusted-azure-services

:::note info
**メリット**
ある程度のセキュリティを確保しつつ、例外を認めることで 柔軟な運用が可能になります。
:::

:::note warn
**注意**
例外を許可した分だけ、セキュリティ が低下します。
:::

---

## 2. プライベート エンドポイント を構成する
前章までの対応で、パブリック IP アドレス からのアクセスは抑制されています。
引き続き、プライベート IP アドレス 経由のアクセスを 許可するための構成を行います。

プライベート エンドポイント の特長として、このサブネットにアクセス可能な、すべてのネットワーク から利用することができます（同一仮想ネットワーク、ピアリング、VPN、ExpressRoute などで接続された場所からの プライべートアクセスが可能です）

:::note info
**サービスエンドポイント との違い**
サービスエンドポイント の場合は、各サブネット ごとに エンドポイント を作成する必要があるので、その点で 違いがあります。
:::

本章では、以下の公開情報に記載された手順を キャプチャ 付きで紹介しています。

**公開情報**

https://learn.microsoft.com/ja-jp/azure/storage/common/storage-private-endpoints?wt.mc_id=mvp_407731

1. Azure Portal で 目的の ストレージアカウント のリソースを開きます。
　<br>
1. 左ペインから **セキュリティとネットワーク** を開き、**ネットワーク** を選択します。上部のタブから **プライベート エンドポイント接続** を選び、**＋プライベート エンドポイント** を押します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/98dbe2fb-751b-a0d1-dbb3-20b54820c184.png)
　<br>
1. **基本** タブでは、任意の名前（下図では ストレージアカウント名 に "-PE" を付与）を設定します。
ネットワークインタフェース名 は、上記の名前に "-nic" で 自動命名されます。
リソースグループ名 と 地域 は、ストレージアカウント と合わせた値で構成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/86b6294f-988d-10a9-3858-a56a4cd7fbf2.png)
　<br>
1. **リソース** タブでは、**対象サブリソース** で、ストレージの種類 を指定します。
**file** = ファイル共有、**blob** = BLOB、**queue** = キュー、**table** = テーブル
※複数のリソースを許可した場合は、それぞれに プライベート エンドポイント を作成してください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/f956efbe-a301-8748-0e7b-0c1ec4a76dfb.png)
　<br>
1. **仮想ネットワーク** タブでは、プライベート エンドポイント を作成する サブネット を指定します。
このサブネット上に、プライベート エンドポイントが生成され、プライベート IP アドレス が構成されます。
以下の例では、**Subnet2** というサブネット上に プライベート エンドポイント を構成しています。ご自身のサブネットに読み替えてください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/8694d5ca-d8aa-aaa0-cde3-e1e557e26423.png)
　<br>
1. **DNS** タブでは、必ず **プライベート DNS ゾーンと統合する** で **はい** を選択してください。
基本的に、プライベート エンドポイント と、プライベート DNS ゾーンは、セットで利用します。
ここで、プライベート DNS ゾーン を構成することで、ストレージアカウント にアクセスするための DNS レコードが自動的に構成されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/e04db226-5529-016f-55b1-5142796b7809.png)
　<br>
1. **タグ** タブ では、特に指定するものはないため **次：確認および作成** を押して 先に進みます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/2f08c2e3-d7c3-dfb1-2f52-d82d00256987.png)
　<br>
1. **確認および作成** タブでは、設定した項目をチェックして **作成** を押します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/a6b4da5b-4425-63e7-d0c9-bbd9eb55ed26.png)
　<br>
1. デプロイが完了すると、以下の通知が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/bd873242-c3cb-5d7c-3092-7992bd6ea387.png)
　<br>
1. デプロイが完了した際の画面です。**リソースに移動** を押します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/faf979e5-d038-7848-dffb-760545aea3ea.png)
　<br>
1. 作成された プライベート エンドポイント が 以下のように表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/23540364-551c-bcae-8d47-4baec97e4c97.png)
　<br>
1. 以下の画面で 作成された プライベート エンドポイント の プライベート IP を確認できます。 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/da4b9355-e809-17ca-e4a4-b94d65baa3a9.png)
　<br>
1. プライベート DNS ゾーン は、以下のように自動構成されています。
これによって carol0226storage.privatelink.file.core.windows.net が 10.10.20.5 に名前解決されるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/40c8052b-4460-fe5e-7d82-da263793bc6f.png)

---

## 3. 動作確認
### プライベート経由のアクセス許可の確認
プライベート エンドポイント を構成した 仮想ネットワーク 上の VM へ RDP 接続して、以下のコマンドを実行してください。
**nslookup** [ストレージアカウント名]**.**[対象サブリソース]**.core.windows.net**

以下のように、プライベート IP アドレス が応答されれば OK です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/c99eb4a6-46a0-a80c-3f0a-392d0b6d815f.png)

**エクスプローラー** を使って、ファイル共有の確認が可能できます。
FQDN を指定して、アクセスを確認します。
~~~
\\[ストレージアカウント名].file.core.windows.net
~~~

問題無く、ファイル共有 にアクセスできれば OK です。

**ストレージエクスプローラー** を使用して、アクセスを確認する事も出来ます。
ファイル共有以外（BLOB , キュー , テーブル）の場合は、こちらを使いましょう。
以下から、ダウンロードして PC へインストールして利用できます。

https://azure.microsoft.com/ja-jp/products/storage/storage-explorer?wt.mc_id=mvp_407731

以下のように File Shares へのアクセスが確認できます。
BLOB , キュー , テーブル があれば、同様に確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/b376f591-eacb-b698-dcb8-6052234a9491.png)

---

### パブリック経由のアクセス拒否の確認
インターネットに接続された、外部の PC 上で、以下のコマンドを実行してください。
**nslookup** [ストレージアカウント名]**.**[対象サブリソース]**.core.windows.net**

以下のように、パブリック IP アドレス が応答されるハズです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/06105589-8848-6a41-12df-589c22f190a7.png)

**エクスプローラー** を使って、ファイル共有の確認が可能できます。
FQDN を指定して、アクセスを確認します。
~~~
\\[ストレージアカウント名].file.core.windows.net
~~~

以下のように パブリックのポートには到達できずに、エラーが表示されれば OK です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/d465e5c7-f6a8-6d6b-437e-520c5cf5d871.png)

**ストレージエクスプローラー** を使用して、アクセスを確認します。
以下のように FIle Shares を選択すると、エラーが表示されてアクセスできません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/1c526f28-ff4e-6ca5-b00a-9ddb9e570fd6.png)

---

## 4. 外部ネットワークからの プライベート アクセス
### 4-1. 対外接続の構成
３章までの構成が完了していれば、あとは 該当のサブネット へアクセス可能な対外接続（ピアリング、VPN、ExpressRoute など）を構成すれば、接続先からのプライベートアクセスを実現できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/05bbc80b-7c0f-55e0-4e28-555f9b4751fb.png)

ちょっとマニアックですが、以下のように OpenVPN を使って 仮想ネットワーク へ接続し、プライベートエンドポイント を利用することもできます。

https://qiita.com/carol0226/items/7a9160b298b736aa187e

このとき、OpenVPN に接続した際に クライアントの DNS が 次章で構成する DNS サーバー（プライベートIP）を参照するように構成してください。

---

### 4-2. 名前解決の構成
プライベートエンドポイントは、プライベート IP アドレス を提供する（上図の青色線）だけでなく、PaaS サービスへの URL を、その プライベート IP アドレスに名前解決するための Azure プライベート DNS ゾーン（上図の緑色線）とセットで利用するのが一般的です。

Azure VM が プライベートエンドポイントを参照するだけなら、DNS クエリも ① の参照（既定）のままで良い為、簡単に構成できます。

しかし、オンプレミスからの参照の場合は、S2S や P2S などの VPN を構成して、プライベートエンドポイント までのルーティング に加えて、DNS の参照先を ★ の プライベート IP となるように構成する必要があります。

プライベート DNS ゾーン にゾーンが無い DNS クエリ は、外部の DNS にフォワードされて、インターネット上の名前解決が行われます。プライベートエンドポイントだけを構成しても、DNS が未構成だと、パブリック IP アドレスが応答されてしまい、プライベート経由の通信にならないので、注意が必要です。

プライベートエンドポイントの対外接続時には、以下の ① ～ ③ いずれかの対応が必要です。

**① Hosts を使った名前解決**
以下の公開情報を使って、プライベート DNS ゾーンから hosts ファイル用の情報をエクスポートできます。
これを、各 PC の hosts ファイルとして保存することで、DNS サーバーを構築せずに 名前解決 させることができます。

https://learn.microsoft.com/ja-jp/azure/private-link/private-endpoint-export-dns?wt.mc_id=mvp_407731

**② Azure プライベートリゾルバー** は、オンプレミスからの名前解決を Azure プライベート DNS ゾーン へ転送するために用意された仕掛けです。そのため、Azure プライベートリゾルバー をデプロイして、オンプレミスの PC は、この プライベートリゾルバーを 参照する DNS サーバーとして構成すれば OK です。

https://learn.microsoft.com/ja-jp/azure/dns/dns-private-resolver-overview?wt.mc_id=mvp_407731

**③ Azure VM で DNS を用意する**
この方法は、以下のような DNS サーバー を稼働させて、フォワード先として Azure プライベート DNS ゾーン (168.63.129.16) を指定します。このように 自前で DNS サーバー を用意することもできます。
- Windows Server の ドメインコントローラー + AD 統合ゾーン
- Windows Server の 標準プライマリ DNS ゾーン
- Linux の BIND

:::note info
**ドメインコントローラーへのアクセスがある場合**
特に、仮想ネットワーク上に ドメインコントローラー（AD 統合ゾーン）を稼働させていて、オンプレミス側のクライアントがドメイン認証を行う場合は、③ のパターンを採用する必要があります。

Azure 上での ドメインコントローラーの構築は、以下の記事で紹介しています。この手順で構築すれば、結果的に DNS の問い合わせを Azure DNS（プライベート DNS ゾーン）にフォワードされるように構成されます。
https://qiita.com/carol0226/items/084fbbb3f31b646025f4
:::

標準プライマリ DNS や、Linux の BIND を使う場合は、ご自身で Azure DNS へのフォワードを構成してください。

---

### 4-3. 仮想ネットワーク の DNS サーバーの構成変更
Azure VM や VPN ゲートウェイ を 前章で構築した DNS サーバー 経由にするためには、仮想ネットワーク の DNS サーバー の構成で、構築した DNS サーバー のプライベート IP アドレス を指定してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/274d51d3-7b5f-5f77-c2a6-03f1655908a1.png)

Azure VM は、これを行わなくても プライベート DNS ゾーンを参照できますが、構築した DNS サーバーを参照させるためには、この設定が必要です。
VPN ゲートウェイを使って、P2S 接続 を行う場合は、この設定が必須になります。

---

## 5. 高度な制御（オプション）
プライベートエンドポイント に対して、ルーティングテーブルや ネットワークセキュリティグループ (NSG) を適用しても、既定では **無視** されるようになっています。

プライベートエンドポイントへ ルートテーブルや ネットワークセキュリティグループ (NSG) を適用させるようにするには、以下の公開情報の手順を使って、ネットワークポリシー を有効にする必要があります。

**公開情報**

https://learn.microsoft.com/ja-jp/azure/private-link/disable-private-endpoint-network-policy?wt.mc_id=mvp_407731

**ユースケース**
NSG の場合は、簡単です。プライベートエンドポイント への通信を 許可／ブロック させたい場合に使えます。

ルートテーブルの場合は、理解が難しいです。
単純に ルートを割り当てても うまく行きません。ハマりポイントです。
上記の公開情報から抜粋した 以下の 赤線 の箇所が該当します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/53689d0a-7bde-f751-8128-14ea6cadb1ab.png)

VPN ゲートウェイや ER ゲートウェイ から入ってきたトラフィックを、一旦 ファイアウォールや 仮想アプライアンスを経由させてから、プライベートエンドポイント へ向けたい場合に、本設定が必要です。

既定では、外部から プライベートエンドポイント 向けのルーティングが /32 で自動構成されているため、VPN/ER ゲートウェイ からの通信は、ダイレクトに プライベートエンドポイント へ向かってしまいます。

すると、通信の制御のために用意した ファイアウォール を経由しなくなってしまいます。
ルートテーブルで、ネットワーク単位で 仮想アプライアンス宛の ルートを書いていても、ロンゲストマッチで /32 が優先されてしまうからです。

そこで、ルートテーブルで プライベートエンドポイントへの接続時に、仮想アプライアンス 経由となるルートを /32 で、構成することで、目的を果たせるようになります（プライベートエンドポイントが複数ある場合は、１つずつ構成する必要が出てきます）

**手順**
下図を参考に、プライベートエンドポイント が存在している サブネット を開きます。
**サブネットの編集** 画面を 一番下までスクロールすると、設定項目があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/305276d9-8950-2ede-ea60-1dc0f1a77d3a.png)

以下のように 適用させたい機能（NSG or ルートテーブル）にチェックを入れる事で、該当のサブネットのルールが プライベートエンドポイント に適用されるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/30dd8f60-605e-7971-e6c7-8bdec45cc383.png)

ルートテーブルは、以下の通り、プライベートエンドポイント の IP アドレス（赤下線） に対して 必ず **/32**（緑下線）を指定します。 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/272dc2f5-39ec-bf8d-f5fd-ddbed1e45dc8.png)

記事の内容としては以上です。
プライベートエンドポイントについて、理解を深めていただけたならば幸いです。

# 参考情報

https://jpaztech.github.io/blog/network/pe-introduction/

https://jpaztech.github.io/blog/network/pe-troubleshooting/

https://jpaztech.github.io/blog/network/private-dns-zone-faq/