セルラー回線の二つの拠点、内向きポートなし：機能するハブを作る

セルラー回線上の二つの拠点は、どちらも求められていない IPv4 接続を受け付けられないため、双方向とも直接トンネルでサーバー役を務められません。機能する構成は到達可能な第三者を中央に置き、各拠点は外側へ発信し、中央は承認した通信だけを転送します。その中央は自分で運用するルーターか、ピアを紹介する製品のどちらかであり、両者は同じものではありません。以下の手順は、次がそれに依存する前に各手順が証拠を残すよう並べてあります。

どちらの拠点にも発信できないため、両方が外側へ発信する必要があります

設計する前に制約を確認してください。事業者が WAN インターフェースにプライベートアドレスを渡している場合、変換が上流で行われるため、拠点側のルーターでポート転送を設定しても到達可能にはなりません。同じ回線にパブリック IPv6 アドレスがあれば設計は根本から変わるため、確認は両方のファミリーを対象にします。同じ事業者を共有していても両者の制約が同一になることはまれなので、拠点ごとに答えを書き留めてください。

通常のセルラー環境では、事業者の変換済み範囲のアドレスと、そこを通るデフォルトルートが見えます。これは修理すべき不具合ではなく、ハブが存在する理由です。探しているのは、拠点が先に話さなくても第三者が到達できるアドレスです。

目の前の拠点のアドレスに関する問いには、二つのコマンドが答えます。拠点のルーターで実行し、その背後のノート PC では実行しないでください：

ip -4 addr show scope global
ip -6 addr show scope global

誰がピアを紹介し、誰がパケットを運ぶのか

紹介と転送は別の仕事ですが、製品は境界を可視化しないまままとめて提供することがよくあります。ランデブーの仕組みは二つのピアが候補経路を見つけるのを助け、直接経路がないときはリレーがパケットを運びます。ピアを紹介するサービスを買ってもルーターが手に入るわけではなく、その違いが設計にハブが必要かどうかを決めます。

トラバーサルには独自の語彙があり、その言葉は役割を説明するもので、保証ではありません。 ICE 仕様 は候補と接続性チェックを説明し、STUN はアドレス変換を知る一つの方法を、TURN はそれを実装したアプリケーション向けのリレー転送を説明します。これらの仕組みがどれも一般的なゲートウェイに現れないのは、探索アドレスに向けただけだからです。トラバーサルは製品の能力として検証し、テストが逆を示すまではリレーを前提にしてください。

拠点ごとに一つのルートを、ピアが所有する

ハブには拠点ごとに一つのトンネル、それぞれの背後に別々の LAN プレフィックス、そして各プレフィックスの所有者を示すルートが必要です。例ではハブが 10.61.0.1、拠点 A が 10.61.0.11 で LAN は 10.60.10.0/24、拠点 B が 10.61.0.12 で LAN は 10.60.20.0/24 です。以下の各ルートはトンネルのインターフェースではなく、プレフィックスを所有するピアを指します：

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

転送を有効にしないと、原因を示すエラーもなくパケットはハブで止まります。最後のコマンドは、送信元を含めた検索で拠点 A の LAN から拠点 B の LAN へパケットがどの経路をたどるかを尋ねるため、本当の問いに答えます。トンネルのインターフェースを名指す検索は証拠として、デフォルトルートに落ちる検索は謎ではなく欠けたルートとして扱ってください。次に通過を意図的に制限しますが、それはすべてのピアの間を転送するハブが二つの拠点を平坦なネットワークに変え、あると思っていたアクセス ポリシーを適用されないものにしてしまうからです。

暗号化がどこで終わるかも決めてください。ハブがトンネルの両端を持つ場合、そのマシンの運用者とそのワークロードが信頼と可用性のモデルに加わり、その帯域が経路の一部になります。

すべてのマッピングを事業者越しに生かし続ける

各拠点は自分のトンネルを開始し、それぞれが変換マッピングを生かし続けないと事業者はそれを忘れます。開始側のキープアライブがハンドシェイクの間でそのマッピングを保ちます。許可するプレフィックスはハブのアドレスと遠隔 LAN に限定し、侵害されたピアが持たないプレフィックスを主張できないようにしてください：

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

もう一方の拠点で、その拠点自身の遠隔プレフィックスを使って同じブロックを複製し、トンネル範囲全体を許可したくなる衝動を抑えてください。停止して新しい送信元ポートから再開するハンドシェイクは期限切れマッピングの署名であり、ハンドシェイクの時刻がそれが起きた証拠です。事業者のタイムアウトより短い間隔は、後から修復するのではなく期限切れを防ぎます。事業者が変換の挙動を変えたら、その時間も一緒に変わると想定してください。

両方向を証明し、次に復旧を証明する

検証は方向を持つため、 A から B への ping は設計の半分を証明し、戻りの経路については何も示しません。ハブで同じ送信元を意識した検索を使って応答経路を確認し、もう一方の側からテストを繰り返し、新しいハンドシェイクも証拠に加えてください。一時間アイドルだったトンネルは古いマッピングを試している可能性があるためです：

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

次に、望む成功ではなく、予想する失敗を試してください。一つの拠点の回線を再起動し、事業者側の変更のたびに運用者が必要な設計は未完成なので、どちらの端にも人が触れずにトンネルが戻ることを確認してください。主要な経路、存在すれば IPv6 の代替、そしてハブが使えないときの挙動を記録してください。ハブは今や可用性モデルの一部なので、障害時に発見するのではなく書き留めてください。