Mac の VPN が「切断中」で止まる：実際に動いているもの

「切断中」はトンネルを解体している間にクライアントが報告する状態であり、通信が止まったという判定ではない。Mac ではその解体は短い手順として進み、ラベルは接続を所有するコンポーネントが応答を返してから初めて変わる。ある手順がヘルパー、プラグイン、ポリシーの判断を待つと、インターフェースが消えた後もラベルが残ったり、メニューがまだ表示している間にトンネルが転送を続けたりする。表示は「解体中、結果は不明」として扱い、どちらの半分が本当かを見極める。

二つの障害はメニューバーからは同じに見え、逆の対応を要する。一つではトンネルがまだパケットを運び、表示だけが古い。もう一つではトンネルは消えたが、別のポリシーが通信を遮断したままにしており、これは多くの場合意図的である。ルートと DNS の状態は、どのメニュー操作よりも速く両者を切り分ける。

ラベルが追っているもの

VPN クライアントは小さな状態機械を持ち、メニューバーはその投影である。macOS 自身が管理する接続では、その機械はシステムの VPN フレームワークにある。アプリが管理するトンネルでは、アプリとその特権ヘルパーにある。停止の最後の手順はソケットを閉じることではない。トンネルを成立させていたものを解放することだ。utun インターフェース、そこを指していたルート、クライアントが挿入したリゾルバの項目、そして接続中に通信を遮断していたファイアウォール規則やポリシーである。

これらの手順は別々なので、停止はどれか一つで滞りうる。応答をやめたヘルパー、二つ目のインターフェースも要求するルート、別のプロファイルが所有するリゾルバ項目は、いずれもクライアントを待たせたままにする。ラベルはクライアント自身の進捗に関する報告であり、意図については権威的だが、ネットワークについては当てにならない。

接続を所有するコンポーネントを見つける

ネイティブ構成では、scutil --nc list がシステムの知るサービスとその状態を表示し、scutil --nc status "Work VPN" が一つのサービスの詳細を返す。 サードパーティ製アプリが保持するトンネルは、その一覧にまったく現れないことがあるしたがって、空の結果は何も接続されていない証拠にはならない。

プロファイルがアプリのものなら、そのアプリの状態表示と文書化された「切断」操作に頼る。ウィンドウを閉じることは停止要求ではない。バックグラウンドのヘルパーがトンネルを所有していれば、アイコンは消えてもヘルパーがインターフェースを生かし続ける。Apple の VPN 設定のリファレンス はネイティブの操作項目と、管理対象設定の出どころを扱っている。

インターフェース、ルート、DNS を読む

三つの確認で、接続に触れずに問いの大半に答える。重要なのは三つを合わせて解釈することであり、どれか一つだけでは誤解を招く。

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30

• utun インターフェースがあり、既定または分割ルートがそこを通り、リゾルバがプロバイダーを指している。トンネルはまだ上がっており、ラベルが古い。
• utun がなく、通常の既定ルートで、DNS は DHCP から、インターネットもない。切断中に遮断するポリシーが仕事をしている。
• utun もルートもなく、リゾルバはまだプロバイダーを指している。解体が途中で止まり、DNS が片付けるべき残りである。

次に、トンネル経由でしか応答しないはずの内部ホストへ一つ、公開ホストへ一つ要求を送る。到達性は、確認を計測作業に変えることなく、ポリシーと残留状態を切り分ける。経路がまだ応答するなら遠隔作業を先に保存し、遠隔で管理するマシンのネットワークを変える前に、もう一つの入り口を用意する。

一括終了とプロファイル削除がなぜ誤らせるか

pppd や racoon、configd といったプロセス名は特定の実装に属する。それらを終了させると他の接続に影響しうるうえ、ルートと utun インターフェースを残し、どの手順で滞ったのかの記録も残らない。古いプロセス名も、現在のプロファイルを所有している証拠にはならない。

プロファイルを削除して作り直すのは、滞った遷移を片付けるより大きな変更である。何が失敗したのかを説明しないまま管理対象設定やローカルの身元材料を捨てることがあり、監視下の Mac では単に復元されることもある。削除は本当に古くなった構成のために取っておき、代わりに遷移を診断する。

痕跡を残す停止手順

以下の順序は接続自身の操作項目に主導権を残し、滞りが再発したときの記録を生む。表示の問題をネットワーク変更に変えてしまうことも防ぐ。

1. 遠隔作業を保存し、Mac が遠隔にあるなら別の方法で到達できることを確かめる。
2. クライアント名、バージョン、プロファイルを記録する。log show --last 5m --predicate 'subsystem == "com.apple.networkextension"' で短い時間枠を取得する。古いリリースほど履歴を残さないので、滞った直後に実行する。
3. 文書化された「切断」操作を使い、待ってからインターフェースとルートの確認を繰り返す。
4. ラベルが古いがトンネルが下りているなら、そのままにしてクライアントの更新を待つ。プロセスを強制しない。
5. 解体が本当に滞ったなら、クライアントを再起動し、作業を保存したうえで Mac の再起動を計画する。管理対象のマシンでは管理者の手順が必要だ。

復旧後、通常の既定ルートと DHCP リゾルバが戻ったこと、遮断された通信が復元されたか意図的に遮断されたままかを確認する。プロファイルとクライアントのバージョンを症状とともに記録し、次回はメニューバーの推測ではなく証拠から始められるようにする。