トンネルは上がっているのに、なぜプライベート名は失敗するのか

接続はどこも正しく見えます。トンネルは上がり、コンソールにはプライベートエンドポイントが表示されていますが、すべての要求が名前解決で失敗します。当然の動きはトンネルを疑うことですが、たいていトンネルは無実です。問い合わせはプライベートゾーンについて何も知らないサーバーに送られています。ルーティングを変えてもその応答は変わりません。問題は誰に聞いたかだからです。

問い合わせはどのリゾルバーに届いたのか？

トンネルを見る前に、各リンクに付いているリゾルバーを探します。Linux はリゾルバーの状態コマンドでリンクごとのサーバーを表示し、macOS は DNS 設定のダンプでスコープ付きリゾルバーを表示します。応答がまだ自宅ルーターから来ているなら、トンネルのリンクは一度も使われていません。

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

ここでは二つの段階が混同されています。リゾルバーのアドレスを押し込むサーバーと、それを有効なリンクに設定するクライアントです。プロファイルにその設定があっても、ログに届いたと出ても、OS は古いサーバーを使い続けることがあります。ログとリンクが報告する内容を比べ、リンクを信頼してください。

クラウドネットワークが本当に応答するアドレスを使う

クラウドネットワークは通常、範囲の基底から二つ先の予約アドレスでプライベート名に応答します。つまり 10.0.0.0 から始まるネットワークは 10.0.0.2 で応答します。プロバイダーによっては、範囲を知らなくても機能するリンクローカルなリゾルバーを公開しており、ネットワークを他の誰かが構築したときに役立ちます。候補のアドレスは誰かに押し込む前に、直接問い合わせてください。リゾルバーでないアドレスは、ファイアウォールによる破棄とまったく同じに見えます。問い合わせが単に応答を一度も受け取らないからです。

直接の問い合わせがネットワーク内からは応答し、トンネル越しには応答しないなら、リゾルバーは正常で、二点間の経路が正常ではありません。その結果、調査はクライアントプロファイルではなく、ルート、転送、アクセス規則へ移ります。

トンネルは名前空間を運ばない

パケットは通過しますが、名前は通過しません。どちらの名前空間が相手側に属するかを各側に伝える必要があり、それはゾーンを持つ人が所有する別個のオブジェクトです。通常の形は、一つの名前空間に対するフォワードを、トンネル経由で到達できるリゾルバーに向けることです。

実際には方向ごとに独自の規則が必要です。ゾーンを持つ側が問い合わせを送り出す側だからです。どちらの方向も問い合わせ元がルーティングされ許可される必要があり、応答する側はインターネットではなくトンネル経由で応答を返さなければなりません。フォワードは狭く保ち、プライベート名前空間だけがリンクに依存するようにします。すべての問い合わせをそこに通すと、トンネルが落ちた瞬間に小さな依存が全停止に変わります。

境界を順にたどる

有効なリンクに設定されたリゾルバー、次にそのリゾルバーへの直接の問い合わせ、次に遠い側からの同じ問い合わせ、最後に同じ名前を使うアプリケーションを試します。各手順は一つの境界を分離するので、失敗すれば調査をやり直すのではなく、どこを見るべきかが分かります。アプリケーションが失敗するのに応答が成功する場合は、DNS ではなく証明書の信頼や API ポリシーを示しています。その障害は現実であり、リゾルバーの変更では直りません。

どの手順が失敗したかを書き留めます。その一行こそ次の人に必要なもので、記録には十秒しかかかりません。

次の人が見つけられる場所に連鎖を残す

押し込んだリゾルバー、転送規則、許可された問い合わせ元、応答するエンドポイントを一か所に記録します。プライベート名が再び失敗したとき、記録を見ればトンネルが移動したのか、リゾルバーのアドレスが変わったのか、規則が狭められたのかが分かります。それがなければ、どの障害もゼロから始まり、同じ三つの推測で終わります。

記録は正確に保てる程度に短くしてください。四行、日付、各部分の所有者の名前です。古い記録はないより悪いものです。間違っているのに権威あるように見えるからです。