ルーター自身のDNSはなぜVPNトンネルを迂回するのか

クライアントの検索はトンネルを辿る一方、ルーター自身の検索はWANから出て行き、一方を律するファイアウォール規則は他方には何の効果もありません。理由はバグではなく、転送された要求とルーターが自ら生成する要求は二つの別個の流れであり、それぞれ構成の異なる部分と照合されるからです。クライアント側の半分だけを取得すると、もう半分が決して使わない経路について自信ありげな答えが得られます。修正は、ルーターのリゾルバーを意図的に向け、その後で二つの経路を別々に検証することです。

パケットキャプチャは実際にどちらの流れのものか

一回の検索には二つのやり取りが含まれます。LANのクライアントがルーターのリゾルバーへクエリを送り、それがLANインターフェース上で転送トラフィックとして届くため、転送パケット向けに書かれたポリシールートやNAT規則が一致する可能性があります。続いてルーターはキャッシュから応答するか、見つからない場合は上流サーバーへ自らのクエリを開きます。

その二番目のクエリはルーター自身を送信元とし、宛先も自分自身であり、プラットフォームは別の構成ブロックからその経路を選びます。どちらのやり取りも同じ名前を運び、どちらも他方の複製ではありません。したがってLAN側で取得したキャプチャは、クライアントのパケットがどこへ行ったかを証明するだけで、外向きのパケットについては何も語りません。

実務的な確認は両側を同時に観察することです。ルーター上でリゾルバーのソケットを一覧し、ローカルで問い合わせ、WANインターフェースをキャプチャします:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

ソケット一覧がloopbackまたはLANアドレスに束縛されたリスナーを示すなら、ルーターは別のホストへ転送するのではなくローカルで応答しています。そのときキャプチャは、結果として生じた上流クエリがトンネルインターフェースから出るのかWANから出るのかを示し、それがポリシールート規則では決して得られなかった答えです。

ポリシールートが二番目のクエリを決して見ない理由

ファイアウォール規則はインターフェース、送信元、宛先、ポートに対して書かれ、装置を通過するパケットについて評価されます。ルーターが生成するクエリは、ローカルプロセスがそれを直接ルーティングテーブルへ渡すため、何も通過しません。ポリシールーティングとNAT したがって転送経路にのみ適用され、規則一式が完全に見えてもルーターのDNSをトンネルの外に残してしまうのはそのためです。

この区別は機能ではなくパケットの経路に由来するため、ファームウェアの書き換えを経ても残ります。装置が自身のために生成するもの、すなわちリゾルバーのクエリ、時刻同期、更新確認、パッケージミラーへのアクセスはすべてローカル発であり、同じ盲点に落ちます。ノートPCからのテストがルーターについて何も証明しないのも同じ理由です。

pfSenseのリゾルバーが自身の上流経路をどこで決めるか

pfSenseはその分離を可視化します。クライアントのトラフィックはポリシーでVPNゲートウェイ経由にできる一方、ファイアウォール自身のトラフィックはLANの規則ではなくリゾルバーの外向き設定に従います。Webインターフェースではその設定はServices > DNS Resolver > Outgoing Network Interfacesの下にあり、その値はリゾルバーが上流クエリに使えるインターフェースの一覧です。

そこでトンネルインターフェースを、しかもそのインターフェースだけを指定することが、ルーター自身の検索をトンネルに従わせる原因です。既定のままにすると、リゾルバーはルーティングテーブルから出口を選び、デュアルWANやVPNのホストではそれがWANであることがよくあります。

他のファームウェアは同じ判断を、送信元アドレスに束縛された上流サーバー一覧、転送のみのモード、文書化されたルートポリシーといった別の名前で公開しています。探すべき設定は、常にローカルで生成されたクエリの出口または送信元を選ぶものです。リゾルバー設定のリファレンス はpfSenseのそのオプションを文書化しており、変更前に読む価値があります。

設定より先に障害時の挙動を選ぶ

トンネルが落ちたとき、何も漏れないように上流クエリを止めることと、既知の経路で承認済みのリゾルバーへ退避することの二つの挙動が弁護できます。どちらも方針であり、既定で得られるものではありません。インターフェース一覧に触れる前に、ネットワークがどちらを必要とするか決めてください。

障害時に閉じるほうが弁護しやすいのですが、トンネルの断をルーター背後のすべての機器にとって名前解決の断に変えてしまいます。退避はオフィスを使い続けられるようにしますが、トンネル外の上流とのやり取りという代償を伴い、それは偶然ではなく意図して許容される必要があります。VPNの外のリゾルバーアドレスを見た次の人は、注記が別段に述べていなければ漏えいと読むため、選択を書き留めてください。その注記こそが、文書化された退避と次四半期のレビューでの説明のつかない発見とを分けます。

二つのケースが判断を難しくします。プライベート名にはトンネルが到達できる内部リゾルバーが必要な場合があり、独自の暗号化DNSを持つブラウザーやアプリはルーターを完全に迂回できるため、設定したリゾルバーが常にそのアプリの使うものとは限りません。

両方の経路を検証し、結果は別々に保つ

ブラウザーでのDNSテストが答えるのは、そのテストの条件下でそのブラウザーがどのリゾルバーを使ったかという狭い問いです。ネットワーク上の機器を棚卸しするものではなく、ルーターが自身のために生成したクエリを見ることもできません。その出力は監査ではなく一つのデータ点として扱ってください。

LANのクライアントから、まず公開名をルーターに尋ね、次に内部ゾーンだけが答えるべきプライベート名を尋ねます。二番目のクエリだけが失敗する場合はトンネルではなく名前転送を示します:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

次にトンネルを落として両方のクエリを繰り返します。拒否応答はリゾルバーが障害時に閉じていることを意味し、成功応答は退避リゾルバーとその使った経路を示します。それを書き留めた注記と、同じ分にWANインターフェースで取得したキャプチャと比較してください。

記録では、クライアントとルーターのやり取り、ルーターと上流のやり取り、そして二番目を決めた構成という形で観察を分けて保ちます。後日のルーティング変更はその二番目のやり取りを警告なしに行使します。VPNエンドポイント以外から届く応答はそれ自体では漏えいではなく、構成がその経路を偶然選んだときにだけ漏えいになります。