ルーテッドVPNクライアントはサーバーには届くがLANホストには届かない

ルーテッドクライアントは接続できても、LANホストからの応答をすべて失うことがあります。ゲートウェイに戻り経路を追加し、転送とパケットフィルタリングを確認してください。

トンネルは上がり、クライアントはVPNサーバーにpingを送り、すぐ隣のマシン上の共有フォルダーは決して応答しません。要求は確かにクライアントを出て確かに到着しているため、クライアントの設定にこれを説明するものは何もありません。失敗しているのは戻りの経路であり、失敗している機器は通常VPNホストではなくLANゲートウェイです。応答パケットをたどれば、この種の症状がすべて説明できます。

要求ではなく応答を追う

VPNサーバーはクライアントのパケットを復号し、送信元フィールドにクライアントのアドレスを残したままLANへ転送します。宛先ホストはそのアドレスに応答し、ここで自分のルーティングテーブルがすべてを決めます。そのデフォルトゲートウェイはトンネルプールを何も知らないため、応答はインターネットプロバイダーの方向へ出て、その経路のどこかで破棄されます。

クライアント側の症状は、拒否もリセットもなくただ何も返らない静かなタイムアウトです。共有の参照は固まり、pingは応答なしと報告し、サーバーは自分の仕事を果たしているのでログは正常に見えます。

戻り経路はホストが見る場所に置く

すべてのLANホストは自分のデフォルトゲートウェイに問い合わせるので、 トンネルプールがどこにあるかを知る必要がある唯一の機器はゲートウェイです。そこに静的経路を追加すれば、各ホストは手を加えずに正しい経路を引き継ぎます。

ゲートウェイが自分のアドレスをDHCPオプションとして配布しているなら、その方法で経路も配布すれば新しいマシンが自動的に取り込みます。そうでなければ経路は一つの設定ファイルに置かれ、次の再構築で消えます。

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

送信元NATが直ったように見える理由

クライアントプールをVPNサーバーのアドレスの背後にマスカレードすると、パケットからクライアントのアドレスが消えることで問題が解消します。応答はトンネルへの到達方法をすでに知っているサーバーに戻り、すべてが機能します。代償は、内部ホストがクライアントを識別できなくなり、すべての接続が一台のマシンから来たように見えることです。

その交換は、たとえばベンダーのアプライアンスに静的経路を設定できないときなど、正しい場合もあります。ルールは、/24向けに書いたルールがプールの/16への振り直しの日から一致しなくなり、最初の兆候が接続しても何にも届かない新しいクライアントの一群になるため、現在のプールより広くしないでください。

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

クラウド経路には三つの設定が必要

VPCでは、サブネットにクライアント範囲への経路がまったくないため、同じ欠落が別の形で現れます。ルートテーブルにはトンネルプールをインスタンスのネットワークインターフェイスに向けるエントリが必要で、そのインターフェイスでは、自分のアドレス以外を送信元とするパケットをプラットフォームが受け入れられるよう、送信元と宛先のチェックを無効にする必要があります。セキュリティグループとネットワークACLも、両方向でプールを許可しなければなりません。

省略するたびに異なる部分的な障害が生じます。ルートテーブルのエントリを省くと、プライベートインスタンスは応答をプールへ戻せないサブネットに応答します。チェックが有効なままだと、インスタンスがすでに送信した後にプラットフォームが応答を破棄します。セキュリティグループのルールがなければ要求自体が届かず、クライアントは一層手前でタイムアウトを見ます。

チェックはこの順序で実行する

ルーティングを疑う前に、転送しないホストも同じ静かな形で失敗するため、転送とフィルターポリシーを確認してください。次に、厳格なフィルターは予期しない方向から来る応答を破棄することがあるため、トンネルを運ぶインターフェイスで有効な逆経路設定を読みます。

クライアントがLANホストにpingを送っている間にそのホストで取得したキャプチャで締めくくります。対応する応答のない要求が届けば戻り経路が証明され、決して届かない要求なら障害はサーバーかトンネルに戻ります。

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

送信元と宛先のチェックは エラスティックネットワークインターフェイスガイドに記載されています。トンネルトラフィックを実際に運ぶインターフェイスで設定し、同じインスタンスに接続された無関係なアダプターには設定しないでください。

関連記事