Wi-Fi は接続済みと言うのに何も読み込めない：古い Mac のリゾルバ

リテラルなアドレスに ping を送れば応答が返る。サイトを名前で開くと何も起きないのに、ネットワークアイコンは接続が正常だと言い張る。VPN に接続したばかりの Mac では、この組み合わせはほぼ常に、名前解決がすでに到達できないサーバーを向いているという意味であり、ネットワークが落ちているわけではない。アドレスは以前のどこかの時点で Wi-Fi サービスに固定され、それ以降だれも外していない。排除法で診断し、そのあと固定された項目を削除する。

修理はフラッシュではなく削除であり、その違いが重要なのは、多くの人が最初に試すコマンドがまったく別のことをするからだ。

「接続済み」はリンクについての表明だ

macOS はネットワークサービスごとにリゾルバ設定を保持する。DHCP から来た値が一つの出所、手入力の値がもう一つ、プロファイルが押し込んだ値やクライアントが書いた値が三つ目だ。固定された値はネットワークが提供するものより優先され、スタックのどこもそれを再検証しない。そのため消えたサーバーは、人が外すかサービスを一から作り直すまでリストに残る。

だからハンドシェイクを終えたトンネルは、すでに誤った方向を向いた名前解決を何も変えない。VPN はリゾルバを追加したが、失敗していたものを点検したわけではない。

名前とパケットを切り分ける

まずリテラルなアドレスでホストに到達する。読み込めればパケットは正常で、原因はリゾルバにある。読み込めなければそこで止め、DNS を変えても混乱した絵に変数が一つ増えるだけだから、ルーティングの問題として扱う。

名前だけが失敗し、対応するアドレスは成功するのが指紋であり、範囲も見るべきだ。すべてが失敗するなら壊れたグローバル項目を指し、トンネル内のホストだけが失敗するなら別の管理者とより狭い修正を指す。

固定されたサーバーを削除する

ネットワーク設定で Wi-Fi サービスの詳細を開き、DNS タブに切り替える。サーバーの行をすべて外し、変更を確認し、そのあと検索ドメインに自分が追加していない値がないか見る。リストを空のままにしてサービスを再接続し、DHCP が渡すアドレスがひとりでに戻ることを確認する。空のリストは、固定された値が問題だったと証明する一時的な状態だ。

古いリリースでは同じパネルが一段深く、詳細ボタンの裏に隠れているが、挙動も結果も同じだ。

パネルではなく状態を読む

scutil --dns | head -40 は macOS が実際に使っているリゾルバを範囲ごとにまとめて表示し、既知の内部名に nslookup を一度かければ応答がそもそも返るかがわかる。二つの出力を比べよう——きれいなパネルなのに古いサーバーがまだ載っているなら、その設定を書いているのは別の主体だ。それは別のバグであり、別の修正が要る。

どちらもきれいに見えるのに名前が失敗し続けるなら、不具合は別の場所へ移っており、もう DNS 設定のデバッグではない。

だれが項目を戻すのか

削除後に戻ってくるサーバーには出所があり、デバイス管理で構成プロファイルを確認しよう。プロファイルは DNS を運ぶことがあり、独自の周期で再評価される。クライアントの環境設定で接続時に DNS を設定する項目を確認し、このマシンでまだ場所に値するかを決める。VPN に本当にプライベートなリゾルバが必要なら、将来のあらゆるネットワークが引き継ぐグローバルなリストに書き込むのではなく、所有するドメインに限定する。

意図したリゾルバと、それが答えるべきドメインを記録する。次のクライアント更新のあと、公開名を一つとプライベート名を一つ検証するのが、設定をたどり直すより速く、マシンがまだ手元にあるうちに退行を捕まえられる。

それ以外はすべて、意図があるように見えて測れるものを何も変えず、同じ壊れた名前解決を次の人に残すだけの保守の芝居にすぎない。