一つの経路を証明する二つのピアによるWireGuardテストの作り方

デフォルトルート、LANプレフィックス、DNS、ファイアウォール例外をまとめて載せたWireGuardテストでは、どれが壊れたのか分からない。二つのピア、一組のアドレス対、一つの許可サービスまで削れば、障害の隠れる場所はなくなる。退屈なベースラインこそが診断だ。まずそれを組む。十五分で済み、そうでなければ推測に費やす午後を節約できる。

ベースラインが証明するのは、多くの人が思うより狭い範囲だ。二つの識別情報が一致し、UDPが待ち受けポートに届き、許可された一つの宛先がリクエストを運ぶことだけを証明する。転送、NAT、LANルート、DNSは後から一つずつ追加する別機能だ。

鍵、アドレス、単一のエンドポイント

各システムで鍵ペアを生成し、公開側の半分だけを互いに渡す。wg genkey | tee privatekey | wg pubkey > publickeyが文書化されたワンライナーで、秘密鍵は保護できるファイルに残る。所有する他のどの設定にも現れない範囲からトンネルアドレスを選ぶ。たとえば10.99.0.1/24と10.99.0.2/24だ。どのアドレスがどのマシンに属するかを書き留めておくべきだ、以降の確認はすべてその対応表に依存するからだ。

秘密鍵は決して移動しない。テストのために秘密鍵を反対側へコピーする必要があるなら、そのテストはすでに間違っている。二つのシステムがNATの背後にある場合、少なくとも片方に到達可能なUDPポートが必要で、もう片方はそこを指すEndpointを持つ。公開アドレスとポートは、51820についての想定ではなくメモに書く。

異なる外部ポートにマップするポートフォワードは、Endpointがそれに一致する限り問題なく動く。ここでの不一致はエラーではなく沈黙を生む。だからこそ、ワイヤ上でデバッグする前に紙の上で確認する価値がある。

wgに属するフィールドとそうでないもの

中核となるフィールドは少ない。Interfaceの下のPrivateKeyとListenPort、Peerの下のPublicKey、AllowedIPs、Endpointだ。AddressとDNSはwg本体ではなくwg-quickに属し、同じ設定を別のツールへ移した瞬間にこの区別が効いてくる。

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPsは同時に二つの役割を担う。どの宛先をトンネルに入れるかを選び、到着時にその送信元アドレスを使うことをピアに許可する。そのため反対側のミラーエントリは、あなたのトンネルアドレスを正確に指定する必要がある。間違ったピアへの/32はルーティングの問題として読まれ、認可の問題のように振る舞う。WireGuardクイックスタートでは、フィールド名を比べたいときに同じ二つのピア構成が標準的な表現で示されている。

アイコンではなくハンドシェイクを読む

インターフェースを管理しているものを通して起動し、ステータスランプではなく状態を読む。wg showはピアごとの最新ハンドシェイクとバイトカウンタを表示する。数分以内のハンドシェイクがあれば、鍵、エンドポイント、UDP経路がすべて機能している。片方向にしか増えないカウンタはそれ自体が答えであり、ハンドシェイクが起きない場合とは別の障害だ。

二つの障害は別の調査を意味する。ハンドシェイクがまったく起きないなら、鍵の不一致、誤ったEndpoint、UDPの遮断、あるいはハンドシェイク自体を落とすファイアウォールが疑わしい。ハンドシェイクが成功するのにデータが届かないなら、AllowedIPs、トンネルアドレスで待ち受けていないサービス、あるいはLANにはポートを許可するがトンネルインターフェースには許可しないホストファイアウォールが疑わしい。これはシステムの別々の半分であり、ルールを変える前にベースラインが両者を切り分ける。

許可された一つのサービスを証明し、次に逆方向

もう一方のピアのトンネルアドレスへ、応答するはずのサービスでリクエストを送り、pingより良いものを選ぶ。ICMP応答の欠如はトンネルの障害ではなくホスト側のフィルタリングかもしれないので、無言のpingはどちらの方向も証明しない。開いていると分かっているポートへのTCP接続、またはデータを返すリクエストなら、解釈できる答えが得られる。

逆方向は独立した結果を持つ別のテストとして実行する。二つの方向はファイアウォールとAllowedIPsのエントリが別々で独立に失敗しうるからだ。ハンドシェイクが動いてリクエストが通らないなら問題はトンネルではなくデータ経路にあり、AllowedIPs、待ち受けサービス、ホストファイアウォールのいずれかを疑って、転送、NAT、DNSを足す前に直すべきだ。

ベースラインを基準として保つ

動作するトポロジーとプロファイルのソースを復元できる場所に保存し、公開サービスと同期するディレクトリには置かない。次に一つずつ機能を足し、そのたびに元のリクエストを繰り返す。転送、NAT、LANルート、そして最後にDNSという順で、テストを壊した追加が今なら特定できる、他の何も動いていないからだ。

アイコンを緑にするだけのベースラインは、次の障害をどの追加が起こしたかを何も教えてくれない。唯一許可された経路を基準として動かし続け、その後の変更はすべてそれと比較する。