NVA なしで ExpressRoute 上の Azure プライベート IP VPN

「ExpressRoute のプライベート ピアリング経由のトラフィックを暗号化するには、ネットワーク仮想アプライアンスが必要だ」というのは誤解です。必要ありません。Azure は、トンネルの終端点が回線経由で運ばれるプライベートな RFC1918 アドレスである Site-to-Site VPN Gateway をサポートしており、アプライアンスは構造上必須ではなく任意です。この誤解が隠しているのは、実際に問題になる部分です。プライベート エンドポイントを二つのオブジェクトではなく一つだけ有効にすること、そして直接ピアリングのルートが暗号化された経路に黙って勝つことです。

誤解はどこから来たか

この主張には由緒があります。長年、プライベート ピアリング経由の IPsec の実用的なレシピは NVA でした。管理されたゲートウェイがパブリック エンドポイントしか公開していなかったからです。それは変わりましたが、変わる前に書かれた回答が、日付を誰も確認しないスレッドで今も引用されています。訂正は限定的です。プライベート アドレスの VPN ゲートウェイは存在し、変わるのは終端点であって、その周りのルーティング ロジックではありません。

これらのどれも NVA を引退させません。引退するのは「アプライアンスが要件への唯一の道だ」という前提です。

両方のレベルでプライベート エンドポイントを有効にする

VPN ゲートウェイを収容する VNet にリンクされた、動作中の ExpressRoute プライベート ピアリング接続から始めます。オンプレミス側は、その回線経由で該当するプライベート アドレスにすでに到達できている必要があります。トンネルはそれらのアドレスをトランスポートとして使うからです。次にゲートウェイの前提条件です。プライベート IP の VPN に関する Microsoft の手順では、Standard パブリック IP リソース上に構築されたゲートウェイが必要です。プライベートなトンネル アドレス指定はこの要件をなくしません。「プライベート」とは「どこにもパブリック IP がない」という意味だと考える人を驚かせます。

次に、両方の場所でフラグを有効にします。ゲートウェイ構成にはプライベート IP 用のスイッチがあり、個々の Site-to-Site 接続には、その接続でプライベート アドレスを使わせる二つ目のスイッチがあります。片方だけ設定するのが最も多い不完全な構成です。トンネルは確立しないか、誤った終端点に確立します。

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

プロパティ名は、インストールされている CLI のバージョンで確認してください。ポータルのラベルと CLI のプロパティは、常に同じ表現とは限りません。アクティブ-アクティブ ゲートウェイは二つのプライベート トンネル アドレスを公開し、その冗長性を意味あるものにしたいなら、オンプレミス機器で両方のピアを構成する必要があります。このプライベート アドレスのトンネルを立ち上げるだけなら BGP は必須ではありませんが、通常はプレフィックスを配布する方法の一部です。

二つ目の誤解: 確立したトンネルはトラフィックを暗号化する

いまやアプリケーション ネットワークへは二つの経路が到達します。直接のプライベート ピアリング経路と、VPN を経由する経路です。どちらも機能します。この IPsec レイヤーを適用するのは一方だけです。Microsoft は、同じプレフィックスが ExpressRoute と VPN の両方でアドバタイズされると、Azure は直接の ExpressRoute 経路を優先すると文書化しています。したがって、健全なトンネルと健全なカウンターは、アプリケーションのパケットがどこへ行ったかを何も証明しません。

文書化されている誘導方法は、ExpressRoute 側の包含範囲と VPN 側のより具体的な保護範囲、または二つの経路で重複しないプレフィックスです。例として、プライベート ピアリングが 10.40.0.0/16 を運び、VPN が 10.40.12.0/24 をアドバタイズできます。より具体的なプレフィックスが勝ち、範囲の残りは直接のままです。

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

オンプレミスの方向でも同じ確認を行います。送信トラフィックがどの方向へ出るかは、ルーターの優先順位が決めるからです。そしてトンネル自体のトランスポートは ExpressRoute の経路上に保ちます。ゲートウェイのプライベート エンドポイントをトンネル内に引き込むルートは、トンネルを自分自身に依存させます。

トンネルが落ちたときに何が起きるかを決める

トンネルが落ちると、より具体的な VPN ルートは消え、より広い直接ルートは残ります。するとトラフィックは暗号化されずに流れ、すべてが健全に見えます。暗号化を保証するために存在する要件にとって、これは最悪の障害モードです。要件がそのフォールバックを禁じているなら、トンネルの可用性に頼るのではなく、ルーティングとアクセス ポリシーで明示する必要があります。

どのプレフィックスが直接到達可能なままでよいか、どれが暗号化された経路がないときに止まるべきかを書き留めます。次に、許可されたケースを実トラフィックでテストし、接続カウンターを比較します。ルート テーブルだけでは、暗号化の要件がまだ満たされているかは分からないからです。

この枠組みは、終端点がプライベートだからという理由で購入するのではなく、複数のトンネル、スループット、ベンダー検査といった実際の機能で NVA を評価することも可能にします。