Azure の UDR を VPN ゲートウェイへ：全出口ではなく一つの宛先

外部プレフィックスを一つだけ指定してユーザー定義ルートを追加し、VPN ゲートウェイに向けても、トラフィックは Azure のインターネット経路から出ていきます。あるいは正しく出て、応答が二度と戻ってきません。どちらも同じ誤りから来ます。Azure のネクストホップを設計の全体だと考えることです。ルート テーブルは、Azure 内部でパケットがどの出口を取るかだけを決めます。トンネルを出た後に何が起きるか、応答がどう戻るかは、あなたが作るべき後半です。

ネクストホップはゲートウェイであり、アプライアンスの IP ではない

UDR は一致するプレフィックスをネクストホップの種類に送ります。VirtualNetworkGateway は種類であり、アドレスではありません。ゲートウェイのプライベート IP を VirtualAppliance ルートに貼り付けて、なぜ一致しないのかと悩む人がいますが、この種類は代わりに NIC や内部ロード バランサーを期待します。Microsoft のルーティングのドキュメントも、ゲートウェイのネクストホップを、ゲートウェイが VPN ゲートウェイである仮想ネットワークに限定しています。ExpressRoute、Route Server、Virtual WAN ハブはこのオプションでは扱えません。

ルートを書く前に、仮想ネットワークが実際に何を持っているかを確認します。ハブ経由でルーティングする設計なら、そのルートは編集しているスポークではなく、ハブのルーティング所有者に属します。

何かを変更する前に有効なルートを読む

Azure はシステム ルート、BGP で学習したプレフィックス、UDR を NIC ごとの有効なルート テーブルに統合し、最長一致のプレフィックスがどこから来たかにかかわらず勝ちます。同じプレフィックスでは UDR が BGP ルートに勝ちます。この順序のため、以前の実験で残った古い UDR が、トンネル経由で学習したばかりのプレフィックスを静かに上書きすることがあります。

まず有効なテーブルを見てから、ルートを追加するのか置き換えるのかを決めます。

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

プレフィックスだけでなく、ソース列も読みます。正しいプレフィックスと間違ったソースを持つルートは、どのオブジェクトを編集すべきかを教えてくれ、最初のルートに負ける二本目を追加する無駄を防ぎます。

実際のプレフィックスとサブネットに対してルートを書く

フォーラムの投稿からコピーしたパブリック範囲ではなく、実際に到達しているサービスから取った宛先の本物のプレフィックスを使います。すべての出口を動かす既定ルートを検討する前に、承認済みのサービス一つから始めます。そのうえでルート テーブルをワークロードのサブネットに結び付けます。ゲートウェイ サブネットには独自の要件があり、そこに自分のテーブルを結び付けると、ワークロードを誘導するのではなくゲートウェイが壊れます。

ルートを作成し、次にテーブルをワークロードを収容するサブネットに結び付けます。

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

伝播も重要です。そのテーブルで BGP 伝播を有効にすると、学習したプレフィックスが自分で書いたものと並んで現れ、より具体的な学習済みプレフィックスが広い UDR に勝つことがあります。伝播を無効にするのは、そのサブネットに対して UDR 群を権威にしたいときだけです。

オンプレミス側を仕上げなければ、そこでフローは死ぬ

オンプレミスのゲートウェイは Azure の送信元を受け入れ、宛先へ転送し、アプリケーションを許可する必要があります。その先の経路はインターネット出口でも別のプライベート ホップでもかまいませんが、その判断は Azure のルート テーブルではなく計画に属します。よくある失敗は戻りです。インターネットの宛先はプライベートな Azure の送信元をあなたへ戻すルーティングをしないので、応答は自分の既定ゲートウェイへ行って消えるか、そもそも出ません。

二つの設計がこれを解決しますが、互換ではありません。 出口で送信元を変換する 方法なら、宛先はオンプレミス ネットワークが持つパブリック アドレスに応答します。もう一つは送信元を保持し、トンネル経由で応答が戻るようにルーティングされた戻りの関係を作る方法です。どちらかを選び、アプリケーションがどのアドレスを見るかを書き留めます。

セレクターと許可リストはこれらとは別です。Azure のネクストホップを選んでも VPN のトラフィック セレクターは広がらず、外部サービスの送信元許可リストも変わりません。

宛先が観測した送信元で検証する

要求は別サブネットのジャンプ ホストからではなく実際のワークロードから送り、宛先が観測した送信元アドレスを読みます。その一つの値が、二つの戻り設計のどちらが入っているかを教えてくれます。次に応答経路を確認し、VM への通常の管理トラフィックがまだ通ることを確かめます。誤って追加した既定ルートは、アプリケーションが壊れるよりずっと早く SSH セッションの切断として現れるからです。

選択したプレフィックス経由の通過は、強制トンネリングよりはるかに狭い変更です。狭く保てば、ロールバックはルートを一本削除するだけです。