スプリットトンネルはブラウザを除外するが DNS 問い合わせは除外しない

ブラウザはトンネルから除外され、公開 IP のページはその通信が自宅の接続から出ていることを示しているのに、社内 wiki はやはり開かない。名前解決は別の場所へ行き、その別の場所は通常 VPN が設定したリゾルバーである。データ経路とリゾルバー経路は、ほとんどのスプリットトンネル設計で別々の決定だ。除外が壊れていると判断する前に、ブラウザが実際にどちらを使ったかを確認する。

データ経路とリゾルバー経路は分かれる

除外はアプリケーションのパケットをトンネルから外すことであり、データ経路におけるルーティングとファイアウォールの決定だ。名前解決は別の照会で、プロセスがシステムのリゾルバーに問い合わせ、そのリゾルバーがどのサーバーに質問を届けるかを決める。

どちらも意図的に、かつ異なりうる。業務展開では、社内名が他のどこでも解決されないため、社内名前空間を社内リゾルバーに残したまま選ばれた公開ブラウジングをトンネルの外へ送ることがある。混乱しやすいのは逆の場合で、公開サイトが失敗するのは、ブラウザが展開の想定したリゾルバーに一度も問い合わせなかったからだ。経路とリゾルバーを別々に記録すれば、議論の半分は消える。

どのプロセスが問い合わせるかを見つける

ブラウザは、システムのリゾルバー、独自の暗号化 DNS サービス、または OS がネットワークごとに割り当てるリゾルバーを使える。一つ目はプラットフォームの方針に従い、二つ目はその方針を完全に迂回し、三つ目は問い合わせがどのリンクへルーティングされるかに依存する。

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

テストの前に、どのリンクが DNS サーバーを持ち、どの名前空間を主張し、名前ごとの方針が既定を上書きするかという有効な設定を読む。Linux では分割 DNS がルーティングドメインを使い、Windows では名前解決ポリシーテーブルが名前空間に対して同じ役割を果たす。どちらもリークテストのページからは見えない。

どのリゾルバーがどの名前を見るかを決める

何かを変える前に、社内名は社内リゾルバーへ、公開名は方針が許すサービスへ、例外は担当者とともにという意図したマッピングを書く。その一覧がなければ、リークテストの各ラベルは誰も決着できない方針論争になる。

次にブラウザ自身の設定を確認するのは、ブラウザの暗号化 DNS が OS が問い合わせを受け取る前に適用されるからだ。キャプティブポータルを避けるために有効にした利用者は、展開が選んだリゾルバーを静かに上書きしている。それは漏えいではなく設定の決定であり、ブロックリストではなく決定に値する。

テストのラベルを一つ緑にするために、すべての DNS フィールドを書き換えてはいけない。ラベルは一つのプロセスの一つの問い合わせを、ある瞬間について記述したものだ。

問い合わせと接続を別々に検証する

二つの経路を別々に試す。接続テストはデータ経路を示し、リゾルバーテストは誰が名前を受け取ったかを示す。

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

リゾルバーにも明示的に問い合わせ、失敗を経路ではなくサーバーに帰す。そのうえでブラウザを再起動して繰り返すのは、アプリケーションが否定応答をキャッシュし、古い失敗が持続しているように見えるからだ。

承認された変更の後、データ経路と リゾルバーの受け取り手を二つの別の行 として日付とともに記録する。次の再接続で挙動が戻るなら、直すべきはそれを供給するプロファイルであり、ブラウザではない。