Pritunl のプライベート DNS が失敗する？狭いリゾルバールートを追加する

プライベート名は社内ネットワークでは全員が解決でき、VPN では全員がタイムアウトします。リゾルバーはゲートウェイに応答し、そこへのルートは存在するのに、クエリは依然として応答をまったく受け取りません。足りないのは別のパブリックリゾルバーでも広いルートでもありません。プライベート DNS サーバーが応答を許す送信元アドレスです。

リゾルバーがクライアントプールを拒否していることを確認する

まず、障害が到達性ではなく送信元の問題であることを証明します。接続中のクライアントからプライベートリゾルバーへ直接クエリを送り、リクエストがタイムアウトするのか拒否として返るのかを観察します。dig @10.40.0.53 intranet.example.net +time=2 +tries=1 がタイムアウトし、同じクエリがゲートウェイからは成功する場合、リゾルバー上のアクセス ポリシーを示しています。SERVFAIL の応答はまったく別の場所、通常はゾーンか上流のフォワーダーを示します。

テスト前にクライアントのアドレスを記録します。クライアント上の ip -4 addr show tun0、またはコンソールに表示されるリースが、リゾルバーがどのプールを見ているかを教えてくれます。

次に、経路がそもそも存在することを確認します。リゾルバーのアドレスをトンネルへ送るルートは前提条件であり、修正ではありません。パケットが届かなければ、送信元ポリシーは参照されません。クライアント上で ip route get 10.40.0.53 を使って確認します。

すべてを変換するのではなく、ホストルートを 一つ追加する

Pritunl のプライベート DNS ガイダンスは狭い対処法を説明しています。リゾルバーアドレスに対する NAT を有効にした /32 ルートを作り、そのアドレスをクライアントの DNS サーバーとして選択します。ルートは DNS トラフィックについてのみ、リゾルバーが見る送信元を変えます。アプリケーショントラフィックは、それ用に選んだ送信元保持の設計を保ちます。

既存のルートに重複がないか確認したうえで、サーバーが対応するルート所有者を通して設定します。上の例では宛先は NAT を有効にした 10.40.0.53/32 で、クライアントプールは 10.90.0.0/24 のままです。一つのサービスを直すためにプライベート範囲全体を変換しないでください。クライアントの実アドレスに依存する下流のポリシーはすべて、代わりにゲートウェイを見るようになります。テスト検索の間にクエリログを見て、リゾルバーが実際に受け取るアドレスを確認します。ホストルートだけでは、変換や許可について何も証明できません。

リゾルバーは依然として変換された送信元を UDP と TCP で許可する必要があり、その応答が戻れなければなりません。送信元を変えても、存在しないゾーンやレコードを作ることはできません。

クエリを送るのはサーバーかクライアントかを決める

Pritunl は VPN Client DNS Mapping に関連する DNS プロキシの構成も文書化しており、そこではサーバーがクライアントの代わりに上流クエリを転送します。そのモデルでは上流の送信元はサーバー自身のネットワークコンテキストに属し、クライアント側の例外は誤った修正です。

何かを追加する前に、どのモデルが有効かを特定します。三つの重複する修復、プロキシ、クライアント側のリゾルバー上書き、手動の NAT スクリプトは通常、誰も次を確定していないことを意味します：どのコンポーネントがクエリを送るべきか。bootstrap も確認してください。プライベート専用リゾルバーだけが、トンネルが存在する前にエンドポイントを見つける唯一の方法であってはなりませんし、恒久的なリゾルバーの変更が接続より長く残るべきでもありません。

パブリックな Web ページではなく、プライベートな検索をテストする

変更を適用して再接続したら、クライアントの有効なリゾルバー設定を確認し、次にプライベートゾーンにしか存在しないと分かっている名前を解決します。サーバーを明示しない dig intranet.example.net は、クライアントが実際に何を使っているかを示します。続けて、その検索が返したアドレスへリクエストを送ります。解決とサービスへのアクセスは別の手順だからです。DNS-over-HTTPS で公開サイトを読み込むブラウザーは、オペレーティングシステムのプライベートリゾルバーの経路について何も証明しません。パブリックなセカンダリリゾルバーも、内部ゾーンの権威ではありません。

リゾルバーアドレス、/32 ルート、クライアントの DNS 設定をまとめてサーバーのメモに記録します。その設定の半分だけを復元すると、元の障害が再現します。

最後に、DNS が成功した後もトンネルがアプリケーションの宛先へルーティングしていることを確認します。ルート、サービスへのアクセス、認証は名前解決とは独立したままであり、動作する検索はスループットについて何も語りません。プライベートページが遅いが解決するなら、リゾルバーは役目を果たし、問題は経路へ移っています。