複数パス上の VPN：キャリアが提供すべき四つの保証

二本目の WAN リンクを追加するとトンネルは上がるが、片方のパスが揺らぐとファイルコピーはやはり止まる。リンクは健全で VPN プロセスも動いている。足りないのはキャリアとトンネルの間の契約だ。複数のソケットは自動的に一つの接続のようには振る舞わず、その上のアプリケーションは配送が破綻するまで違いに気づけない。契約の各部分はテスト可能な障害に対応しており、それが契約を有用にする。

製品を選ぶ前にその契約を書く。四つの部分がある。VPN が受け取るストリーム、キャリアが欠落データをどう回復するか、どのエンドポイント ID がパス変更を生き延びるか、そしてパスが故障したときに全体がどう振る舞うかだ。

症状：リンクは上がっているのにセッションが切れる

両方のリンクが上がっていることを示す監視グラフは、各パスがトラフィックを運べることしか証明しない。VPN が一本の順序だったストリームを見ていること、片方のパスで失われたパケットが別のパスで回復されること、ピアがまだどのセッションと話しているか知っていることは証明しない。契約の残りは、そのグラフが見せられないものを覆う。

転送が止まったら、キャリアが生き残ったパスで配送を続けたかを調べる。二本目のリンクが遊んでいる間にセッションが死ぬなら、キャリアはそれを使っていない。セッションが生きていてもデータが順序外れや重複で届くなら、キャリアは接続レベルの契約なしにパケットを動かしている。両側のタイムスタンプで大抵はっきりする。

この違いが修正方法を決める。ルーティングやポリシーの問題はパス選択の変更が要る。順序と回復の層が欠けているなら、より大きなバッファではなく別のトランスポートが要る。

保証一：接続レベルのバイトストリーム

VPN が信頼できる順序だったストリームを必要とするなら、キャリアは個々のパスより上でバイト範囲を識別しなければならない。下位の TCP 接続は自分のセグメントだけを番号付けするので、受信側はその番号だけではパスをまたいで並べ替えられない。

Multipath TCP が標準的な例だ。複数の TCP サブフローを調整しながら一本の信頼できるバイトストリームを提示し、データレベルのシーケンスマッピングと確認を持つ。アプリケーションが読むのはストリームであり、たまたま最初に断片を届けたサブフローではない。

Linux では MPTCP はソケットごとに IPPROTO_MPTCP でオプトインする。ネゴシエーションがマルチパス動作を使えない場合、文書化されたフォールバックは通常の TCP であり、アプリケーションは二本目を一度も使わずに一本のパスで動き続けるかもしれない。カーネル設定が効いたと仮定せず、配備されたソケットが実際に何をネゴシエートしたかを確認すること。

保証二：順序、重複、回復

遅延や損失率の異なるパスは、キャリアにバッファリング、並べ替え、再送を強いる。契約は、許されるバッファ量、アプリケーションが見る背圧、再送をどのパスが運ぶかを明記しなければならない。

接続を保ったまま配送をやめるパスは、きれいなクローズより厄介だ。キャリアはそれを検出し、未完了のデータを移し、永遠に来ないセグメントを待ち続けないようにしなければならない。単純な「両リンクが上がっている」チェックではこの状態を覆えない。

重複には独自のルールが要る。同じペイロードを両方のパスで送れば遅延を改善できるが、受信側は VPN に届く前にコピーを抑止しなければならない。IPsec のリプレイ対策はセキュリティアソシエーションごとに任意で、シーケンス番号を検査する。パケットを並べ替えたり再生したりする重複層は、それを発動させたり、トンネルが落ちるまで問題を隠したりしうる。

保証三：エンドポイント ID とパスの結合

新しいパスが現れたとき、ピアはセッションを認識する安定した手段を必要とする。各パスを別々のトンネルとして認証すると、VPN は一つではなく二つのセッションを見るかもしれない。キャリアがパスを一つのセッションの下に結合するなら、新しいパスをどう認証し、古いパスがどうなるかを定義しなければならない。

どのアドレスと識別子が安定しているかを記録する。トンネルのエンドポイント、キャリアのセッション識別子、その間のプロキシだ。プロキシは保護されたペイロードを一度も見なくても、可用性と信頼の境界をもう一つ増やす。

ポリシーもここにある。予期しないネットワークから参加するパスは技術的には有効でも、意図した信頼モデルに反することがある。新しいパスを自動で受け入れるか、認証を要求するか、拒否するかを決める。

保証四：障害時の有界な挙動

遅いパスだけでなく、パスの完全な故障をテストする。生き残ったパスはメモリが無制限に増えることなくセッションを運び、回復はアプリケーションが許容できるより長いタイマーに依存すべきでない。故障したパスが戻ったとき、キャリアは再バランスするか、フローをその場に残すかを決めなければならない。

バッファリング、再送、パス数に上限を設け、損失、並べ替え、重複、遅延の不均衡の下で検証する。ここで最も興味の薄い数字は総帯域だ。配送の継続性とメモリの境界こそが契約である。

キャリアの回復状態は VPN の暗号状態と分けておく。確立された認証や暗号化を置き換える自作の信頼性層は近道ではなく、層をまたいでシーケンス番号を再利用することがリプレイ防御と診断を不確かにする。

テスト計画でキャリアを受け入れる

四つの保証を合否チェックとして書く。一本の順序だったストリーム、定義された回復、安定したセッション ID、有界な障害挙動。各チェックは一本のパスを劣化させ、次に一本を外して実行する。

パス変更をまたいだ一回の成功したファイル転送は継続動作を証明しない。優先パスを切り替えながら転送を繰り返し、キャリアの見え方と VPN 自身のカウンターの両方を点検する。どちらのパスがデータを運んだかで両者が食い違うなら、契約はまだ観測可能ではない。

署名済みのマトリクスを配備と一緒に保管する。次のエンジニアに、何が約束され、どのパスの組み合わせがテストされ、どの障害モードがまだ未対応かを、リンク状態灯から推測し直すことなく伝える。