ふたつのアップリンクにひとつのトンネル：フェイルオーバー、分散、それとも束ねるのか

フェイルオーバー、フロー単位の分散、単一フローの集約は、それぞれ別の約束です。デフォルトルートが二本あっても得られるのは最初のものだけで、残りのふたつは得られません。

二本のインターネット回線はVPNの可用性を高め、一部のワークロードでは速度も上げられますが、どちらが起きるかは仕組みが決めます。デフォルトルートが二本あるルーターは束ねられておらず、数千の内部接続を運ぶトンネルも依然としてひとつの外側フローです。約束を先に名付けることが、設計と高価な失望の分かれ目です。下の表は、各方式が遠端で何を必要とし、リンク喪失が転送に何をするかで選択肢を分けています。

三つの約束、パートナーが要るのはひとつだけ

フェイルオーバーは、優先リンクが消えたときにも経路を利用可能に保ちます。フローハッシュ分散は独立したフローを二本のアップリンクに振り分けます。単一フロー集約は、ひとつの転送が二本のリンクを同時に使えるようにします。これらは要件の異なる別製品であり、最後のものだけがルーターの外側にある何かの協力を必要とします。

MechanismFar-end requirementEffect on one transferWhat breaks under a link loss
Packet-spraying overlayA cooperating endpoint that reassembles the streamPackets can spread across both linksReordering and buffering on the surviving path; its own recovery logic decides what continues
MPTCP subflowsA peer or proxy that accepts subflowsSubflows can share one connectionSurviving subflows continue if the peer keeps them alive
Flow-hash balancingNothing new; the existing tunnel endpoint is enoughOne outer flow still follows one linkFlows hashed onto the dead link move; established sessions break
Link failoverNothing newOne path at a time; the second link sits idleThe session stalls or restarts on the other link

あの表のどこにも、二本目の回線を買う理由はありません。あの表がするのは、フェイルオーバー設計を束ねているかのように評価するのを止めることです。

ルーターから見てトンネルがひとつのフローに見える理由

負荷分散ルーターは送信元と宛先のアドレスをポートとともにハッシュし、ハッシュが指す先へフロー全体を送ります。VPNトンネルはルーターから見ればそうしたひとつのフローであり、中で何が動いていても変わりません。内部接続がハッシュの判断に届くことはありません。外側のヘッダーがすでに経路を決めているからです。だからこそ二本目のアップリンクは多くの利用者の総容量を二倍にでき、ひとりの利用者の大きな転送には何も変えません。

別々のふたつのトンネルはふたつの候補を与えますが、それでもトラフィックを割り当て、応答を要求が通った経路に保つ意図的なポリシーが必要です。その手順を飛ばすと、非対称ルーティングが普通の結果になります。最低限必要なのは、フロー、優先リンク、予備リンクを名指すポリシーです。

Ethernetの束ねは無関係なプロバイダーをまたげません。遠端が集約プロトコルに参加しなければならないからです。協力する端点がなければ、ふたつのISPにまたがる束ねは研究プロジェクトです。

マルチパスTCPが両端で必要とするもの

LinuxのMultipath TCPのドキュメントは、ひとつの接続に属する複数のサブフローを説明しています。片端のカーネル対応だけでは何も変わらず、相手側もそのサブフローを受け入れる必要があります。遠端のプロキシがもうひとつの一般的な構成で、独自の容量と可用性を持つ部品となり、それを計画に入れる必要があります。同じ論理でWireGuardに簡単な答えはありません。転送がUDPだからです。MPTCPはTCPのサブフローを増やすもので、設計に別の要素がなければそのトンネルを集約できません。

カーネル機能が有効かどうかは、それを前提に設計する前に確認してください。多くのディストリビューションは無効のまま出荷しています。この三つのコマンドで一分で分かります。

sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits show

パンフレットではなくワークロードで選ぶ

ワークロードが多数の独立したセッションなら、フローハッシュ分散は遠端の協力なしに容量を増やせます。ひとつの大きな転送なら、集約の設計だけが助けになり、その設計には協力する相手が必要です。リンクが死んでも作業が続くことが要件なら、答えはフェイルオーバーであり、ひとつの転送のスループットは無関係です。

要件は動詞を入れた一文で書いてください。バックアップが二倍速く終わる、あるいは落ちたリンクでセッションが終わらない、という形です。曖昧な目標は、誰も受け入れも拒否もできない設計を生みます。次に遠端が何であってよいかを決めます。最も安い選択肢は、そこに何も新しいものを要求しない場合が多いからです。その制約が、最初の会議の前にパンフレットの主張の大半を消します。

要件文書では三つの約束を分けておいてください。三つすべてを主張する設計は、普通はひとつを届け、残りを黙って前提にします。次の節では、実際にどれが届けられるかを試します。

ひとつの転送と多数を試し、それからリンクを抜く

ひとつの持続的な転送を、同じ宛先への複数の並列転送と比べてください。そしてそれぞれの損失、遅延、リンクごとの使用率を記録します。並列セッションだけで得が出るなら、それはフローの分散を示し、単一フローの集約ではありません。一本のアップリンクの喪失は別に試してください。両方のリンクが動いているときの容量は、確立済みセッションのフェイルオーバーについて何も語らないからです。各試験の前後で経路、ソケット、再送カウンターを記録します。

ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5

単一の転送がまだ一本のアップリンクを使っているなら、その設計はフローハッシュが意味するとおりに動いています。並列転送が両方に広がるなら、分散は効いていて集約は効いていません。設計が三つの約束のどれを実際に守るのかを記録してください。次の容量の話は、ベンダーの主張ではなく証拠から始まります。

関連記事