VPN がつながっていても応答でタイムアウトする理由

要求は届き、サーバーはログに記録し、それでもクライアントはタイムアウトを報告します。この組み合わせが意味するのは、 応答が戻り道を見つけられなかったということです。両端から同時に確認できる数少ない障害のひとつでもあり、確認は順番に行って、どれかが失敗した時点で止めてください。

要求がどこに届いたかから始める

他の何かを調べる前に、パケットがサービスに届いたことを確認してください。サーバー側のログ記録、接続カウンター、遠端での許可されたキャプチャは、どれも同じ問いに答え、それらが無ければ応答ではなくトンネルへ戻ることになります。これが、転送の問題と戻り経路の問題を分ける確認です。

要求が一度も届いていなければ、ここで止めてください。トンネル、プライベートプレフィックスへの経路、またはアクセス規則が主題であり、応答経路はまだ関係ありません。サーバーが見た送信元アドレスも記録します。それはクライアントに与えられたプールのアドレスか、変換されたアドレスのどちらかであり、この違いが後のどの確認が当てはまるかを決めます。

応答にはプールへの経路が必要

リモートアクセスのクライアントは通常プールからアドレスを受け取り、プライベートネットワークはそのプールへ戻る経路を必要とします。既定経路が自分のゲートウェイを指しているサーバーは、パケットをそのゲートウェイに渡しますが、そのゲートウェイはプールの在り処を知らないため、応答はそこで消えます。クライアントには何も戻らないのでタイムアウトに見え、それは決して出発しなかった要求と区別できません。

サーバーが自分のサブネットに使う経路ではなく、クライアントのアドレスに対して選ぶ経路を確認してください。この二つの検索は異なる答えを返すことがあり、ここで重要なのは二番目です。変換はもうひとつの設計であり、サーバーが見るものを変えます。戻り経路を単純にできる一方、元のクライアントアドレスをサーバーのログから消すため、その項目に基づく規則や報告に影響します。

サーバー側のキャプチャとゲートウェイ側のキャプチャを比較する

サーバーを出るものとゲートウェイに届くものを比較します。サーバーの出力インターフェースでのキャプチャと、トンネルゲートウェイでのキャプチャは問いの別々の半分に答え、その間のずれが損失の位置を示します。

ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0

ゲートウェイ自身が生成した要求は、別のアドレスから出て別の規則に当たるため、クライアントからの試験の代わりにはなりません。だからこそ、ゲートウェイからの ping が成功し、クライアントからの要求が失敗するという状態が同時に成り立ちます。

経路上に複数のルーターがある場合は、プールへの経路を必要とするものすべてを確認してください。拠点間の設計では、遠隔のプレフィックスを複数の機器で知っている必要がよくあり、ゲートウェイ自身がトンネルと LAN の間を転送しなければならないため、 strongSwan の転送に関する解説 は、その sysctl とファイアウォール側を扱っています。

プール、プレフィックス、担当者を記録する

記録に含めるべき事実は四つです。クライアントが受け取ったプール、必要だったプライベートプレフィックス、応答の責任を持つルーター、そして存在するなら変換の規則であり、これがあれば後日のゲートウェイ変更は調査ではなく比較になります。

そのうえで、通常のクライアントと実際のアプリケーションアカウントで再試験してください。アプリケーションの権限を広げてもパケットの戻り経路は直らず、この診断の途中でアカウントを変えると次の比較が乱れます。設計が変換に依存しているなら、サーバーのログを読む場所に文書化してください。監査記録で見慣れない送信元アドレスを見た人が、チケットから対応表を探し直さなければならない状態は避けるべきです。