iPhone Always On VPN: 二つのトンネルが一つの仮想IPを共有できる場合

管理されたAlways Onプロファイルを使う監視対象のiPhoneでは、電話機はアクティブなIPインターフェイスごとにトンネルを保持するため、セルラーとWi-Fiがそれぞれ自分のトンネルを持ちます。するとサーバーには一台の端末に対して二つのIKEセキュリティアソシエーションが並び、多くの場合一つの仮想アドレスを共有します。最初の直感は、これをrekeyループと呼んでタイマーを変え始めることですが、その直感はたいてい間違いです。以下の手順を、サーバー上で証拠が現れる順にたどり、サーバーがどのケースかを教えるまで電話機の設定には触れないでください。

サーバーがすでに持っている二行から始める

アソシエーションをswanctl --list-sasで一覧し、両方のエントリで四つのフィールド、つまりリモートアドレス、認証されたID、割り当てられた仮想IP、作成時刻を読みます。一つのIDと一つの仮想IPに対して二つの異なる外部アドレスというのがこの疑問の出発点になった形であり、変更の前に書き留める価値があります。次に、トラフィックセレクターが宛先検索で二つのトンネルを区別できるかどうかを決めるため、それぞれに付いている子アソシエーションを確認します。数秒のうちに現れて消えるペアは、両方が何時間も生きるペアとは別の生き物です。

結論を出す前に、一覧を作成時刻で並べ替えてください。出力内の隣接には何の意味もなく、表形式の一覧はまさにその間違いを誘います。

どちらの重なりを見ているのかを決める

IKEv2のrekeyとmake-before-break再認証は、古いアソシエーションを削除する前に新しいものを確立することで、意図的に短い重なりを作ります。タイムスタンプが決め手で、新しいものが現れてから一秒か二秒後に消える古いSAは役目を果たしている更新だからです。独立したインターフェイストンネルは決してそうは見えず、それぞれが自分のインターフェイスが上がっている間は存続し、一方を削除しても他方の作成にはつながらないからです。

Appleの管理されたAlways Onの動作はインターフェイス単位であり、だからこそ監視対象の端末は手作業で設定したプロファイルより正当に忙しく見えることがあります。プロバイダーアプリの自動接続トグルも同じ意味ではなく、通常のオンデマンドルールも同様です。Appleの展開の概要はインターフェイス単位のモデルを説明していますから、ループだと決めつける前に自分の二行をそれと比べてください。どちらの形も同じサーバー側プールから取るので、重なりが唯一の早期シグナルです。

一つの仮想アドレスが二つのトンネルの応答を壊す理由を見る

電話機への応答は内部アドレス宛てに送られ、カーネルは宛先とポリシーで外向きトンネルを選びますが、電話機が使ったインターフェイスでは選ばず、同じ仮想IPを保持しポリシーが一致する二つの同時アソシエーションでは、応答がどのセッションのものかをルーティング判断が言えなくなります。一部の応答は間違ったトンネルを通り、電話機では片方向だけ機能する接続や、Wi-Fiが上がると切れる接続が見えます。二つのコマンド出力が状態を証明します。swanctl --list-sasが両方のSAで同じ仮想IPを示し、ip xfrm policyが二つの同一セレクターを示します。

その出力のペアこそ、変更記録に貼るものです。どちらか一方だけでは説得力がなく、どちらも単独ではもっともらしく見えるからです。

これはサーバー側のアドレッシングとポリシーの問題であり、電話機の不具合ではありません。二つの同一の内部アドレスを分けるクライアント設定は存在しません。プールが同じ値を二回配り、ポリシーインストーラーがそれを受け入れたので、クライアントを責める前にサーバー側から結果を読んでください。

プールか並行性モデルを変える、rekeyタイマーではない

swanctlの設定では、一意性は接続に対する明示的なポリシーです。unique = replaceは新しい接続が確立したときに古い接続を削除し、unique = keepは新しく来たものを拒否しますが、どちらの値も接続を設定するときに働き、その中の子SAには働きません。

connections {
  ios-alwayson {
    unique = replace
  }
}

どちらの値も、インターフェイス単位のクライアントにとって中立ではありません。keepは二本目のトンネルを拒否して整ったステータス画面を戻しますが、管理された設計を壊します。一方replaceは古いトンネルを切り倒し、反対方向への同じ妥協になります。二つのトンネルが本当に必要な場合は、プールのバックエンドが一つのIDに対して別々のリースを発行する必要があり、そのリースキーが要求を区別しなければなりません。静的なID対アドレスの表は同じアドレスを二回返して元の問題をより多くの設定で再現するので、二つ目の静的マッピングを追加する前に、バックエンドがリースをどうキー付けするかを確認してください。

実際に配備する遷移をテストする

セッションを有効にしたままWi-Fiの範囲外に出て、それから戻り、応答が両方向に届くことを確認します。二回行うのは、二回目の遷移が古いポリシーのたいてい現れる場所だからです。開いた接続に応答するサービスで試し、トンネルがアイドルでいるときではなくトラフィックを運んでいるときに外出を繰り返します。送信はできるが受信できない電話機は、ハンドシェイクログでは健全に見え、ブラウザーでは壊れて見えます。

一行に縮んだステータス画面は、機能する設計の証拠ではなく、一つのトンネルが消えた証拠にすぎません。遷移が通る前に、両方向が機能していなければなりません。観察したことを重なり確認の二つの出力とともに書き留めて、次のエンジニアが同じ散歩を繰り返すのではなく比較できるようにしてください。