Azure VPN のプレフィックスを追加すると接続が切れる理由

誤った Azure オブジェクトにプレフィックスを追加すると、Connected と報告しながら何も転送しない接続ができあがります。これはこのスタックで最も高くつく種類の誤りです。関係するリソースは三つあり、リモートのアドレス空間を所有するのはそのうち一つだけです。仮想ネットワーク ゲートウェイ、リモート側を記述するローカル ネットワーク ゲートウェイ、そして両者を結ぶ接続です。プレフィックスはローカル ネットワーク ゲートウェイに属し、変更を反映するには接続を作り直す必要があり、ゲートウェイ自体は通常そのままにします。順序は変えられませんし、ポータルにはその一部しか表示されません。

三つのオブジェクトのうち一つがプレフィックスを持つ

仮想ネットワークのアドレス空間は別の問いに答えるものです。Azure の内部に何があるか、です。そこにリモート プレフィックスを追加してもトラフィックはそこへルーティングされず、プラットフォームが自分のものと見なす空間が広がるだけで、実際のリモート範囲と衝突する可能性があります。リモート プレフィックスを持つのはローカル ネットワーク ゲートウェイであり、接続は両方のゲートウェイと事前共有キーを参照します。

もう一つ、覚えておくべき前提があります。 GatewaySubnet は管理対象のゲートウェイ インスタンスをホストし、この名前を正確に持つ必要があり、Basic 以外の SKU では少なくとも /27 であることが求められます。

そのサブネットに他のものは属さず、プレフィックスの変更で触れる理由もありません。ローカル ネットワーク ゲートウェイにないプレフィックスは、接続状態が何と言おうと到達できません。ゲートウェイはトンネルをネゴシエートする際、通知されたプレフィックスだけを提示するからです。だから症状は非対称になります。トンネルは上がり、セキュリティ アソシエーションも正常で、一つのサブネットだけがトラフィック セレクターに現れません。近隣は動いているのに一つのリモート範囲だけ欠けているなら、トンネルを見るのをやめてローカル ネットワーク ゲートウェイを読んでください。

なぜ接続が削除されるのか

接続オブジェクトは、ネゴシエートされた構成をその寿命の間固定します。そのため文書化された手順では、まず接続を削除し、ローカル ネットワーク ゲートウェイを更新し、同じ共有キーで接続を作り直します。プレフィックスだけの変更ではゲートウェイ インスタンスは再構築されないので、停止はゲートウェイの再デプロイではなく接続の解体に収まります。

その削除が停止そのものです。ですから簡単な編集ではなく、開始と終了が決まった計画変更として扱ってください。PowerShell では手順は短くなります。 Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force、次に Set-AzLocalNetworkGateway を新しい -AddressPrefix 配列とともに実行し、次に New-AzVirtualNetworkGatewayConnection を同じ -SharedKey と同じゲートウェイで実行します。キーを再利用することが重要です。リモート側は再構成されませんし、新しいキーはリモート機器の所有者との調整を意味します。その機器を別のチームが運用しているなら、何かを削除する前に時間枠を合意してください。

ゲートウェイ自体を作り直す必要がある場合

この問題の周りに出回る二つ目の答えは、ゲートウェイを再作成してキーを再交換する必要がある、というものです。それは別の操作群には正しい判断です。ゲートウェイの種類や SKU の変更、ポイント対サイトとサイト間の切り替え、あるいは自身の構成が誤っているゲートウェイの修復です。そうした変更はゲートウェイ リソースを実際に変えるので、再構築が本当に必要になります。

ポイント対サイト用に作成されたゲートウェイに、サイト間接続をそのまま与えることはできません。ポイント対サイト構成を削除してゲートウェイを再作成する必要があり、その結果として新しい共有キーと新しいクライアント パッケージも生成されます。

ポイント対サイト パッケージは有効期限があるため、別途の注意が必要です。ポータルが生成するファイルは寿命が短いので、実務的には一度ダウンロードしてクライアント証明書と一緒に配布するのがよく、クリックする頃には死んでいるポータルのリンクを利用者に送るべきではありません。プレフィックスの話にはどれも当てはまりません。二つの手順を分けておくことがすべての規律です。プレフィックスは接続レベルの変更であり、ゲートウェイのプロパティはゲートウェイ レベルの変更です。

ポータルのバッジではなく状態を読む

ポータルのバッジではなく、リソースから状態を読んでください。 Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 は ConnectionStatus を入力バイトと出力バイトのカウンターとともに返します。接続されているのに何も運んでいないトンネルと、一度も確立しなかったトンネルを分けるのはこのカウンターです。

転送の途中で増加を止めるカウンターは 認証ではなく経路を示します。まったく動かないカウンターはプレフィックス セットか共有キーを示します。

タイマーは、VPN のせいにされがちな切断の一種を説明します。Azure のロード バランサーは、構成されたタイムアウトの後にアイドル フローを閉じます。これらのメモを書いた時点での既定値は四分で、上方向に構成できます。そのため keepalive のない VM 上の OpenVPN サーバーは、他がすべて正常に見えても数分おきに落ちることがあります。プラットフォームが循環的に再起動するゲートウェイも VNet から Web App への接続を中断することがあります。そしてその失敗はクライアント構成ではなくプラットフォーム側にあります。見分け方は、切断が一定の間隔に従うのか、あなたが行った変更に従うのかです。

三つのオブジェクトとその値を一つの記録に保ってください。仮想ネットワークのアドレス空間、ローカル ネットワーク ゲートウェイのプレフィックス一覧、接続の共有キーへの参照です。 サイト間の PowerShell の記事 にはローカル ネットワーク ゲートウェイのコマンドと、その正しい順序が記載されています。プレフィックスの変更を記憶と照らし合わせることは、動いているトンネルを二回作り直す方法です。

その後、変更した順に確認します。ローカル ネットワーク ゲートウェイが新しいプレフィックス一覧を示し、接続が Connected に戻り、新しい範囲のホストにトラフィックを送るとカウンターが動きます。最初の二つが通るのに三番目が失敗するなら、リモート側が新しいトラフィック セレクターを受け入れておらず、リモート機器に対応するフェーズ 2 のエントリが必要です。それはトンネルの反対端との会話であり、Azure での別の変更ではありません。