WireGuardのハンドシェイクは成功するのにサービスが動かない

ハンドシェイクは完了し、クライアントは新しい転送カウンタを表示し、それでも同じサーバー上のサービスへの要求は失敗する。この組み合わせが人を混乱させるのは、トンネルが明らかに動いているからだ。証明されていないのはローカル配送であり、パケットこそホストに届いたものの、ホストはそれを正しいソケットで受け入れ、応答する権限を持つプロセスに渡す必要がある。この三つのチェックポイントを順に確認しよう。

当てはまらない最初の項目で止まり、他の項目のためにルールを追加しないこと。

ハンドシェイクが証明するのはトンネルだけ

WireGuardのハンドシェイクはピア間で鍵を確立し、各ピアが列挙した範囲のトラフィックを許可する。サーバー上でどのプロセスが待ち受けているかは何も語らず、ホストのファイアウォールが自身のアドレス宛のパケットを受け入れるかどうかも語らない。

見落とされやすいのは、ホスト自身へのトラフィックはローカル入力であり、ホストを通って別の場所へ向かうトラフィックは転送であるという最後の区別だ。両者は異なるファイアウォールチェーンと異なる設定で扱われる。間違ったチェーンを調べると午後が消え、無害に見えるカウンタが返ってくる。

待ち受けとルートを読む

クライアント側では、サーバーのトンネルアドレスがトンネルへルーティングされていることを確認する。サーバー側では、クライアントが使っているアドレスにソケットが存在し、その背後のプロセスが意図したものであることを確認する。

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

127.0.0.1 で待ち受けるものは、ファイアウォールが何を許していても、10.66.0.1 宛の要求には決して応答しない。ワイルドカードアドレスで待ち受けるものは、ルールが遮断しない限り応答する。したがってソケット一覧は、どのルールも調べる前に半分のケースを片付ける。ポートとアドレスの組み合わせが、要求が到達できるかどうかを決める。

クライアントが使うアドレスと、サーバーがトンネルインターフェースで実際に持つアドレスを比較する。どちらかの側の古い設定は、そのアドレスを持たないピアへ正しくルーティングされた要求を生む。

転送ではなくローカル入力のルールを適用する

パケットが届きソケットが存在するなら、残る境界は入力ポリシーである。転送を許可するルールはローカル配送を許可せず、一つのインターフェースに限定されたルールは、期待するトンネルインターフェース名と一致しないことがある。

ホストを開くのではなく、目的のサービスへ許可した一つのポートで試す。次に、許可リスト、アカウント要件、特定のホスト名へのバインドがネットワークの正常な配送を拒否することがあるため、アプリケーション自身の認可を確認する。

証明書の検証は有効なままにしておく。予期しない証明書の身元は、どのホストが応答したかという情報であり、回避すべき障害ではない。クリックして通過すると、誤ったサービスを特定する唯一の手がかりが隠れる。

名前・サイズ・身元の失敗を分ける

アドレスでは動くが名前では失敗するサービスはDNSの問題であり、修正はファイアウォールではなくクライアントへ配布するリゾルバ設定にある。小さな要求には応答するが大きな応答で止まるサービスはパケットサイズとMTUを示しており、これはまったく別の調査である。

誤ったホスト名を示すHTTPSエラーは通常、要求が別のサービスに届いたことを意味し、多くの場合プロキシや別の待ち受けがそのポートを占有しているためだ。証明書のサブジェクトを読み、到達しようとしたホストと比較する。この比較は何のコストもかからず、調査を終わらせることが多い。

ソケット、入力ルール、アプリケーションポリシーのどれで失敗したかを記録する。この一行がネットワーク障害と認可の判断を区別する。問題ではなかったポートを次の人が開けるのも防ぐ。