VPNは接続できるがLAN機器に到達できない：確認すべきこと

トラフィックはトンネルに入り、ゲートウェイは自分のアドレスに応答し、その先の何も応答しない。このパターンはよくあることであり矛盾ではないが、ゲートウェイからの応答はトンネルが終端したことを証明しても、その先に宛てられたパケットに何が起きるかについては何も証明しない。二つのテストは同じマシン上の異なるコード経路を通る。

これからはゲートウェイの向こう側で何かを試す。転送がどれほど壊れていても、ゲートウェイ自身のアドレスは応答し続ける。

ゲートウェイは自身のスタックから応答する

ゲートウェイ宛てのパケットはローカルの入力経路に渡され、そこでカーネルが待ち受けソケットが受け入れるかを決める。ゲートウェイの背後のホスト宛てのパケットは代わりに転送経路に渡され、そこでは別の一連の検査が適用される。転送は完全に無効にできるし、カーネルが有効にした後に、トンネルに一切言及しないフィルタ規則がそれを拒否することもある。そのどれもゲートウェイ自身の応答には影響せず、だからこそこの症状はこれほど確実に誤解させる。

トンネル経由で到達する管理ページも第一のカテゴリに属する。それらはトンネルについての証拠であり、その背後のネットワークについての証拠ではない。

フローを最初に落とす境界まで追う

クライアントから始め、フローが使う経路と送信元アドレスを確認する。次にゲートウェイで、まさにそのフローが到着するのを見て、さらに同じフローがLANへ出ていくのを見る。まったく到着しないなら、問題はクライアント側かトンネルの許可プレフィックスにある。到着しても決して出ていかないなら、問題は転送か前方経路のフィルタにあり、キャプチャはすでにどちらかを示している。

同じテストをゲートウェイから実行すると、ゲートウェイ発のパケットは送信元も戻りの要件も異なるため、面白い半分が隠れる。各手順でクライアントのフローを、その送信元アドレスのまま使う。間違ったインターフェースで取ったキャプチャは自信満々のナンセンスを生む。

戻り経路とホストのファイアウォールは別々に失敗する

パケットがホストに届いた後、さらに三つのことが成り立たねばならない。サービスがパケットの送られた先のアドレスで待ち受けていること、ホストのファイアウォールがそれを受け入れること、そして 応答にはクライアントプールへ戻る経路がなければならない。最後のものはよく失敗するが、それはホストの既定経路がトンネルの範囲を聞いたこともないルーターを指しているからだ。結果は、ホストから見て確立し、逆方向では静かに死ぬ接続になる。

クライアントから送って戻りを観察し、戻り経路を意図的に試す。片方向のキャプチャは、一時間の推測では解決しないことを数秒で決着させる。

クライアントの送信元アドレスで各ホップを確認する

チェックを順番に実行してすべての出力を残すのは、価値が単一の行ではなく比較にあるからだ。以下のコマンドは送信元アドレスを固定し、選ばれた経路を示し、転送の両側をキャプチャする。自分のLANホストとトンネルインターフェースに置き換えてほしい。

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

経路クエリは、クライアントがそのパケットをそもそもトンネルに送るかを示し、pingはホストから何か戻ってきたかを示す。二つのキャプチャを比べれば、トンネルインターフェース上のフレームに対応するものがLANインターフェースにない場合はサービスの障害ではなく転送の判断だと分かり、到着と出口が分かれる。両方のキャプチャが要求を示し、片方だけが応答を示すなら、残る容疑者は戻り経路だ。

どのアドレスが応答し、どの転送先が失敗したかを記録する。その一文が、サーバーに到達できないという主張ではなく、実行可能な報告にする。