Azure VPN ゲートウェイ経由で二つの拠点間のトラフィックをルーティングする
一つの Azure VPN ゲートウェイ上の二つのサイト間接続は拠点間のトラフィックを通過させられますが、両端がプレフィックスを学習し、LAN の戻り経路が存在する場合に限ります。
二つの拠点は、両者の間に直接のトンネルがなくても、Azure VPN ゲートウェイを介してトラフィックを交換できます。各拠点は同じゲートウェイへのサイト間接続を開き、ゲートウェイは学習したプレフィックスを二つの接続間で受け渡します。これを機能させるのは二本目のトンネルではなく、ルートの交換です。拠点 A は拠点 B のプレフィックスを学習し、B は A のプレフィックスを学習する必要があります。それ以降のすべての手順がそのチェックに依存するため、以下のチェックを順番に実行し、最初に失敗したチェックで停止してください。
何かを構成する前の前提条件
この設計がそもそも機能するかどうかは四つの条件で決まります。ゲートウェイはルートベースであること、BGP をサポートする SKU であること、両方の接続で BGP が有効であること、拠点のアドレス空間が重複しないこと、どちらの側も実際のプレフィックスを隠すために NAT に依存しないことが必要です。
ASN は意図的に計画してください。Azure の文書化された既定値は 65515 で、各拠点のルーターには、ゲートウェイともう一方の拠点と衝突しない独自のプライベート ASN が必要です。既存のゲートウェイ構成を確認せずに既定値を再利用すると、後で AS パスが拒否される原因になります。
VNet ピアリングの動作を期待していないことも確認してください。ゲートウェイは構成した二つの接続間でルートを交換しますが、任意のピアリングを推移的にするわけではありません。三つ目のネットワークが両方の拠点に到達する必要がある場合、そのネットワークには独自の接続または独自のルート パスが必要であり、ゲートウェイがトラフィックを配るという前提は使えません。後でサイトを追加するときに人々が立ち返る設計判断なので、最初の変更ウィンドウの前にこの境界を書き留めてください。
この順序で構成する
各手順には観察可能な結果があるため、それが現れるまで次に進まないでください。
- 仮想ネットワーク ゲートウェイで BGP を有効にし、その ASN とピア アドレスを記録します。
- 各拠点について、その拠点の実際のアドレス空間、ASN、BGP ピア アドレスを持つローカル ネットワーク ゲートウェイを作成します。
- 各サイト間接続を作成し、接続自体で BGP を有効にします。
- 拠点のルーターを、想定でゲートウェイのパブリック IKE エンドポイントではなく、Azure が割り当てたゲートウェイ アドレスとピアリングするように構成します。
四番目の手順が、ほとんどの試行が行き詰まる場所です。Azure が報告する BGP ピア アドレスが、拠点のルーターが隣接として使うべきアドレスであり、トンネル図から人々が期待するアドレスとは限りません。
拠点のプレフィックスそのもの、たとえば A から 10.10.0.0/16、B から 10.20.0.0/16 を広告します。欠けている特定のネットワークを覆うために既定ルートや広い集約を広告すると、隙間は後で静かなブラックホールとして戻ってきます。
両端でルート交換を検証する
接続状態はチェックではありません。両方の接続で IPsec が上がっていても、その間をプレフィックスが一つも通過しないことがあります。ゲートウェイの BGP ピアと学習済みルートを読み、もう一方の拠点へのルートが使用可能なパスとして現れることを確認します。
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP テーブルにあるプレフィックスでも、静的ルートやより具体的なプレフィックスに転送の判断を譲ることがあります。受信したルートだけでなく、選択されたルートを確認してください。
LAN 側の戻り経路をたどる
ここが Azure では正しく見えて現地で失敗する部分です。拠点 A のホストがパケットを拠点 A の VPN ルーターに送るのは、そのルーターが既定ゲートウェイである場合、またはホストかそのゲートウェイが B のプレフィックスへのルートを持っている場合だけです。逆方向でも同じことが成り立つ必要があります。
別のコア スイッチが LAN の既定ゲートウェイである場合、そのスイッチには VPN ルーターを指す、もう一方の拠点へのルートが必要です。それがなければ要求は届いても応答はインターネット経路から出てしまい、利用者には接続が開いてから固まるように見えます。
これを直すためにゲートウェイ サブネットのネットワーク セキュリティ グループに頼らないでください。そのサブネットには独自の要件があり、そこに NSG を置くことは拠点側ポリシーのサポートされた代替ではありません。フィルタリングは拠点のファイアウォールとワークロード自体に属し、そこではルールの所有者がレビューできます。それらのルールをサブネットの NSG に移すと、次の障害をデバッグするチームからも見えなくなります。
操作を許可し、拒否されるテストで証明する
学習されたルートは許可ではありません。本当に必要な送信元、宛先、サービスを拠点のファイアウォールとエンドポイント ポリシーで許可し、それ以外は拒否のままにします。
拠点 A の通常のワークロードから拠点 B の実サービスへテストし、応答を確認してから、禁止されたままであるべき操作を試します。VPN アプライアンス自体が生成するトラフィックは別の送信元アドレスを使い、LAN ルーティングの段階を飛ばすことがあるため、ルーターからの ping の成功は見た目より少ないことしか証明しません。
四つの事実、つまり交換したプレフィックス、使用中の ASN、各側の LAN 戻り経路、サービスを許可するポリシーを書き留めて終えます。どれか一つが欠けていると、構成は最初の変更までは機能し、その後は誰も理由を説明できません。