【Azure S2S VPN】ローカルネットワークゲートウェイ（LNG）での通信制御と、実は勘違いしやすい「その実体」

AzureでSite-to-Site（S2S） VPNを構築・運用する際、必ず登場するのがローカルネットワークゲートウェイ（LNG）です。

オンプレミス側のプライベートIPレンジを登録するリソースですが、ここに特定のIPだけを設定すると、なぜか通信が制限されます。「ファイアウォール（NSG）でもないのに、なぜ通信制御ができるの？」と疑問に思った方も多いのではないでしょうか。

また、名前に「ローカル」と付いているため、初心者だけでなく経験者でもふと「これってオンプレ側の設定だっけ？」と混乱しがちです。

この記事では、LNGによる通信制御の本質的な仕組み（接続元IPの固定）と、勘違いしやすいLNGの「本当の置き場所」について分かりやすく解説します。

1. LNGでの通信制限は「ブロック」ではなく「ルーティングと契約（SA）」

結論から言うと、LNGに特定のIPだけを登録したときに通信が制限されるのは、アクセスを「禁止（Deny）」しているからではありません。

そこへの道しか存在しない（ルーティングの限定）
許可された接続元以外の通信はVPNトンネルに通さない（暗号化対象外）

という、ネットワークの根本的な仕組みによるものです。ファイアウォール（NSG）のようにパケットの中身を検閲しているのではなく、もっと手前の段階でコントロールされています。

具体的には、LNGの設定は以下の「双方向の視点」で重要な意味を持っています。

① オンプレミスからAzureへ：許可された「接続元」だけを通す（トラフィックセレクター）

オンプレミスからAzureへ向かって通信が来るとき、オンプレミス側は「接続元（送信元）」になります。

特にポリシーベースVPN（またはルートベースで UsePolicyBasedTrafficSelectors を有効にした場合）において、VPNコネクションを確立する際、対向のオンプレミスルーターと「お互いにどのIP（接続元）からどのIP（宛先）への通信を通すか」の契約（SA：セキュリティアソシエーション）を結びます。この契約書における「許可された接続元」を定義するのが、LNGのアドレス空間です。

意味：
LNGに 192.168.20.50/32（特定の1台）だけを登録している場合、登録外の 192.168.20.100 からパケットが届いても、AzureのVPNゲートウェイは「このIPは事前に結んだ契約（SA）に含まれていない（接続元として認められていない）ので、受け付けない」と入り口で厳密に弾きます。

② Azureからオンプレミスへ：「行き先（宛先）」を限定する

逆に、Azureからオンプレミスへ通信する（または戻りパケットを返す）とき、オンプレミス側は「接続先（宛先）」になります。

LNGの「アドレス空間」に登録したIPセグメントは、Azureの仮想ネットワーク（VNet）側に対して、「このIP宛てのパケットは、VPNゲートウェイに放り込んでください」という静的ルートとして自動的に注入されます。

意味：
LNGに特定の1台しか登録されていない場合、Azure側にはそのIP宛てのルートしか作られません。他のIPへ通信しようとしても、Azure側が「行き先（ルート）不明」として、パケットをその場で破棄（ドロップ）します。「そこへの行き方しか教えていない」状態を作ることで、結果的に制限がかかります。

2. 勘違いしがち？LNGは完全に「Azure側」のリソースです

ここまでLNGの役割を見てきましたが、ここで重要な運用上の事実をおさらいしましょう。

名前に「ローカル」と付いているため、オンプレミス側に設置する機器や設定のように思えて混同しやすいですが、LNGは完全に「Azure上」で作成・管理するオブジェクト（リソース）です。

これはAzureから見て、「対向先（ローカルな拠点）の情報を定義したもの」という意味になります。そのため、社内LANの物理ルーターを触る必要はなく、すべてAzureポータルやPowerShell、IaC（TerraformやBicep）などから操作します。

Azure上でS2S VPNを組むときは、以下の3つのリソースをすべてAzure上に作成して紐付ける必要があります。

オンプレミス側（CiscoやYamahaなどの物理ルーター）で行う作業は、このAzure上のLNGに設定した情報（Azure側の窓口IPなど）を基に、「手動でVPN設定を投入する」ことになります。

一度VPNが繋がってしまえば、例えば「通信を許可したいオンプレのIPアドレス空間を増やしたい/減らしたい」という場合も、Azure側の管理画面でLNG（接続元の定義）を書き換えるだけで完結します。

💡 補足：なぜExpressRouteではLNGのような制御ができないのか？

S2S VPNであれば、Azure管理者が「接続元（オンプレミス側）のIP」をLNGでガチガチに固定して定義（静的制御）できますが、ExpressRouteでは同じことができません。

なぜなら、ExpressRouteは「BGP（Border Gateway Protocol）」というプロトコルを使い、ルートベースで動くことが大前提だからです。

S2S（LNG形式）： Azure管理者が手動で接続元のIPをガチガチに固定して定義する（静的）。
ExpressRoute： オンプレのルーターとAzureのルーターが、自動で「うちのネットワークにはこのIP群がありますよ」と情報を動的に交換する（動的）。

ExpressRouteの場合、オンプレミス側から広報されたIPセグメント（例：10.0.0.0/8 など大きな塊）を丸ごと信じてルートテーブルに自動登録してしまいます。S2Sのように「Azure側で手動でLNGを書き換えて、特定の接続元IPだけに絞り込む」という設定項目（インターフェース）自体が構造上存在しません。

そのため、ExpressRoute環境で特定のオンプレミスIPだけに通信を絞りたい場合は、Azure側で「UDR（ユーザー定義ルート）を使ってルート伝播を無効化し、静的ルートで上書きする」か、「オンプレミス側からのBGP広報自体を絞る」といった別のアプローチが必要になります。

まとめ：送信元と宛先で制御する場所を使い分けよう

ハイブリッドネットワークの設計において、どこで通信を絞るかは非常に美しいロジックで成り立っています。

接続元（オンプレミス側の誰が）を絞りたいとき：
Azureの LNG（ローカルネットワークゲートウェイ） のアドレス空間をピンポイントに定義して固定する。
接続先（Azure側のどこの1台へ）を絞りたいとき：
Azure側の NSG（ネットワークセキュリティグループ） で受信規則を絞るか、オンプレ側のルーターで 静的ルート（特定の1台宛てのみ） を書く。

セキュリティグループ（NSG）によるL4ブロックだけに頼るのではなく、「そもそもパケットを届けるルート（道）やVPNの契約（SA）を存在させるかどうか」というネットワークのレイヤーを意識することで、より堅牢で管理しやすいハイブリッドクラウド環境を構築できるようになります。