WireGuard クライアントから OpenVPN クライアントへ到達できない？

両方のトンネルが接続し、各クライアントはゲートウェイに到達でき、片方がもう片方のアドレスを試した瞬間にパケットは消える。どちらのハンドシェイクにも誤りはなく、鍵を再発行しても変わらない。ゲートウェイは自分の二つのインターフェースの間で通常の暗号化されていない IP パケットを運んでいるので、プロトコル同士が理解し合う必要はまったくない。必要なのは、どのハンドシェイクも与えない三つのものだ。送信元クライアント側の宛先カバレッジ、ゲートウェイでの送信元の所有権、そして遠端側の戻り経路である。症状は三つとも同じなので、まとめて診断される。

症状は一度に一つずつ欠ける

この設計では wg1 上に 10.71.0.0/24 の WireGuard プール、tun1 上に 10.72.0.0/24 の OpenVPN プールを置き、どちらも一台のゲートウェイで終端する。検証するリクエストは 10.71.0.5 から 10.72.0.30 上の HTTPS へ向かう。以下の各手順はすべてこの一つのフローについてのものだ。各チェックの失敗の痕跡は異なるが、利用者から見れば同じ現象であり、通常は三つのうち一つだけが欠けている。

まず、両方のプールが本当にこのゲートウェイ上にあり、トンネルが存在する名前空間で転送が有効になっていることを確認する。二つのプロトコルを別々の名前空間で終端するゲートウェイは、両者の間で何も転送しない。ピア設定を読む前に、これを除外しておく価値がある。

スポーク側の宛先カバレッジを広げる

WireGuard クライアントでは、既存のピア項目が OpenVPN の宛先に対してゲートウェイを選ぶ必要があり、つまり宛先プレフィックスがそのピアの許可リストに入っていなければならない。追加しても二本目のトンネルは作られない。クライアントがそのアドレスを引くときにどのピアを選ぶかが変わるだけで、wg-quick では通常ルートがリストに自動的に従う。

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

実際の鍵とエンドポイントの行には触れず、Table = off を使う管理ツールはこのリストからルートをまったく取らないことを覚えておく。その場合、同じプレフィックスをシステムのルートテーブルに、それを所有する何者かが入れなければならず、そこでのルート欠落は許可プレフィックスの欠落とまったく同じに見える。

送信元の所有権はゲートウェイに残す

このクライアントのピア項目は、ゲートウェイ上でそのクライアントの送信元アドレスだけを引き続き所有すべきだ。許可アドレスは両方向で検査される。外向きトラフィックのピアを選ぶと同時に、入ってくるパケットの送信元がそれを送ったピアに属することを検証する。スポークが届きたいからという理由で OpenVPN プールをスポークの項目に入れるのが、トラフィックを誤った相手へ向ける誤りである。

AllowedIPs = 10.71.0.5/32

その項目はルーティングの便宜ではなく所有権の宣言として読む。クライアントが到達すべき他のものはすべてクライアントの宛先リストに属し、このピアが何を送れるかというゲートウェイの想定には属さない。

OpenVPN 側に戻り経路を与える

宛先には WireGuard の送信元へ戻る経路が必要になり、プールのクライアントでは通常 OpenVPN サーバーから push される経路として届く。持つべきクライアントにだけ push し、指示が適用されたと決めつけずに、クライアント側で受け入れられたことを確認する。

push "route 10.71.0.0 255.255.255.0"

経路の配布は認可ではない。宛先がプールの中ではなく別の OpenVPN クライアントの背後にある場合、そのクライアント自身の LAN の所有権と転送要件が設計に加わり、push された経路は前半にすぎない。指示を足す前に要件をグラフとして書き直す。どのノードがどのプレフィックスを所有し、どのノードがそこへ転送するのか。

許可したいその一つのサービスだけを許可する

転送が有効で両方のプールが経路可能なら、残る問いはポリシーだ。インターフェースの組一般ではなく、その具体的なフローに対して規則を書き、適用前にプレビューし、応答が新しい接続として遮断されないようステートフルな戻り経路を保つ。ドライランは何のコストもかからず、何が追加されるかを正確に示す。

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

これらは転送トラフィックの規則であり、二つの VPN サービスに対するゲートウェイの待ち受け規則とは別物だ。外側の UDP ポートを開けても内側のリクエストは認可されず、内側のリクエストを認可するのにゲートウェイへの無制限の SSH も転送の既定許可も要らない。宛先自身のファイアウォールと待ち受けアドレスも一致している必要がある。loopback に縛られたサービスは、最も丁寧に経路付けされたパケットでも拒否するからだ。会話の片方向しか覆わないポリシーは、要求が成功して応答が黙るという形で失敗しがちで、これは三つの結果の中で最も紛らわしい。

相互の経路は通常、送信元変換が不要であることを意味し、それは宛先で WireGuard のアドレスを保ち、ログを読みやすくする。二つのプロトコルが関わるからといって包括的な masquerading を足してはならず、何が依存しているかを知らずに既存の変換規則を削除してもいけない。そのうえで単一のフローを端から端まで検証し、許可されていない送信元やポートも一つ試す。両側でハンドシェイクが通ることは、交差経路も分離も証明しない。