クライアントは接続し、トンネルはゲートウェイまで ping を運び、その先では何も応答しません。この状態は、保護されたネットワークへのアクセスだけを目的としたゲートウェイでは正常であり、フルトンネルの出口として宣伝されているゲートウェイでは故障です。ルールを変更する前に、どのサービスが約束されていたかを確認してください。次に、一つの公開要求を、停止しうる四つの箇所に沿って追跡します。一つの要求と一つのパケットキャプチャは、一ページの推測より多くを決着させます。

インターネットへの出口がそもそも設計だったかを確認する

スプリットトンネルのプロファイルは保護されたサブネットだけを VPN に流すため、通常の閲覧はローカルリンクを通り、ゲートウェイには一切触れません。フルトンネルのプロファイルはトンネルにデフォルトルートを入れるため、ゲートウェイが経路全体の責任を負います。どちらも正当な設計であり、両者を混同すると、存在しない故障報告が生まれます。何かをテストする前にクライアントが広告するルートを読み、ルートテーブルがチケットの通常誤った問いに答えてくれることを確認してください。

クライアントが入れるものが、常にプロファイルの意図どおりとは限りません。プッシュされたルートは、メトリックの小さいローカルルートに上書きされることがあり、デフォルトルートを追加しながら LAN ルートを残すクライアントは、そのサブネットではスプリットトンネルのように振る舞います。

一つの公開要求を追跡する

一つの宛先を選び、クライアントから外側へ追跡します。クライアントでは、パケットが本当にトンネルを選んでいるか、どのローカルアドレスを送信元にしているかを確認します。次にゲートウェイで、パケットが届いているか、パブリックインターフェースから出ているかを確認します。これらの答えのそれぞれが、原因のカテゴリを一つ丸ごと排除します。

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

ゲートウェイがパケットを一度も見ないなら、クライアントのルートかトンネルの選択が誤っています。届いても出ていかないなら、問題はゲートウェイ側にあり、残り三つの確認が当てはまります。

転送、ルート、変換を確認する

strongSwan に付属する転送の手引きは、どのトンネル種別のゲートウェイにも当てはまります:カーネルにインターフェース間のパケット移動を許可する必要があり、使えるルートがインターネットへ向いている必要があります。さらにファイアウォールポリシーが通信を許可し、送信元アドレスはパブリック側が応答できるものでなければなりません。変更されずにインターネットへ転送されたプライベートなクライアントアドレスは、決して応答を受け取りません。

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

送信元変換が通常は欠けている部分です。これがあれば、ゲートウェイはクライアントの送信元を自分のパブリックアドレスに書き換えてフローを追跡し、なければ応答の行き先がありません。クラウドプラットフォームは第二の境界を加えます:インスタンスのルートテーブルやセキュリティグループが、ゲストのファイアウォールが許可した通信を落とすことがあります。その境界は見落としやすく、ゲストのシステムは内側からは正しく設定されているように見えます。

非対称な構成では、逆経路フィルタリングも有効なパケットを捨てることがあります。そのルールのカウンタを読み、問題ないと決めつけないでください、パブリックインターフェースの厳格な設定は、ルートテーブルが予測するのとは別の経路で届く通信を拒否します。

応答経路とリゾルバは別々の答え

要求だけでなく応答も見てください。要求が変換されて出ていき、応答が変換されたフローへ戻るなら、アプリケーションがまだ失敗していても転送は機能しており、次の調査はアプリケーションか DNS の担当です。

HTTP エラーを返すサイトは、インターネットへの転送が機能している証拠です。アドレスでのアクセスが動くのに名前が解決できないのは、リゾルバの問題であり NAT の問題ではありません。

的確な修正の後、クライアントと意図的に制限したプライベートリソースを再テストします。インターネットアクセスを与えても、ゲートウェイに接続されたすべてのネットワークへのアクセスを静かに広げてはいけません。

関連記事