Resolver がピアリング先 VNet にあると Azure P2S DNS が失敗する

クライアントは自分の仮想ネットワークには到達できても、ピアリングされたネットワークの名前解決には失敗することがある。ピアリングは双方が認めない限りゲートウェイ トランジットではない。

VM に ping を打てば応答する。名前を尋ねると、クライアントはホストが不明だと言う。Resolver が VPN ゲートウェイを持つネットワークではなく、ピアリングされた仮想ネットワークにあるとき、この二つの結果は想定どおりであり、resolver をどう調べても変わらない。欠けているのは、ピアリングが既定で保留するルーティングの取り決めである。二つの構成は紙の上ではほとんど同じに見え、動くか壊れるかの差は、正しい向きに設定された一対のピアリング スイッチにある。

ノート PC が VNet2 のゲートウェイにトンネルを張り、DNS を提供するドメイン コントローラーが VNet1 に座っている状況を思い描いてほしい。

二つの構成、一つの違い

Resolver をゲートウェイ自身の仮想ネットワーク内に置けば、トンネルが上がった瞬間に名前が解決する。その検索にピアリング設定は一切関与しない。

同じ resolver をピアリングの向こう側へ移すと、クライアントは VM からは相変わらず応答を得るのに、名前は不明のままになる。証明書もトンネルもクライアントも変わっていない。動いたのは resolver の居場所だけである。ピアリングが与えたのはそのアドレスへのルートであり、ゲートウェイがそこへ通信を運ぶ権限ではない。

側面 A: ゲートウェイの所有者側でゲートウェイ トランジットを許可する

ピアリングは二つの仮想ネットワークを結ぶが、その結び付きはゲートウェイ経由で届く通信に対して推移的ではなく、ポイント対サイトの要求はまさにその形で届く。したがって VNet2 のゲートウェイは、設計が許すまで検索を VNet1 へ渡す立場にない。許可は、ゲートウェイを持つネットワークが所有するピアリング上のスイッチである。

VNet2 から VNet1 向きのピアリングで Allow gateway transit を設定する。このプロパティはゲートウェイ リソースではなくピアリング オブジェクトに属するので、ピアリングのブレードで読み、変更する。側面 A はこれで全部である。

側面 B: ピア側でリモート ゲートウェイを使う

もう半分は鏡像である。VNet1 から VNet2 へ戻るピアリングで Use remote gateways を有効にする。同じフラグを両端で、あるいは片端だけで立てると、半分だけ作られた経路と元の症状がそのまま残る。トランジットを許すのは VPN ゲートウェイを持つネットワークだけで、使う側はピアである。

最後に開いたポータルのブレードを信じるのではなく、両方のネットワークで両方のプロパティを読む。

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

二つを並べて見ることが、逆になった設定を捕まえる最短の方法である。ゲートウェイ側で AllowGatewayTransit false を報告するピアリングは、パケット捕捉なしで失敗の全体を説明する。

クライアントがなお受け取るべきもの

ルーティングは必要だが十分ではない。ポイント対サイトのプロファイルは、トランジットが働いた後に応答する DNS アドレスもクライアントへ渡さなければならない。プラットフォームの resolver はそのアドレスではない。仮想ネットワークにリンクされた Azure Private DNS ゾーンには応答するが、自前のディレクトリ サーバーでホストするゾーンには何も返さず、この配備はまさにそちらを使っている。クライアントをそちらへ向けると、公開名は快く解決し、内部ホストは不明のまま残る。

ほかを変える前に、接続中のノート PC から resolver に問い合わせる。

nslookup dc01.corp.example 10.1.0.4

タイムアウトは経路がまだ欠けていると言う。権威ある応答は問題をクライアント側へ押し戻す。多くは決して付加されないサフィックスで、短い名前が公開 resolver へ流れ、そこで快く失敗する。

サイト間側で同じ取り決めを比べる

これはノート PC に固有の話ではない。クライアントをサイト間の支店に置き換えると、両側の要件が戻ってくる。支店はゲートウェイのネットワークへ直接届き、二つ向こうのサービスは依然としてピアリングの後ろにある。

トランジットは両方のピアリングで与える必要があり、それを与えるスイッチはクライアントの種類ではなくピアリングにある。

ゲートウェイを責める前に

Windows はアダプターごとに resolver の一覧を保つので、ゲートウェイを責める前にトンネル インターフェイスが実際に何を受け取ったかを確かめる。

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

否定応答はキャッシュの中でルーティング修正より長く生き残り、古いサフィックス一覧はゾーンを一度もホストしていない場所へ問い合わせを送り続ける。フラッシュし、もう一度尋ね、どのサーバーが応答するかを記録する。

経路が保つかどうかは二つの小さな条件で決まる: アドレス空間が重なってはならない、そして resolver のサブネット上のネットワーク セキュリティ グループがクライアント プールを通さなければならない。クライアント プールはもう一つの送信元範囲にすぎない。VM 側からの有効ルート確認とクライアントからの直接の問い合わせ一回でそれを証明し、ゾーンの問題、サフィックスの問題、フィルターがトランジットの欠落と取り違えられないようにする。

関連記事