Mac の VPN が一度だけ接続してタイムアウトする：IKE デーモンを整理する

再起動後の最初の接続は機能します。それ以降の試行はすべて接続段階で止まり、最終的にタイムアウトします。確実な対処はもう一度再起動することだけです。このパターンはプロファイルの問題でも、資格情報の問題でもありません。バックグラウンドの何かが前回の試行の状態を保持したままで、次の試行がそれと衝突しています。

macOS では、その何かは通常 IKE デーモンです。

パターン：一度接続して、その後タイムアウト

起動ごとにちょうど一度だけ機能する接続は、切断では生き残るが再起動では消える状態を指します。プロファイルはどちらでも生き残るので、プロファイルは変数ではありません。資格情報もどちらでも生き残りますが、サーバーがアカウントをロックした場合は別です。再起動で変わるのは、実行中のデーモンの集合とそれらが保持するソケットです。

これで、ログを一つも開く前に調査範囲が絞られます。問題は、どのプロセスが IKE ポートを所有し、何をしているつもりなのかになります。

二つのデーモン、一つのポート

システムは、接続が IKE バージョン 1 を話すときに racoon を実行します。現在のリリースには iked IKEv2 と新しい IPsec スタック向けのものもあります。どちらも UDP 500 と UDP 4500 を占有でき、パスワード入力中に接続試行が取り消されたり、ネットワーク変更で中断されたりした後も、半開のセキュリティアソシエーションを保持できます。

そうなると、次の試行はきれいに始まりません。古いアソシエーションがまだピアの状態を占有している間にネゴシエーションを試みるため、明確なエラーで失敗する代わりにやり取りが停止します。ユーザーには回転するインジケーターが表示され、その後にタイムアウトします。

何かを終了させる前に所有者を特定してください。その答えが、どのサービスを再起動し、次にどのログを読むかを決めます。

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

出力は二つの事実として読んでください。どのプロセスがポートを保持しているか、複数存在するかどうかです。同じソケットを奪い合う二つの IKE デーモンは、不安定なサーバーのように見える断続的な挙動の多くを説明します。

プロセスではなくジョブを再起動する

古いシステムでは、プロセスを終了して次の接続に再起動させれば十分です。現在のリリースではデーモンは launchd が管理しており、プロセスだけにシグナルを送ると、ジョブが実行もされておらず起動予定もない状態に残ることがあります。代わりにジョブを停止して起動してください。

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

launchd にジョブの記録がない場合でも、プロセスを名前で終了させれば次の試行で新しいネゴシエーションが強制されます。どちらの場合も確認方法は同じで、再接続を試みるときにポートを保持しているプロセスがあってはなりません。同じ lsof コマンドで確認し、再起動が成功したと決めつけないでください。

次に一度接続し、クライアントログを最初から読んでください。フェーズ 1 を通過した後に送信失敗を報告するネゴシエーションは、ローカルソケットの問題を繰り返しています； ピアに拒否されたネゴシエーション はまったく別のチケットです。

拒否しているのがサーバーの場合

二回目以降の接続がすべてローカルで失敗するわけではありません。サーバーは切断後の一定期間、新しいログインを拒否することがあり、クライアント側のタイムアウトはスタックしたデーモンと見分けがつきません。判別は簡単です。デーモンの再起動で改善せず、別のアカウントならすぐに接続できるなら、ウィンドウはサーバー側にあり、Mac は問題ではありませんでした。

スプリットトンネルのポリシーも、逆向きに同じ形を作ります。すべてのトラフィックをトンネルに要求するサーバーは、スプリットトンネル向けに設定されたクライアントをネゴシエーション中に切断し、クライアントはポリシー拒否ではなくタイムアウトを報告します。プロファイルを変えてすべてをトンネル経由にすれば接続するかもしれませんが、それはネットワーク所有者と決めるポリシーの判断であり、黙って適用する修理ではありません。

クライアントを再び変更する前に、ピアのログを読んでください。拒否、ポリシーの不一致、静かな切断は三つの異なる原因で、どれも Mac の画面では「接続中」に見えます。

古いクライアントと 64 ビットカーネル

旧 Cisco IPSec クライアントは 32 ビットおよび PowerPC システム向けにビルドされたカーネル拡張を読み込みます。64 ビットカーネルで起動した Mac では、その拡張は読み込めず、クライアントは VPN サブシステムにまったく到達できないため、エラー 51 で早期に失敗します。間違ったアーキテクチャのカーネル拡張は、デーモンを何度再起動しても直りません。

拡張を再読み込みするとしばらく動作し、次の起動でまた失敗することがあります。恒久的な答えは、まだサポートされている環境で古いカーネルを動かすか、システムに付属する内蔵クライアントに移行することです。読み込めないサードパーティ製クライアントに一晩を費やす前に、アーキテクチャを確認してください。

• 一度再現し、プロファイルに触れる前にどのデーモンが UDP 500 を所有しているか確認してください。
• フェーズ 1 以降の最初の失敗を読んでください。送信エラーはローカルソケットを指します。
• プロセスだけでなく launchd ジョブを再起動し、ポートが空いていることを確認してください。
• 二つ目のアカウントを試して、サーバー側の再認証ウィンドウとクライアントの不具合を切り分けてください。
• クライアントを責める前に、カーネルのアーキテクチャを記録してください。

ちょうど一度だけ機能する VPN は、反証されるまで状態の問題です。デーモンを整理するほうが再起動より速く、再起動が捨ててしまうログの証拠を残せます。