VPNクライアントの背後にあるサーバーがトンネル経由で応答する理由

VPNクライアントも動かしているホストへの受信接続は、非常に独特な形で失敗します。ハンドシェイクは届き、デーモンは応答するのに、クライアントには何も戻りません。ポートを妨げているものはありません。応答はトンネルから出ていきました。トンネルがデフォルトルートを所有しているため、カーネルは応答を宛先でルーティングし、要求がどこから来たかの記憶ではルーティングしないからです。デーモンは正常で、ポートも開いています。

応答は記憶されず、ルーティングされる

デフォルトルートを設定するVPNクライアントは、メトリックで、あるいは空間をより具体的な二つの半分に分けることで、LANゲートウェイを上回るエントリを追加します。外向きのパケットは今やトンネルのインターフェースを選びます。カーネルは、応答しているパケットがもともとどこから到着したかを決して尋ねません。その一つの欠落が、続くすべての症状を説明します。

往路は宛先でルーティングされ、復路も同じです。応答は公開クライアント宛てで、トンネルは喜んでそれを運びます。遠端は自分が所有しない送信元のパケットを受け取り、破棄し、元のクライアントは時間切れまで待ちます。

厳格な逆経路フィルタリングは、デーモンが読む前に受信パケットを落とすことがあります。まずそのカウンタを確認してください。フィルタによる破棄とルーティングの誤りは外から見ると同じだからです。

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

最初のコマンドは、今どのデフォルトルートが勝っているかを示します。二番目は厳格なフィルタリングが全体に適用されるかインターフェースごとかを報告し、三番目は関与しうる転送チェーンの規則を示します。

戻り経路を保つ三つの方法

サービスの宛先をトンネルから除外するのが最も狭い選択肢です。LANゲートウェイに向けたホストルートと、すべてのアドレスではなく物理アドレスに束縛したデーモンが、その一つのフローをトンネルの外に保ちます。変更はローカルで、元に戻すのも簡単です。

ポリシールーティングが一般的な答えです。送信元アドレスやファイアウォールマークをキーにした規則が、デフォルトがWANゲートウェイを指すテーブルを選び、ホスト自身の接続はトンネルを使い続けます。優先度を明示して、後で規則が覆い隠されないようにしてください。

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

最初の二つのコマンドは、公開アドレスを送信元とする応答のための代替経路を組み立てます。三番目は、まさにその送信元と宛先がどの経路を取るかをカーネルに尋ねるもので、これで規則に効果があるかを確認できます。

送信元変換は三番目の選択肢であり、サービスの前で既にNATを行っているルーターの前で生き残る唯一のものです。応答はそのルーターへ戻らなければならず、WANインターフェースへのマスカレードがそれを実現しつつ、クライアントをサービスのログから隠します。接続後にデフォルトルートを手で置き換えるのは診断です。クライアントは次の再接続でテーブルを書き換えるからです。

そのマシンがLANのためにもルーティングする場合

同じ障害は、ホストが背後の機器のためにルーティングするときに一ホップ先で現れます。受信接続は、戻り経路がトンネルしかない内部機器へ転送され、応答はプロバイダーのアドレスから外部クライアントに届きます。内部機器はその間ずっと正しく動作しています。

すると接続追跡は、記録したことのないフローへの応答を見て破棄します。宛先変換が受信接続を機器へ届け、送信元変換が応答をルーター自身から出たように見せます。

転送ポートをWANに残しつつ、ルーター自身のトラフィックはトンネルを使うポリシールートが、より整った等価物です。送信元変換がなければ応答は外部クライアント宛てになり、内部機器にはそのアドレスへの経路がまったくありません。

原因を切り分ける三つの調査

三つの調査を行います。インターネットからそのマシンへの接続、そこから公開ホストへの接続、名前解決です。最初の二つが食い違えば、戻り経路が原因です。名前が両方向で失敗するなら、リゾルバーは別の障害で、単にトンネルを共有しているだけです。

まずルーティングの問題を直し、それから名前を見てください。両者を混同することが、動作しているサーバーを壊れたリゾルバーのせいにする道です。

例外がどのインターフェースを指すかを記録し、設定をバージョン管理下に置いてください。アップグレード後に名前が変わるインターフェースに対して書かれた規則は、今日は通り、次の再起動後に失敗します。