VPN 経由の DNS フィルタリングでサイトが読み込めなくなった：答えを読み解く

トンネルが上がっているのに一つの名前だけが失敗し、ブラウザーはそれをネットワーク エラーと呼びますが、本当の原因はリゾルバーが返した DNS 応答です。フィルタリング リゾルバーは一つの名前を保留し、拒否し、あるいは書き換えて、他のすべての問い合わせを動かしたままにできます。問い合わせを運ぶのはトンネルであり、応答を決めるのはリゾルバーです。暗号化の設定に触れる前に、その応答を調べてください。

トンネルは上がっているので、暗号化は容疑者ではない

接続状態が分かるのはパケットが流れているかどうかであり、名前が解決するかどうかではありません。解決とはクライアントが設定されたサーバーへの問い合わせであり、そこのポリシーは一つのドメインにだけ他と違う応答を返せます。ブラウザー側から見ればそうした応答はすべて一般的な失敗に潰れるので、ステータス ライトが証明できることはごくわずかです。

まず三つを記録します：クライアントが使ったリゾルバー、失敗する名前の応答コード、そして動くはずの名前に対する同じ問い合わせです。dig example.com @10.20.0.1 でリゾルバーに直接問い合わせ、ブラウザーのメッセージではなくステータス行を読みます。対照の名前が解決し、失敗する名前がポリシー応答を返すなら、証拠はそろっています。両方とも失敗するなら、フィルターはまだ関与していません。

四つの応答、四つの異なる所有者

フィルタリング リゾルバーが「いいえ」を伝える方法は一つではなく、拒否の形が次の手順の違いを指すため、応答コードを書き留めてください。ブラウザーは四つとも、接続が切れたように聞こえる何かに書き換えてしまうからです。

何かをトンネルのせいにする前に、応答を表と突き合わせます。拒否も保留された名前も、リゾルバーが判断を下したという意味であり、一方で 沈黙は問い合わせが応答を一度も受け取らなかったことを意味します。この違いが、ポリシーの所有者を追うのかネットワーク経路を追うのかを決めます。

二つのブラウザーが二つのポリシーに従うこともある

独自の暗号化リゾルバーを積んだブラウザーは、オペレーティング システムが配るサーバーを使う必要がないため、トンネルが適用するために組まれたポリシーを無視できます。すると同じマシン上の二つのブラウザーが同じホスト名について食い違い、どちらも壊れてはいません。 各アプリケーションがどのリゾルバーに結び付いているかを確認する フィルターを一貫性がないと決めつける前に。

両方のアプリケーションがトンネルのリゾルバーを使い、片方だけが失敗するなら、違いはアプリケーション側にあり、DNS 側ではありません。アプリケーションごとにリゾルバーのアドレスを書き留めてください（ウィンドウを閉じるとその詳細は消えます）。

自分が持つものは変え、持たないものは上へ上げる

次の一手は、向いているリゾルバーを誰が持っているかで決まります。自分で運用しているものは、文書化されたフィルタリング オプションとその例外を確認したうえでその一つの名前を許可できる、読み書き可能な機能です。雇用主やプロバイダーが運用しているものは、ドメイン、正確な応答、時刻を添えたチケットになります。

プライベートな名前が解決せず意図的なポリシーも適用されなくなるため、サイトを無理に開く目的で公開リゾルバーへ差し替えてはいけません。狭い変更は証拠もそのまま残すので、所有者はあなたの報告を自分の記録と照合できます。変更後は、シェルからの問い合わせではなく、元のアプリケーションのテストをやり直します。

ブロック ページは信頼できる証明書ではない

自前の証明書を提示する差し替えページは HTTPS の身元警告を出しますが、リダイレクトはその証明書を有効にはしません。トンネルが上がっているからといってそのままクリックして進まず、警告は別個の信頼の判断として正しく扱ってください。

診断が終わるのは、失敗する名前がポリシー応答を返し、対照の名前が同じリゾルバーを通して通常の応答を返したときです。その時点での修復はポリシーの変更であり、トンネルの変更ではなく、報告書で引用するのは RFC 1035 の応答コードです。二つの名前と応答を一緒に保管することが、この事件のすべてです。