Azure VPN の NAT では重複する VNet アドレスは解決しない
同じプライベート範囲を持つ二つの VNet は、NAT があるという理由だけでは接続されません。まず接続の種類を確認し、その後で採番し直すか、変換用の別名を自分で所有してください。
両方の VNet が 10.40.1.0/24 を使っており、トンネルは確立するのに何も動きません。VPN ゲートウェイをもう一台追加しても変わらず、ルート メトリックを下げても変わらないのは、問題が経路選択ではないからです。同じプライベート アドレスに応答するワークロードが二つあると、すべてのパケットは曖昧な宛先と検証できない戻り経路を抱えます。変換を計画する前に、実際にどの接続の種類を作ったのかを確認してください。その一つの選択が、Azure の NAT 機能が使えるかどうかを決めます。
症状が実際に伝えていること
VNet A のホストが 10.40.1.10 に送信すると、ルーティング テーブルはそれをどこかへ向けることしかできません。VNet B にも 10.40.1.10 がある場合、そのアドレスは経路が区別できる宛先ではなく、所有者が二人いる一つのアドレスです。
よく導入される二台目のゲートウェイは役に立ちません。別のトンネルを与えるだけで別のアドレスは与えず、重複した範囲はトンネルの中でそのまま運ばれます。さらに、一貫して保つべき構成が二倍になります。できないのは、一つのアドレスに二人のホストという意味を持たせることです。
VPN ピアのパブリック アドレスを変えても何も起きません。それらのアドレスは トンネルの端点を識別するものであり、衝突はその内部で運ばれるプライベート範囲にあります。
NAT が使えるかどうかは接続の種類で決まる
Azure VPN Gateway には NAT 機能が確かにあり、特定のゲートウェイ SKU におけるルートベース IPsec の拠点間接続について文書化されています。同じ文書が VNet-to-VNet とポイント対サイト接続を除外しているため、この機能はどのゲートウェイ関係にも現れるチェックボックスではありません。
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
ネイティブの VNet-to-VNet は、そもそも VNet とローカル ネットワークの範囲が重複しないことを要求しており、これは除外と整合します。同じ理由で、VNet ピアリングも重複の回避策にはなりません。
ネイティブの種類と混同されがちなサポート対象の代替手段があります。もう一方の VNet をローカル ネットワークとしてモデル化し、サイト間接続として接続する方法です。これは別のリソースであり別の設計なので、名前を変えた接続は単なる改名ではなく、検証すべき変更として扱ってください。
採番し直すか、別名を所有する何かで変換する
両方の VNet が自分のものであれば、計画的な採番し直しと変換の継続コストを比較してください。採番し直しはアプリケーション構成、DNS レコード、セキュリティ規則、既存のすべての接続に触れますが、その後は普通に読めるネットワークが残ります。一度に一つのサブネットずつ行い、DNS の変更を最後にします。半分だけ採番し直した範囲はどちらの選択肢より悪い状態です。次にテーブルを読む人には、両方のプレフィックスが正規に見えてしまうからです。
採番し直しが現実的でない場合は、別名に実際の所有者がいる変換設計を使ってください。VNet A の呼び出し元は VNet B の 10.40.1.10 に 10.140.1.10 として到達するかもしれませんが、その別名には変換する装置、そこへの経路、応答に対する一致した振る舞いが必要です。DNS に追加しただけのアドレスは変換ではありません。
両方の範囲を両方向で記録します。呼び出し元が何をダイヤルするか、宛先が送信元として何を見るか、どちら側が開始できるかです。Azure 自身の NAT 規則には SNAT マッピングの逆変換が含まれるため、対応する DNAT 規則を手で書くことはありませんが、その利便性はこの機能が対応する接続の種類で止まります。
うまくいかないこと
ユーザー定義ルートやルート メトリックは、欠けているアドレスの区別を作り出せません。どちらも依然として曖昧な宛先に対して動作し、パケットはテーブルが優先する次のホップに届きます。
重複した範囲をより具体的なプレフィックスとしてルート テーブルに追加しても、曖昧さが一歩移動するだけです。さらに、応答元が二つある逆方向を壊しがちです。
双方向のトラフィックで設計を受け入れる
トンネルの状態ではなく、各側からの新たな許可された操作で設計を証明してください。接続された IPsec トンネルはピアが暗号について合意していることを示すだけで、宛先が区別できるようになったかは何も語りません。
次に拒否される経路を実行します。到達できないままであるべきアドレスと、ポリシーが遮断すべきサービスです。どちらも成功してしまうなら、変換は設計の意図より広すぎます。
後からこの構成を説明する事実で締めくくります。元の範囲、提示する範囲、変換する装置、どちらの側が開始できるかという方向です。どれかが欠けていると、次のエンジニアは二人のホストが同じ名前を共有し、なぜ一方が応答するのか誰も覚えていないネットワークを引き継ぐことになります。