プライベート エンドポイントが依然としてパブリック アドレスで応答する理由

ノート PC は接続し、トンネルは稼働中と報告し、それでもストレージ アカウントはすべての要求を拒否します。プライベート エンドポイントは存在し、そのサブネットへのルートも存在し、名前はパブリック アドレスで応答するか、まったく解決されません。トンネルに問題がないのは、その名前に対してどのサーバーが応答すべきかをクライアントが一度も知らされていないからです。クエリを外向きにたどれば、ギャップは明らかになります。

クライアントのリゾルバーから始める

トンネルが稼働している間に、クライアントがどのサーバーに問い合わせているかを確認します。ポイント対サイトのプロファイルがそのアドレスを提供し、何も提供しないプロファイルでは、オペレーティング システムがアダプターの既定値にフォールバックします。

パブリック リゾルバーはプライベート ゾーンを認識できないため、インターネットから応答しますが、これはまさに彼らの役目です。したがって最初の確認は、トンネルでもエンドポイントでもなく、使用中のリゾルバーのアドレスです。

応答の実体を読む

サービスの名前を解決し、返ってくるアドレスを読みます。パブリックな応答は、クエリがゾーンを見られないサーバーに到達したことを意味します。応答がない場合は、名前がプライベートにのみ存在し、クライアントが到達できるどこにも保持されていないことを意味します。

この二つの結果は似たアプリケーション エラーを生みますが、担当は異なります。一方はリゾルバーの選択の問題で、もう一方はゾーンのリンク漏れです。

hosts エントリは経路を証明し、そのあと嘘をつく

エンドポイントのアドレスをローカルの hosts ファイルに書くのは、トンネルとサービスのファイアウォールがすでに機能していることを証明する最短の方法です。そのエントリで要求が成功するなら、壊れているのは名前解決だけです。これは一台ごとの変更であり、対象はちょうど一つの名前だけです。

二つ目のアカウント、二つ目のエンドポイント、同僚の役には立ちませんし、エンドポイントが新しいアドレスで作り直されると警告もなく壊れます。

さらに悪いことに、自分のマシンだけが他と違う動きをするため、リゾルバーの不具合が 一週間の調査を生き延びます。経路の確認に使い、そのあと削除して原因を直してください。

ゾーンをリンクし、リゾルバーを配る

二つの条件が同時に成り立つ必要があります。プライベート ゾーンがエンドポイントの存在する仮想ネットワークにリンクされていること、そしてクライアントがそのゾーンを読めるサーバーにクエリを送ることです。DNS Private Resolver の受信エンドポイントは、ネットワーク内にそのようなアドレスを提供し、トンネル経由で届くクエリに応答します。そのアドレスを VPN プロファイルに入れ、クライアントが適用すべきプライベート サフィックスを追加します。

すでにあるオンプレミスのリゾルバーでも、ゾーンを宛先にした条件付きフォワーダーで同じ結果を得られます。

リゾルバーのネットワーク規則は、ルーティングと同じくらい重要です。受信規則が VPN クライアントの範囲を除外していると、クエリは誤った応答を返すのではなくタイムアウトします。そのタイムアウトが、何も問題のないルート テーブルへ人を送り返すのです。

名前、ポート、ID の順に確認する

順番に進めるとは、名前を解決し、応答がプライベートであることを確認し、ポートを開いたうえで認証済みの要求を行うことです。各段階にはそれぞれの担当と、それぞれの失敗の痕跡があります。

プライベートな応答のあとにタイムアウトが続く場合は、ルートかファイアウォールを示します。パブリックな応答はリゾルバーを示します。ID エラーを返す完了済みの接続はサービスの側の問題です。

もう一つ、この一覧に入る失敗があります。クライアント アドレスを許可するサービスのファイアウォールは、再接続後にプールがそのアドレスを別のセッションに渡すと一致しなくなります。クライアントが持っていると思うアドレスではなく、サービスが記録した呼び出し元アドレスを読んでください。両者が食い違うことは、多くの人が思うより頻繁にあります。Azure DNS Private Resolver のガイダンスは、ゾーンのリンクと転送の構成を扱っています。