トンネル技術の比較

トンネルとは、ある通信を別の通信でカプセル化することを指します。選定にあたっては、「いったい何を転送したいのか」という問いに答えなければなりません。改造できないデバイスのEthernetフレーム、サブネット全体のIPパケット、それとも特定サービスのTCP接続か。これらのニーズは、ブロードキャスト範囲、ルーティング動作、権限の境界が異なり、単に製品のパフォーマンスだけで順位付けすることはできません。

「デプロイ可能」かどうかを判断するには、既存のデバイスが対応しているか、運用側が鍵とルーティングを管理できるか、出口で必要な転送が許可されているかも考慮する必要があります。デバイスがIPsecのオフロードに対応しているからといって、特定のアルゴリズム、カプセル化、トラフィックがオフロードパスを通過するとは限りません。

IPIPとGRE：最も単純なIPカプセル化は同じプロトコルではない

IPv4-in-IPv4は、元のIPv4パケットの直前に新しいIPv4ヘッダを追加し、外側のProtocolフィールドは4となります。オプションがない場合、20バイトが追加されます。GREはプロトコル番号47を使用し、さらに4バイトの基本GREヘッダを持ち、その中のProtocol Typeフィールドがカプセル化されたプロトコルを示します。したがってGREはより汎用的ですが、「ヘッダのないIPIP」と呼べるものではありません。IP-in-IP RFC 2003、GRE RFC 2784

GREは拡張フィールドとしてKey、シーケンス番号、チェックサムなどを携带できます。長さは固定の4バイトである必要はありません。Keyは論理トンネルを区別するために使用できますが、認証資格としては機能しません。攻撃者は暗号化の秘密鍵を知らなくても、同じKeyを構築することができます。基本のIPIPとGREは、どちらもペイロードの機密性を提供しません。

内側が1400バイトのIPv4パケットであると仮定します。オプションなしのIPv4-in-IPv4は1420バイト、基本GRE over IPv4は1424バイトとなります。ここでは外側のEthernetヘッダは含まれておらず、暗号化も追加されていません。この数字を「オンラインでのバイト占有量」と比較する際は、同じ階層の口径で揃える必要があります。

VXLANとGeneve：トンネル自体が完全な仮想ネットワークコントロールプレーンではない

VXLANは内側のEthernetフレームをUDPにカプセル化します。基本VXLANヘッダは8バイトで、VNI（VXLAN Network Identifier）は24ビットです。VNIは論理ネットワークを示すものであり、暗号化キーではありません。同じVNIへの誤ったアクセスを防ぐには、下層の分離とエントリポイントでの検証が必要です。UDPのソースポートは、外側のECMPにおけるトラフィックのハッシュ分散に使用できますが、すべてのパケットでランダムにパスを変更する必要があるわけではありません。VXLAN RFC 7348

Geneveの基本ヘッダも8バイトですが、可変長のオプションをサポートしており、ネットワーク仮想化のメタデータ携带に適しています。計算オーバーヘッドを評価する際は、実際のオプション長を加算する必要があります。理解できない重要なオプションに出会った場合、処理ルールがパケットの受信可否に影響を与えるため、オプションをすべてのエンドポイントに対して透過的な装飾として扱うことはできません。Geneve RFC 8926

カプセル化はパケットの搬送方法を示すだけで、遠端のMACアドレスがどこにあるか、不明なユニキャストを誰に送信すべきか、ブロードキャストをどのように複製するかは説明しません。学習、静的設定、またはEVPNなどのコントロールプレーンがこれらの問題を担います。レイヤ2の拡張は、ブロードキャストと障害の影響をより多くの場所に持ち込みます。アプリケーションがユニキャストIPの相互通信のみを必要とする場合、本当に同じブロードキャストドメインを必要としているかどうかをまず判断すべきです。

なぜVXLANでMTUが必ず9000である必要はないのか

VLANなし、内側フレームがFCSを持たず、外側IPv4にオプションがない場合を例とします。1500バイトの内側IPパケットに、内側Ethernet 14バイト、VXLAN 8バイト、UDP 8バイト、外側IP 20バイトを加えると、合計1550バイトの外側IPパケットとなります。重要なのはパスがこのサイズをサポートしていることであり、9000は単なるネットワーク設定の一つに過ぎません。内側MTUを下げることでも対応可能であり、任意のフラグメンテーションを無代价な救済策として扱うことはできません。

inner_ip = 1500
encapsulation = {
    'IPIP/IPv4': 20,
    'GRE-basic/IPv4': 20 + 4,
    'VXLAN/IPv4': 20 + 8 + 8 + 14,
    'VXLAN/IPv6': 40 + 8 + 8 + 14,
    'Geneve/IPv4+16B-options': 20 + 8 + 8 + 16 + 14,
}
assert inner_ip + encapsulation['VXLAN/IPv4'] == 1550
assert 1500 - encapsulation['VXLAN/IPv4'] == 1450
assert 1500 - encapsulation['VXLAN/IPv6'] == 1430
assert 1500 - encapsulation['Geneve/IPv4+16B-options'] == 1434
# 1550バイトの外側IPパケットに、外側EthernetヘッダとFCSを加える；プレアンブルとフレームインターバルはまだ計算していない。
assert 1550 + 14 + 4 == 1568
print('外側IP長を基準としたカプセル化予算の計算が通過した')

内側のVLAN、追加の暗号化、または第2のレイヤトンネルも、引き続き予算を消費します。TCP MSSはTCPデータセグメントに影響を与えるのみです。MSSを下げるだけでは大規模なUDPデータグラムは解決できず、すべてのパスでのPMTU処理を代替できるわけではありません。

1500バイトの内側パケット、外側には本当に収まるのか？

まずVXLANのIPv4とIPv6の外側を比較すると、内側の上限は20バイト異なります。次にESPを選択し、内側長を1438から1439に増やした場合、外側は1バイトだけ増えるのではなく、アライメントのために1500から1504へと段差をつけて増加します。予算にはこのような離散的な変化を含める必要があります。

WireGuard、IPsec、プラットフォーム機能は別々に比較すべき

WireGuard は、ピアの公開鍵、AllowedIPs、UDPデータプレーンを組み合わせていますが、プロトコル自体には完全なユーザーディレクトリや一般的な自動NAT透過サービスは含まれていません。IPsec/IKEv2 はポリシーとSA（セキュリティ・アソシエーション）によってIPトラフィックを保護し、認証、アルゴリズムのネゴシエーション、デバイス間の相互運用においてより豊富な設定空間を持ちます。パフォーマンスは実装、アルゴリズムのアクセラレーション、パケット長、コア数、リンクによって決定され、環境を問わず常に優位な「チャンピオン」は存在しません。

Tailscale はWireGuardの上にアイデンティティ、ポリシー配布、発見、リレー機能を追加します。それは単なる裸のWireGuardとの違いではなく、デプロイコストを比較する際には、ピア、公開鍵、ルーティングを手動で保守する作業量と、プラットフォームコントロールプレーンへの依存度を計算に入れる必要があります。

「エンドツーエンド暗号化」のエンドポイントを明確にする必要があります。2台の業務ホストがそれぞれトンネルを終端する場合と、2台のゲートウェイ間のトンネルでは異なります。後者の場合、ゲートウェイを出た後は平文ネットワークを通過し続ける可能性があります。アプリケーションTLSを使用することで、さらに遠くのエンドまで保護を提供できます。

リバーストンネル：内部ネットワークのクライアントが能動的に外向き接続を行い、パブリックエンドでアクセスを受信する

通常の公開ネットワークポートフォワーディング方式では、内部ネットワークのプロキシCが公開ネットワークのプロキシSに能動的に接続し、Sが外部接続をCに転送し、Cがローカルサービスに接続します。これにより、内部ネットワークへの直接のインバウンドアクセスという要件を回避できますが、公開ネットワークのSは依然として到達可能である必要があり、Cのアウトバウンド接続も許可されている必要があります。ここでは、訪問者から内部ネットワークへのUDPホールパンチングの確立は必須ではありません。

ratholeとfrpの一般的なデプロイメントにはどちらもserver/clientの役割がありますが、前者が天然に非対称で分散型であり、後者が集中構造であると記述することはできません。ratholeの現在のリポジトリ設定はTCPとUDPサービスをサポートし、TLS、Noiseなどの転送オプションを提供しており、「TCPのみをサポートし、暗号化はCaddyに依存する」という記述は正確ではありません。rathole プロジェクト、転送設定

製品がUDPサービスをサポートしていることと、「プロキシ間で必ずネイティブUDP転送が行われる」ことは別問題です。UDPデータが信頼性のあるストリームで転送される場合、パケットロスとキューヘッドブロッキングの動作が変化します。複数の業務接続が1つのTCP転送を共有する場合、外側のパケットロス回復が他のリユース接続に影響を与える可能性があります。frp ネットワーク設定

コネクションプールがすべてのハンドシェイクを解消できない理由

プールは、一部のコネクション準備作業をビジネスリクエストの到着前に移動させ、ヒット時に待ち時間を削減します。リユースは、複数の論理コネクションが既存の転送を共有することを許可します。frpはこれらのメカニズムの両方をサポートしているため、「ratholeは事前に構築し、frpは常にリクエストごとに新規TCPを確立する」という記述を両者の根本的な違いとして使うことはできません。

S—Cチャネルが準備されていても、訪問者からSへの接続、Cからローカルサービスへの接続、およびアプリケーションTLS/ログイン手順が存在する可能性があります。プール内コネクションが無効になった場合は、検出と補充が必要です。early eof を唯一の原因をNATのアイドルタイムアウトに帰属させることはできず、相手側のクローズ、プロセス終了、またはプロトコルの不一致によっても発生し得ます。

例えば、リクエストがオンデマンドでチャネルを確立する際に追加で40msの待ち時間が発生し、事前準備チャネルのヒット率が90%であると仮定します。この項目のみを計算すると、平均待ち時間は4msとなります。残りの10%のリクエストには依然として40msの待ち時間が存在し、平均値だけでテールレイテンシが消失したとは言えません。プールが大きくなると、より多くのFD、メモリ、ゲートウェイの状態を占有します。

エントリポイントTLSとトンネル暗号化：2つの異なる終端位置

CaddyがSでブラウザのTLSを終端する場合、SはHTTPの平文を見ることができます。S—C間のTLS/Noiseを有効にすることで転送を継続して保護できますが、Sを業務コンテンツを見えない中継ポイントに戻すわけではありません。訪問者からオリジンサーバーまでアプリケーションTLSを透通させる場合、Sは対応する暗号文を転送するだけであり、証明書とアプリケーションの認証はオリジンサーバーが担当します。

プロキシ登録トークンは、Cが特定の転送サービスに登録する権限を持っていることを証明するものであり、パブリックリスニングポートにアクセスするすべてのユーザーを自動的に検証するものではありません。公開管理ページ、データベースポート、またはファイルサービスの場合、アクセス制御は実際のエントリポイントまたはアプリケーションで実施する必要があります。トンネルの両側にトークンを1つ設定するだけでは、そのサービスがプライベート化されたことを意味しません。

完全なシナリオを使って選択を行う

3人の同僚が家庭用NASの管理ページにアクセスする必要があると仮定します。訪問者はクライアントをインストールでき、公開アクセスは不要です。まず、デバイスオーバーレイネットワークソリューションのメンバー承認、クライアントサポート、復旧コストを比較します。管理ページをパブリックネットワークに公開し、追加のエントリ認証を重ねる必要はありません。

目標がクライアントインストール不要の公開デモサイトに変更された場合、リバースHTTPプロキシがエントリ形式として適切であり、次にTLS終端、ドメイン名、オリジンサーバーのアイデンティティ、リクエストサイズ/タイムアウトを決定します。目標が多数のIPサービスを持つ2つのサブネットを接続することに変更された場合、ゲートウェイVPN、ルーティング、戻り経路を比較します。アプリケーションがレイヤ2の発見や特定のEthernetセマンティクスを必要とする場合にのみ、レイヤ2オーバーレイネットワークとブロードキャスト境界の評価を続行します。

これらの判断は、製品の永久的なランキングではありません。評価レポートには少なくとも、データが実際に誰を通り、誰が復号でき、何へのアクセスが許可され、最大有効パケット長はどれくらいか、満負荷時のメモリ使用量とテールレイテンシ、そしてコントロール接続の切断後に新旧の業務がそれぞれどうなるかを示す必要があります。「軽量、低レイテンシ、エンタープライズ級」とだけ書いても、それに基づいて再現したりトレードオフを決定したりすることはできません。