web-dev-qa-db-ja.com

UDPパケットはVPNインターフェースに到達し、プロセスに配信されません

VPNによってサーバーYに接続されているサーバーX（45.55.245.182）があります。 XのVPNインターフェースはip10.200.0.2のtap0です。 YのVPNインターフェースは、IP10.200.0.1のtap0です。サーバーYでnetcatを実行して、UDP35000をリッスンします。

nc -lu 10.200.0.1 35000

サーバーXでは、ポート35000のパケットが次のiptablesルールでDNATされます。

iptables -t nat -A PREROUTING -p udp --dport 35000 -j DNAT --to-destination 10.200.0.1

サーバーYのtap0インターフェイスでtcpdumpを実行すると、パケットが期待どおりに到着したことが示されます。

11:54:44.000610 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.200.0.1 tell 10.200.0.2, length 28
11:54:44.000638 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.200.0.1 is-at fa:0f:00:1a:57:59 (oui Unknown), length 28
11:54:44.154702 IP (tos 0x8, ttl 47, id 52840, offset 0, flags [DF], proto UDP (17), length 34)
    hotnet-213-57-17-185.hotnet.net.il.24740 > 10.200.0.1.35000: [udp sum ok] UDP, length 6

セットアップを示す図を参照してください： enter image description here

ただし、サーバーYでリスニングネットキャットがデータを取得していることを確認できません（クライアントでEnterキーを押しても、Yの画面には何もエコーしません）。

何が問題になる可能性がありますか？

iptablesvpndnat
1
rlib

問題の最も可能性の高い説明はrp_filterであり、これはデフォルトで有効になっています。サーバーYはtap0でパケットを受信しますが、そのルーティングテーブルによると、パケットは別のインターフェイス（おそらくeth0）に到着するはずでした。

これが本当に問題である場合、解決策はrp_filterに対してtap0を無効にすることです。まず、これを試して、問題が解決するかどうかを確認します。

echo 0 > /proc/sys/net/ipv4/conf/tap0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

サーバーYにパケットを受け入れるようになったら。間違ったIPアドレスからの送信が原因で、クライアントが応答を拒否するという問題が発生する可能性があります。その問題には さまざまな解決策 があります。

サーバーXでSNATを使用することを選択した場合、両方の問題が解決されます。ただし、2つの注意点があります。

  • サーバーYはクライアントのIPアドレスを知りません。
  • クライアントへの応答は、サーバーXを経由してクライアントに戻るまでに長い時間がかかる必要があります。これは、クライアントに直接ルーティングするよりも効率が悪い場合があります。
2
kasperd

送信元アドレスを実際にパケットが到着した10.200.0.2に設定すると、問題が解決しました。

iptables -t nat -A POSTROUTING -p udp --dport 35000 -j SNAT --to 10.200.0.2
0
rlib