macOS で保存済み VPN 設定を切り替えるとき、実際に何が変わるのか
保存済みの Mac VPN の切り替えはプロファイルの入れ替えではありません。ルート、DNS、認証情報のどこが変わるのか、そして実際に得られたトンネルをどう確認するかを解説します。
VPN 一覧を開き、もう一方の保存済みエントリを選んで、きれいな切り替えを期待しますが、新しい出口アドレスになり、ほかは何も変わらないという前提があります。まずこの前提を捨ててください。macOS の保存済み VPN はプリセットではなく完全なネットワークサービスなので、サービスを切り替えるとルーティング、DNS、認証が同時に変わり得ます。メニューバーはどのサービスが有効かを示すだけで、その下のトンネルが意図どおりかまでは示しません。
保存済みリストはプロファイル選択ツールではない
システム設定 > ネットワークの各エントリは独立したサービスで、サーバアドレス、アカウント、認証方式、DNS サーバー、そして「VPN 接続を介してすべてのトラフィックを送信」などのオプションをそれぞれ持ちます。古いリリースではシステム環境設定に同じ一覧があります。二つのエントリが同じホスト名を指していても挙動が異なることがあるのは、プロトコルやクライアント拡張がトンネルの構築方法を決めるからです。
サードパーティ製クライアントは別々の一覧を持ちます。Tunnelblick は独自フォルダから設定を読み、WireGuard は独自のトンネル一覧を保ち、OpenVPN Connect はアプリ内にプロファイルを保存します。システムに設定を登録するものもあれば、すべてをアプリ内に置いて内蔵一覧に決して現れないものもあります。したがって「保存済みに切り替える」は、どのアプリがプロファイルを所有するかで操作が変わります。
scutil --nc list はシステム構成に登録された VPN サービスを、引用符付きの名前で出力します。切り替えをスクリプト化するときはこの正確な名前を使い、一覧がサードパーティのトンネルをすべて網羅しているとは考えないでください。
切り替えで実際に変わるもの
有効なサービスが変わると 四つのものが同時に動きます。そのサービスが全トラフィックを送るなら既定ルートが新しいトンネルに従い、リゾルバ一覧はサービスが指定する DNS サーバーに変わり、新しい接続は新しいトンネルのアドレスを送信元にし、使われる認証情報は新しいサービスのものになります。ネイティブ設定とアプリのプロファイルは、同じゲートウェイで終わっていても互換ではありません。
| What you assume | What the system does |
|---|---|
| Same server name means same tunnel | Protocol, certificate and account are per service |
| All traffic follows the active VPN | Only when Send all traffic over VPN is on |
| DNS switches with the VPN | Only if that service defines DNS servers |
| Disconnect ends the connection | On Demand or a management profile can reconnect |
| Open sessions survive the switch | TCP sessions tied to the old address stall |
戸惑いやすいのは DNS の部分です。macOS はリゾルバの順序を保ち、scutil --dns はどのリゾルバがどのインターフェースで使われているかを表示します。DNS サーバーを設定していない VPN サービスでは Wi-Fi のリゾルバが答え続けることがあり、新しい公開アドレスを得ても DNS の挙動は古いままで、切り替えが半分しか効いていないと結論づけてしまいます。
古い設定が戻ってくる理由
切断した直後に同じサービスが再び接続するなら、まず On Demand を確認してください。オンデマンド接続のルールは、アプリが一致するドメインを解決したときにサービスを復帰させることがあり、管理プロファイルも同じルールを強制できます。エントリを削除しても直らないことが多いのは、プロファイルで導入した設定は次のプロファイル更新で戻り、手動の設定はサービスが消えても Keychain にパスワードを残すからです。
二つ目のサービスを開始しても、一つ目が必ず止まるわけではありません。クライアントとプロトコルによってはトンネルが二本、ルートが二組になり、どちらが通信を運ぶかはサービスの順序とルートの具体性で決まり、最後にクリックしたアイコンでは決まりません。切り替わったとみなす前にインターフェースを確認してください。
チェックマークではなくトンネルを確認する
設定に触る前に、システム自身の見え方をたどります。scutil --nc status "Name" はシステムが何と考えているかを報告し、ifconfig はutun インターフェースにアドレスがあるかどうかを示し、netstat -rn -f inet は既定ルートがどこを指すかを示し、scutil --dns は実際に使われているリゾルバを示したうえで、新しい接続を開いて出口アドレスを確認してください。すでにサインイン済みのページは、古いトンネルに結び付いたソケットを使い続けているかもしれません。
DNS がまだローカルネットワークから応答するなら、サービスの設定済みサーバーとリゾルバ一覧を比べてください。既定ルートがまだ物理インターフェースを指すなら、そのサービスは分割トンネルか、完全には接続されていません。どちらも設定の結果であり、クライアントの故障の証拠ではありません。
驚きを避ける切り替え順序
- 現在のサービスと、プロファイルが管理しているかどうかを記録します。
- 二つのトンネルが共存できない場合は、先にそれを切断します。
- 切り替え先に接続し、「接続中」ではなく「接続済み」を待ちます。
- 既定ルート、リゾルバ一覧、新しい出口アドレスを確認します。
- 長時間のセッションを保持するアプリを再起動します。
新しいエントリがこれらの確認を通るまで古いエントリを残し、同じラベルが次の障害の原因究明を難しくするため各エントリには別々の名前を付けてください。Apple の Mac ヘルプはネイティブ側をMac で VPN 接続を設定する で説明しており、管理対象の設定を編集する前に確認すべき資料です。
選択が元に戻るなら、まずポリシーか On Demand として扱ってください。設定の所有者と自動接続の設定を確認し、それからサービスを切り替えているのかプロファイルと戦っているのかを判断します。