WireGuard のデフォルトルートループ：エンドポイント経路を見つける

インターフェースは起動し、ピアの設定も正しく見えるのに、ハンドシェイクが一度も完了しない。トンネル経由でデフォルトルートを追加するのが、これをよく引き起こす手順だ。同じルートテーブルが、トンネル自身の暗号化パケットの行き先を決めるようになり、その答えはトンネルの中へ戻ってしまう。内側のパケットを運ぶはずの外側のパケットを運べるものがなくなるので、接続は始まる前に止まる。修復は小さいが順序があり、編集よりも検証のほうが重要だ。

ルートを変える前にループを確認する

ピアの現在のエンドポイントアドレスを読み、そのアドレス宛てのパケットがどこへ行くかをルーティングスタックに尋ねる。答えがトンネルインターフェースを指すなら、ループは確認済みで、これ以上の診断は要らない。何かに触る前に両方の出力を変更記録に残す。修復後の比較は同じ二つのコマンドだからだ。ループは一度見れば分かりやすい。難しいのは、それが起きている間もインターフェースが正常に見えることだ。

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

その取得にポリシールールも含める。メインテーブルで正しく見えるデフォルトルートでも、マーク付きまたはマークなしのトラフィックに別のテーブルを選ぶルールに負けることがあり、ルートテーブルが問題なさそうに見えてもループは再び現れる。

トンネル経路ではなくエンドポイント経路を読む

エンドポイント経路とは、暗号化されたデータグラムがピアの公開アドレスへ向かう経路であり、トンネルが存在する限りトンネルの外に留まらなければならない。トンネル経路とは、ピアが運ぶことを許されたすべてだ。この二つの経路は一つのルートテーブルを共有しており、まさにそのために一つの全捕捉エントリが両者を互いの中へ潰してしまう。トンネルのトラフィックとトンネル自身の転送とを切り離すことが設計上の問題のすべてであり、対応するどのツールもどこかで少しずつ違う解き方をしている。

インターフェースが両方を運ぶなら、両方のアドレスファミリーを別々に確認する。動作する IPv4 の除外は、IPv6 のエンドポイントにまだ到達できるかどうかを何も語らない。混在構成は、ピアの IPv6 アドレスが選ばれるまで動いているように見えることがある。

一つの一貫した変更でエンドポイント経路を戻す

対応するアプローチは二つあり、それらを混ぜることが、動作する構成を予測不能にする道だ。一つ目は、インターフェースを所有するツールにトンネル全体を任せることだ。wg-quick にはデフォルトピア範囲の専用処理があり、別のテーブル、ポリシールール、ソケットマークを設定するので、外側のパケットがトンネルの外に保たれる。その仕組みはそのまま残し、半分だけを手で再現してはいけない。手動で追加したデフォルトと、すでにマークとルールを設定する管理ツールを混ぜた構成は、再接続後に失敗しやすい。管理ツールが、手動の手順が前提にしていた状態を書き換えるからだ。

二つ目は手動設計で、エンドポイントに物理ゲートウェイ経由の明示的なホストルートを与える。そのルートをデフォルトより前に追加し、古いエントリが勝たないよう追加ではなく置換し、その後で検索を確認する。

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

検証し、それから戻る道を残す

進むハンドシェイクのタイムスタンプが最初の証拠であり、単に存在するインターフェースより強い。トンネル経由のアプリケーションテストで続け、次に意図的にインターフェースを落として、何も指さないデフォルトルートを保持するのではなくホストが使える状態に戻ることを確認する。その最後の手順を人は飛ばしがちで、再起動後にマシンが取り残されるかどうかを決めるのはそれだ。

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

その前に、現在のルーティング状態を保存し、トンネルに依存しない入り口があることを確かめる。コンソール、帯域外管理アドレス、あるいは現地の同僚だ。デフォルトルートを失った遠隔マシンは、たった今失った接続では復旧できない。ランブックで最も安全な手順は、最初のコマンドの前に取るものだ。