- 症状: Wi-FiのDNS設定を空にしても、VPN(Tunnelblick)に接続していないとネットに繋がらない。VPN接続を試みる（失敗しても）と何故か直る。
- 原因: 過去のVPNセッションが正常終了せず、VPN用のDNS設定が macOS の SystemConfiguration の Setup（恒久設定）層 に残留していた。Wi-FiパネルのGUIから削除してもこの層までは反映されなかった。
-
対処法:
scutilコマンドで残留したDNS設定を直接削除する。
環境
- macOS
- VPNクライアント: Tunnelblick（OpenVPN）
- Wi-Fi接続（en0）
症状
ある日、Wi-FiのDNS設定（システム設定 → Wi-Fi → 詳細 → TCP/IP・DNS）を手動でいじった後から、以下の現象が発生した。
- VPNに接続していない状態だと、名前解決ができずネットに繋がらない（
ping 8.8.8.8のようなIP直打ちは通るが、ping google.comのようなドメイン名は通らない） - VPN(Tunnelblick)の接続ボタンを押すと、たとえ接続が失敗（タイムアウトなど）してもネットが復旧する
- Wi-FiのDNSサーバー欄を手動設定から空欄に戻しても症状は変わらなかった
一見するとWi-Fi側のDNS手動設定が悪さをしているように見えるが、実際にはその設定を消しても直らない、というのがポイントだった。
切り分けの手順
1. DHCPが正しく機能しているか確認
ipconfig getpacket en0
domain_name_server にルーターのIP（例: 192.168.x.x）が正しく入っており、DHCP自体は正常だった。
2. IP直打ちと名前解決の切り分け
ping 192.168.x.x # ローカルゲートウェイ
ping 8.8.8.8 # 外部IP直打ち
ping google.com # 外部ドメイン名
前者2つは通るが、ping google.com だけが通らない → 経路の問題ではなく、DNS(名前解決)だけの問題 と判明。
3. 実際に使われているDNS設定を確認
scutil --dns
出力の resolver #1 に、見覚えのない設定が残っていた。
resolver #1
search domain[0] : openvpn
nameserver[0] : 10.x.x.x # ← VPN内部専用DNS(例)
nameserver[1] : 10.x.x.x # ← VPN内部専用DNS(例)
if_index : 11 (en0)
search domain: openvpn という検索ドメインと、VPN内部でしか到達できないプライベートIPのDNSサーバーが、Wi-Fi(en0)のDNSとして直接設定されていた。
これがVPN未接続時に名前解決が全滅する原因。VPN接続を試みるとTunnelblickがルートを一時的に張るため、たまたまこの内部DNSに到達できるようになり「直ったように見えていた」だけだった。
4. Wi-Fiパネルから該当DNSを削除しても直らない理由を特定
Wi-Fiパネルの DNSサーバー欄から該当IPを削除しても、scutil --dns の出力からこの設定が消えなかった。
これは、GUIが参照・書き込みする層とは別に、SystemConfigurationの Setup: 階層（恒久設定）に同じ設定が別途残っていたため。おそらく過去にTunnelblickでのVPN接続が正常終了せず（接続不安定でクラッシュ的に切断されたなど）、down（切断）スクリプトによるクリーンアップが正しく走らず、この設定だけが取り残されてしまったと考えられる。
原因の特定（scutil対話モードで直接確認）
sudo scutil
対話モードに入り、まず全体のキー一覧を確認する。
> list
Wi-Fi(en0)に対応するService IDを探し（Setup:/Network/Service/<UUID>/Interface などから特定できる）、DNSキーの中身を確認する。
> show State:/Network/Service/<UUID>/DNS
<dictionary> {
ServerAddresses : <array> {
0 : 192.168.x.x
}
}
State（実行時の実体）側は正常だった。しかし、恒久設定側を見ると：
> show Setup:/Network/Service/<UUID>/DNS
<dictionary> {
DomainName : openvpn
SearchDomains : <array> {
0 : openvpn
}
ServerAddresses : <array> {
0 : 10.x.x.x
1 : 10.x.x.x
}
}
ここにopenvpn関連の設定がそのまま残留していた。 これがOS起動時やネットワーク再構成のたびに読み込まれ、Wi-FiのDNSとして適用されていたため、GUIから消してもすぐに（あるいは実際には最初から）反映されていなかった。
対処法
scutilの対話モードのまま、該当キーを削除する。
> remove Setup:/Network/Service/<UUID>/DNS
念のため確認：
> show Setup:/Network/Service/<UUID>/DNS
No such key
quitで抜けて、最終確認。
scutil --dns
resolver #1
nameserver[0] : 192.168.x.x
if_index : 11 (en0)
openvpn関連の設定が消え、DHCPで配布された正常なDNSのみになっていることを確認。この状態でVPN未接続でもping google.comが正常に通るようになった。
まとめ
| 項目 | 内容 |
|---|---|
| 症状 | VPN未接続時に名前解決できずネットに繋がらない。VPN接続を試みると（失敗しても）直る |
| 見た目の疑わしい原因 | Wi-FiパネルのDNS手動設定 |
| 真の原因 | Tunnelblickが書き込んだVPN内部DNS設定が、SystemConfigurationのSetup:階層に残留し、Wi-FiパネルのGUI操作では消えなかった |
| 対処法 |
sudo scutil の対話モードで Setup:/Network/Service/<UUID>/DNS を直接 remove する |
補足：なぜGUIから消せなかったのか
Wi-FiのTCP/IP・DNSパネルはSystemConfigurationの設定を読み書きしているが、Tunnelblick（OpenVPN）がVPN接続確立時に直接この階層へ書き込みを行うため、VPN切断が正常に完了しなかった場合、GUI操作だけでは完全にロールバックされないケースがある。今回のように接続が不安定（AEAD Decryptエラーが頻発するなど）だと、正常な切断シーケンスが走らずこの現象が起きやすいと考えられる。
同じ症状に遭遇した場合は、Wi-Fiパネルだけでなく scutil --dns で実際に使われているDNS設定を確認し、怪しい残留があれば scutil の対話モードで直接削除するのが確実。
なお、根本的な再発防止のためには、VPN接続自体が不安定な原因（AEAD Decryptエラーなど）を合わせて調査するのが望ましい。