web-dev-qa-db-ja.com

iptablesのNAT）を介して送信される発信UDPパケットの暗黙的な送信元ポートマッピングを無効にする方法は？

iptablesは、tunインターフェイスから送信されるUDPパケットの送信元ポートを書き換えています。 NATルールを設定してポートXを転送しました（詳細は以下を参照）。NATの背後にあるアプリケーションがポートXで転送されたUDPパケットを受信し、その後 "別のUDPパケット（送信元ポートX）を送信することで、そのパケットは何らかの方法で送信元ポート1024を取得します。送信元ポートは、NATボックスを離れる前にすでに書き換えられています。リモートアプリは、このパケットを拒否します。 1024ではなく送信元ポートXが必要です。

「 暗黙の送信元ポートマッピング 」が行われていると思います。ポートXは1つの機能専用であり、衝突は発生しないため、これは必要ありません。NATマシンも、他のマシンもそのポートを使用しません。 iptablesにソースポートをそのまま維持させるにはどうすればよいですか？

送信元ポートが書き換えられたパケットが発信されるNATの背後にあるホストで、次のことを（一度に1回）試しましたが、すべて同じ結果になりました。

iptables -t nat -A POSTROUTING -o tun0 -p udp --sport X -j SNAT --to 10.7.0.5:X
iptables -t nat -A POSTROUTING -o tun0 -p udp -j SNAT --to 10.7.0.5
iptables -t nat -A POSTROUTING -o tun0 -p udp -j MASQUERADE

NATを実行するリモートの外向きボックス：

iptables -t nat -A PREROUTING -i eth0 -p udp --dport X -j DNAT --to-destination 10.7.0.5:X
 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
networkingiptablesroutingnetfilter
2
redfish

アプリを0.0.0.0ではなくtun0インターフェースにバインドすることで問題が解決しました。

conntrack -Eで、接続に別のインターフェイス（tun0ではない）からの送信元アドレスがあることがわかったので、それを試しました。そのため、パケットが正しい宛先に到達し、正しい送信元アドレスが書き直されたとしても、接続トラッカー内のパケットの状態は正しくありませんでした。

2
redfish