web-dev-qa-db-ja.com

一部のiptables DNATルールが再起動するまで機能しないのはなぜですか？

Iptables DNATルールが再起動するまで機能しません。サーバーを再起動すると、すべてのルールが機能します。

アーキテクチャの説明：

数十のホスト（送信者）が一部のUDPパケット（特定のポート9999で一方向）をLinuxルーターに送信します。このLinuxルーターは、iptablesを使用して、これらのパケットを複数のホスト（レシーバー）に転送します。

senderX 10.0.0.X ====> iptablesを搭載したLinuxルーター====> receiverY 10.0.1.Y

Linuxルーターには、eth1 10.0.0.1/24（送信側）とeth0 10.0.1.1/24（受信側）の2つのネットワークカードがあります。

Iptablesのセットアップ：

  • ip_forwardingがアクティブ化されます
  • すべてのデフォルトポリシーがACCEPTに設定されている
  • 送信者ごとに1つのiptablesルールが存在します。以下に例を示します。
 iptables -t nat -A PREROUTING -s 10.0.0.2 -i eth1 -j DNAT --to-destination 10.0.1.123

ネットワークセットアップ ：

ip addr show：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope Host lo
    inet6 ::1/128 scope Host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 54:9f:35:0a:16:38 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.1/24 brd 10.0.1.255 scope global eth0
    inet6 fe80::569f:35ff:fe0a:1638/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 54:9f:35:0a:16:3a brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1
    inet6 fe80::569f:35ff:fe0a:163a/64 scope link
       valid_lft forever preferred_lft forever

症状：

一連のルールを追加した後、一部のルールが機能しません。また、tcpdumpを使用すると、UDPパケットがルーティングされなくなり、パケットが拒否されていることがわかります。

tcpdump -n -i eth1 Host 10.0.0.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
16:12:58.241225 IP 10.0.0.2.56859 > 10.0.0.1.9999: UDP, length 1464
16:12:58.241285 IP 10.0.0.1 > 10.0.0.2: ICMP 10.0.0.1 udp port 9999 unreachable, length 556
  • すべてのルールをフラッシュしてiptablesに再注入しても、機能しなかったルールは機能しません。
  • サーバーを再起動すると、すべてのルールが正常に機能します。

分析が完了しました：

機能していない特定の送信者をログに記録するルールを追加しました：

iptables -t nat -A PREROUTING -s 10.0.0.2 -i eth1 -j LOG --log-prefix='PREROUTING LOG :'

しかし、このルールは何も記録しません。パケットはtcpdumpで見たので来ていますが、ログに記録されていません。また、-vオプションがiptablesにあります。このルールでカウンタが増加することはありません。

動作が停止する前に同じルールを適用すると、いくつかのログが表示されます。

質問 ：

  • IptablesのUDP転送に制限はありますか？
  • この問題のトラブルシューティング方法を教えてください。
linuxnetworkingiptablesudpdnat
4
kranteg

説明する症状は、NATルールと接続追跡エントリの間に矛盾がある場合に見られる症状と一致します。

たとえば、パケットが

-A PREROUTING -s 10.0.0.2 -i eth1 -j DNAT --to-destination 10.0.1.123

新しい接続追跡エントリを作成する必要があります。これにより、送信元と送信先のタプルと受信側のポート、および送信側の同様のタプルがマッピングされます。

着信側に一致する既存の接続追跡エントリは存在できません。存在する場合は、ルールの代わりに使用されていたためです。ただし、タプルの宛先IPを置き換えて発信側のタプルを構築すると、タプルは既存の接続追跡エントリと競合する可能性があります。

conntrackユーティリティをインストールすると、conntrack -L既存の接続追跡エントリのリストを表示します。このユーティリティには、特定の条件に一致する接続追跡エントリのみを一覧表示し、選択したエントリを削除する機能もあります。

これが実際に直面している問題である場合は、問題のある接続追跡エントリを削除すると、問題が解消されます。永続的な修正には通常、関連するNATルールを両方向のパケットに設定することが含まれます。これにより、最初のパケットがたまたま反対方向に送信された場合でも、常に目的の接続追跡エントリを取得できます。通常の場合。

5
kasperd