Mac の VPN は「切断」を押した直後に勝手に再接続する

「切断」を押すと確かに切れますが、十秒後にはトンネルがまた戻ってきます。このループは VPN クライアントの不具合であることはほとんどなく、常に一つの問い、「落ちているか？」だけを立て、それに接続で答える復旧スクリプトです。ユーザーが答えた問いと、システムが報告する問いを分ければ、修正は長い待機ではなく小さな状態の量になります。

二つの問い、一つではない

このプロファイルは今接続されるべきか、そしてシステムは今何を報告しているのか？これらは所有者の異なる別々の問いであり、復旧ポリシーは行動する前に両方を必要とします。意図は、あなたのツールが決めて記憶するものです。観測された状態は、プラットフォームがあなたに伝えるものです。

行はケースの一覧ではなくポリシーとして読んでください。二行目こそ多くのスクリプトが省く行であり、監視を、自分が正しいと主張し続ける機械から区別する唯一の行です。

観測された状態は好みではない

Apple の Network Extension の状態モデルは、connecting、connected、disconnecting、disconnected、recovery の状態を報告します。五つとも接続を記述しています。そのどれも「ユーザーはこのプロファイルを一時停止のままにしておくよう求めた」とは言いません、なぜならそれは接続の状態ではまったくないからです。そのフレームワークの上に作られていないクライアントは、独自の対応する操作と状態取得を公開しており、同じ線を独自の語彙で引いています。

結果として、切断された状態はそれだけでは決して解釈できません。それは少なくとも三つのうちの一つを意味します：トンネルが落ちた、ユーザーが止めた、あるいはシステムが試行の合間にある、ということです。それらを見分けられるのは、あなた自身の意図の記録だけです。その記録を書き、再起動をまたぐ必要があるなら再起動を越えて保持し、後からログ行から推測するのではなく、ユーザーが操作したその瞬間に更新してください。

scutil --nc list
scutil --nc status "Office VPN"

このプロファイルを起動できるのは誰か

ヘルパーが約束する一時停止は、同じプロファイルの他の所有者と同じだけの強さしかありません。On Demand のルール、管理された構成、あるいは二つ目のクライアントが接続を要求でき、ヘルパーは書かれたとおりに振る舞っているのに壊れて見えるでしょう。

プロファイルを起動できるあらゆる仕組みを見つける一時停止を守ると約束する前に、どれが勝つかを書き留めてください。管理されたサービスが個人の一時停止オプションを意図的に用意しない場合、それはポリシーについての管理者の決定であり、スクリプトが管理と戦って埋めるべき隙間ではありません。

再試行をつまらなくする

試行回数に上限を設け、それぞれを、ネットワークが戻った、ゲートウェイが応答した、資格情報のプロンプトが完了した、といった何か変化したことに対応させてください。利用できないゲートウェイ、期限切れの識別情報、拒否された第二要素には三つの異なる応答が必要ですが、短い間隔のループは三つとも同じ応答にします。

高速な再試行が画面で実際に何を生むかを見てください。ユーザーが閉じる繰り返しのダイアログは、一つの明確な失敗メッセージより悪く、人々にプロンプトを読まずにクリックさせる習慣を作ります。

一時停止と通信ポリシーは別々の約束

ユーザーが一時停止したトンネルは、しばしば通信を意図的にブロックしたままにしますが、それが kill switch 型ポリシーの要点です。つまり「一時停止」が約束すべきはただ一つ、復旧が止まることです。ネットワークが何を許可するかを黙って変えるべきではありません。

通信の挙動は別に決め、一時停止の操作の隣に文書化し、トンネルが一時停止中でも失敗中でも存在しなくても一貫させてください。さもないと、ユーザーは「切断」を押すと予測できないことが起きると学び、次のサポートチケットは、目に見える理由もなく「時々動かなくなる」ネットワークについてのものになります。