WireGuardピアが誤ったWANから出ていく：五つの確認を順番に

アップリンクが二本、ゲートウェイが一台、そしてトラフィックが予備回線に繰り返し現れるWireGuardピア。ハンドシェイクはその間ずっと正常なままです。だからこそ、この症状をルーティングの不具合ではなくWireGuardの不具合と読み違えやすいのです。

以下の確認を順番に進めてください。どれにも停止条件があり、先に飛ばすとたいてい自信に満ちた間違った答えになります。

ハンドシェイクと転送フローを切り分ける

暗号化されたピア交換には、サーバーの公開アドレスへのエンドポイント経路があります。転送されるクライアントトラフィックは宛先が異なり、マークやポリシールールで選択されることがあります。同じインターフェースを共有する二つのルーティング判断です。一方を他方の証拠として扱うのが最初の誤りです。

ハンドシェイクから推論している自分に気づいたら、すぐに止めてください。それはエンドポイント経路についての証拠にすぎません。

ポリシールールを読む。デフォルトテーブルではない

デフォルトテーブルは、どのポリシールールにも一致しないときに何が起きるかを示します。送信元、マーク、宛先でルーティングするゲートウェイでは、決めるのは別の場所にあるルールです。素のテーブルは完全に妥当に見えても、実際の選択はその上で行われています。

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

ポリシールールと、それが指すテーブルを読みます。そのうえで、テストフローにどのルールが一致するかを確認します。意図したアップリンクをもはや運んでいないインターフェースを参照するルールは、細部ではなく発見です。最後の経路検索は、テーブルを読んで推測するよりはるかに速く答えを示します。

マークと変換を一緒に確認する

ポリシールーティングは、チェーン内でより前の段階で設定されたパケットマークに依存します。マーク付けのルールがあなたのトラフィックを取りこぼすと、フローはメインテーブルへ落ち、そこにある既定の経路で出ていきます。転送パケットは、ローカルで生成されるトラフィック向けに書かれたチェーンをしばしば飛ばします。

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

変換は、フローを運ぶアップリンクと一致していなければなりません。パケットが予備回線から出ていくのに一次アドレスへ変換するルールは、フローが一度も使わなかったインターフェース宛ての応答を生みます。変換ルール自身のインターフェース条件を確認してください。無条件のルールは二本目のアップリンクが使われるまで機能し、その後は断続的に見える形で失敗します。

どのインターフェースが応答を運ぶかに注目する

一つのリクエストを実行している間に、両方のアップリンクでキャプチャします。どちらのインターフェースがリクエストを運び、どちらが応答を運ぶかを記録します。非対称な経路は、予測するより見るほうがはるかに簡単です。

応答が誤ったアップリンクから届くなら、問題はWireGuardからコネクション追跡や変換へ移っています。ピア設定の変更では直りません。

戻り道を用意して一つだけ変える

ゲートウェイでポリシールールを編集する前に、コンソールかアウトオブバンドのアクセスを確保してください。変更は一つだけ行い、同じ許可済みの宛先を試し、それから再接続してハンドシェイクが意図したエンドポイント経路をまだ使っていることを確認します。二つ目のアドレスファミリーにも数値テストを加えてください。v4のみのポリシーは同じ誤りを残すからです。

各フローがどのアップリンクを使ったかを記録します。その記録が、次回の報告を丸半日の作業ではなく二分の確認に変えます。WireGuardの名前空間とルーティングに関する解説は、エンドポイント経路をトンネル化されたトラフィックから意図的に分離する方法を説明しており、通常はデフォルトルートの回避策をコピーするよりクリーンです。