VPNのDNSは本当に使われているのか。ポート53を捕まえて確かめる

VPNクライアントがDNSに何をするのかと多くの人に尋ねると、リゾルバを設定するので問い合わせはトンネルの中を通ると答えるでしょう。プッシュは事実ですが、それが問い合わせになるという前提は違います。プッシュされたオプションと回線上のパケットの間には三つの段階があり、それぞれが独立に失敗し、そのどれもが壊れたDNSサーバーのように見えます。だからこそ、漏えいテストのページと正常に動くブラウザが、同じ機械について同じ瞬間に食い違うことがあるのです。

プッシュされたオプションは問い合わせではない

第一段階は、サーバーが設定を提示することで、たとえばトンネル内のリゾルバを指名するプッシュDNSオプションです。第二段階は、クライアントがその設定をインターフェースに適用することです。第三段階は、アプリケーションが実際にそのアドレスへ問い合わせを送ることです。第二段階で失敗すると、リゾルバ一覧は変わらないままオプションだけが接続ログに残り、第三段階で失敗すると、完全に正しいリゾルバ一覧が使われないままになります。

多くのトラブルシューティングはこの三つを一つにまとめ、VPNサーバーを責めますが、通常、自分の担当分を果たしたと証明できるのはその側だけです。代わりにクライアントの実際のリゾルバ状態を読み、次に問い合わせが一つ出ていくのを観察してください。この二つの観察が、設定と経路とポリシーを切り分け、所要時間は五分ほどです。キャプチャは保存してください、次の担当者は説明ではなく前と後を求めるからです。

インターフェースが実際に何を保持しているかを確認する

Linuxではシステムのリゾルバが素のファイル、NetworkManager、systemd-resolved のいずれかであり、どれがそれを所有するかでプッシュされたサーバーの行き先が決まります。コマンドラインのOpenVPNプロセスはシステムのリゾルバを自分では更新しないため、文書化された統合は up/down スクリプトか、設定の適用方法をすでに知っている接続マネージャーです。両方を動かすのは、競合を効率的に生み出す方法です。

resolvectl status
cat /etc/resolv.conf

Windowsでは一覧はアダプターごとなので、トンネルのアダプターが内部サーバーを保持する一方、物理アダプターがローカルのものを保持し、一部の名前では勝ちます。有効だと思い込んだ側ではなく、両方のアダプターを比較してください。

問い合わせを一つ、機械の外まで追う

両方のインターフェースを同時にキャプチャし、次に内部リゾルバを使うべき名前を一つ解決します。その一対のキャプチャが、どの設定出力にも答えられないことに答えます。

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

物理インターフェースに現れ、トンネルには決して現れない問い合わせは、クライアントが誤ったリゾルバを選んだことを意味します。どちらにも現れない問い合わせは、アプリケーションがキャッシュから答えたか、loopback で待ち受けるスタブに尋ねたか、通信がポート53としてまったく現れない暗号化リゾルバを使ったことを意味します。問い合わせだけでなく応答もキャプチャしてください、トンネルを通って出た問い合わせに公開アドレスからの応答が返るのは、応答がまったく来ないのとは別の障害です。

自分のDNSだけを受け入れるファイアウォール

商用クライアントは時に独自のフィルターチェーンを導入します。文書化された一つのパターンは、クライアント自身のリゾルバへのDNSを許可し、非loopbackインターフェースを出ようとする残りのUDPポート53トラフィックを、利用者が意図的に別経路へ流したものを含めてすべて破棄します。デーモンの問い合わせは痕跡なく消え、それはフィルターではなくリゾルバの故障として読まれます。

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

破棄ルールが例外より先に評価される場合、後から追加したルールには決して到達しないので、先頭に挿入し、宛先を本当に意図するリゾルバに限定してください。

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

その例外はポリシーではなく診断です。ベンダーのルールが意図的なものであれば、サポートされる修理はクライアントにそのリゾルバを許可するよう設定し、判断を記録することです、挿入したルールは次のクライアント更新を生き延びません。

漏えいページが思ったより証明しない理由

漏えいテストのページが示すのは、テスト運営者と話したリゾルバであり、あなたの機械が参照したものではありません。外へ再帰するローカルのフォワーダーは自分の出口アドレスをそのページに載せ、暗号化された問い合わせはページを完全に空白にすることがあります。どちらの結果も誤って読まれ、一方は漏えい、他方は保証とされますが、どちらの読み方も観察から導かれません。

擁護できる証拠は、インターフェース、宛先アドレス、応答、時刻を含むキャプチャです。トンネルが上がる前に一つ、上がった後に一つ取り、次に名前が失敗したときに比べてください。その一対は、障害が名前解決・経路・リゾルバ自身のアクセスポリシーのどれだったかを次の人に伝えます。