☰

Warum funktionieren einige DNAT-Regeln von iptables erst nach einem Neustart?

tag-icon • tag-icon linux networking iptables udp dnat
Warum funktionieren einige DNAT-Regeln von iptables erst nach einem Neustart?

Meine iptables DNAT-Regeln funktionieren erst nach einem Neustart. Wenn ich meinen Server neu starte, funktionieren alle Regeln.

Beschreibung der Architektur:

Dutzende Hosts (Absender) senden einige UDP-Pakete (unidirektional über einen bestimmten Port 9999) an meinen Linux-Router. Dieser Linux-Router verwendet iptables, um diese Pakete an mehrere Hosts (Empfänger) weiterzuleiten.

senderX 10.0.0.X ====> Linux-Router mit iptables ====> receiverY 10.0.1.Y

Der Linux-Router verfügt über zwei Netzwerkkarten: eth1 10.0.0.1/24 (Senderseite) und eth0 10.0.1.1/24 (Empfängerseite).

Iptables-Einrichtung:

  • ip_forwarding ist aktiviert
  • alle Standardrichtlinien sind auf AKZEPTIEREN eingestellt
  • Es gibt eine iptables-Regel pro Absender, hier ein Beispiel:
iptables -t nat -A PREROUTING -s 10.0.0.2 -i eth1 -j DNAT --to-destination 10.0.1.123

Netzwerkeinrichtung :

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

Symptom:

Nach dem Hinzufügen eines Regelsatzes funktionieren einige der Regeln nicht. Und ich kann mit tcpdump sehen, dass UDP-Pakete nicht mehr geroutet und Pakete abgelehnt werden.

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
  • Wenn ich alle Regeln lösche und sie erneut in iptables einfüge, funktionieren Regeln, die nicht funktionierten, immer noch nicht.
  • Wenn ich meinen Server neu starte, funktionieren alle Regeln einwandfrei.

Durchgeführte Analyse:

Ich habe eine Regel zum Protokollieren eines bestimmten Absenders hinzugefügt, die nicht funktioniert:

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

Aber diese Regel protokolliert nichts. Pakete kommen, weil ich sie in tcpdump sehe, aber sie werden nicht protokolliert. Auch mit der -vOption in iptables sehe ich keine steigenden Zähler für diese Regel.

Wenn ich die gleiche Regel anwende, bevor sie nicht mehr funktioniert, habe ich einige Protokolle.

Frage :

  • Gibt es irgendwelche Beschränkungen für die UDP-Weiterleitung in iptables?
  • Wie kann ich dieses Problem beheben?

Antwort1

Die von Ihnen beschriebenen Symptome stimmen mit denen überein, die bei einem Konflikt zwischen einer NAT-Regel und einem Verbindungsverfolgungseintrag auftreten.

Wenn beispielsweise ein Paket übereinstimmt mit

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

Es muss ein neuer Eintrag zur Verbindungsverfolgung erstellt werden. Dadurch wird ein Tupel aus Quell- und Ziel-IP und Port auf der eingehenden Seite einem ähnlichen Tupel auf der ausgehenden Seite zugeordnet.

Es darf kein vorhandener Verbindungsverfolgungseintrag vorhanden sein, der mit der eingehenden Seite übereinstimmt, da dieser sonst anstelle der Regel verwendet worden wäre. Sobald jedoch die Ziel-IP des Tupels ersetzt wurde, um das Tupel für die ausgehende Seite zu erstellen, kann das Tupel mit einem vorhandenen Verbindungsverfolgungseintrag in Konflikt geraten.

Wenn Sie das conntrackDienstprogramm installieren, können Sie conntrack -Leine Liste der vorhandenen Verbindungsverfolgungseinträge anzeigen. Das Dienstprogramm verfügt auch über Funktionen zum Auflisten nur der Verbindungsverfolgungseinträge, die bestimmten Kriterien entsprechen, sowie zum Entfernen ausgewählter Einträge.

Wenn dies tatsächlich das Problem ist, mit dem Sie konfrontiert sind, wird das Entfernen des fehlerhaften Verbindungsverfolgungseintrags das Problem beheben. Eine dauerhafte Lösung umfasst normalerweise die Konfiguration relevanter NAT-Regeln für Pakete in beide Richtungen, sodass Sie immer den gewünschten Verbindungsverfolgungseintrag erhalten, selbst wenn das erste Paket in die entgegengesetzte Richtung gesendet wird, als dies normalerweise der Fall ist.

verwandte Informationen