iptables は tun インターフェイスから発信する UDP パケットの送信元ポートを書き換えます。 NATルールを設定し、ポートXを転送しました（詳細は以下を参照）。これは、NATの背後にあるアプリケーションがポートXから転送されたUDPパケットを受信してから、他のUDPパケット（ソースポート1024を取得するためのソースポート方式が必要）を送信して「応答」する場合です。送信元ポートが再割り当てされました。 - NATedボックスを残す前に作成されました。リモートアプリケーションは1024以外のソースポートXを必要とするため、このパケットを拒否します。
私の考えでは」暗黙的なソースポートマッピング「が発生しています。ポートのため必要ありません。
送信元ポートを書き換えるパケットが開始された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
ベストアンサー1
この問題は、0.0.0.0 ではなく tun0 インターフェイスにアプリケーションをバインドすることで解決されました。
conntrack -Eで接続に他のインタフェース（tun0ではない）のソースアドレスがあることがわかったので、これを試しました。したがって、パケットが正しい宛先に到達し、正しい送信元アドレスが書き換えられても、接続トラッカーのパケット状態は正しくありません。