☰

iptables NAT-Problem mit Verbindungen mit RST-Paketen

tag-icon • tag-icon linux vpn iptables nat
iptables NAT-Problem mit Verbindungen mit RST-Paketen

Ich habe ein Setup, das ungefähr wie folgt aussieht.

Anwendung > Lokaler Server > VPN > Remote-VPN-Server > Lizenzserver

Die Anwendung und der lokale Server befinden sich in meinem LAN. Der lokale Server stellt über ein VPN eine Verbindung zum VPN-Server des Unternehmens her. So kann der lokale Server den Lizenzserver des Unternehmens sehen.

Ich weise meine Anwendung an, auf meinem lokalen Server eine Lizenz zu suchen und füge meinem lokalen Server die folgenden iptables-Regeln hinzu.

iptables -F
iptables -t nat -F
iptables -X

licServer=$(host licserver | awk '/has address/ { print $4 ; exit }')
iptables -t nat -A PREROUTING -p tcp --dport 1642 -j DNAT --to-destination $licServer:1642
iptables -t nat -A PREROUTING -p tcp --dport 57109 -j DNAT --to-destination $licServer:57109

iptables -t nat -A POSTROUTING -j MASQUERADE

Dies scheint zu funktionieren und die Anwendung erhält erfolgreich eine Lizenz. Allerdings ist die Aushandlung im Vergleich zu einer lokalen Sitzung (die meine Regeln nicht verwendet) sehr langsam.

Wenn ich mir Wireshark anschaue, sehe ich, dass die Anwendung einige ungewöhnliche Nachrichten sendet. Es werden nie FIN-Pakete gesendet, stattdessen sendet die Anwendung RST-Pakete. Mir fällt auf, dass jedes Mal, wenn sie eines dieser RST-Pakete sendet, fast genau 10 Sekunden gewartet wird, bevor die nächste Nachricht gesendet wird. Ich glaube nicht, dass das ein Zufall ist, da das CLOSE_WAIT-Timeout 10 Sekunden beträgt.

Eine typische Verhandlung würde etwa wie folgt beginnen

t=0 Application:A > Local Server:1642 [SYN]
t+0.1 Local Server:1642 > Application:A [SYN, ACK]
t+0.1 Application:A > Local Server:1642 [ACK]
t+0.1 Application:A > Local Server:1642 [PSH, ACK]
t+0.2 Local Server:1642 > Application:A [PSH, ACK]
t+0.2 Application:A > Local Server:1642 [RST, ACK]   (10 second wait here)
t+10.2 Application:B > Local Server:57109 [SYN]

... und so weiter. Immer wenn ein RST auftritt, wartet es weitere 10 Sekunden.

Wenn die Anwendung lokal auf dem Lizenzserver ist, werden die gleichen Nachrichten gesendet, allerdings gibt es keine 10 Sekunden Wartezeit nach dem Senden des [RST, ACK]-Pakets.

Meine Frage ist daher: Was macht NAT auf meinem Server, das dazu führen könnte, dass meine Anwendung nach dem Senden eines RST-Pakets 10 Sekunden lang hängen bleibt?

Antwort1

Aber egal, es stellte sich heraus, dass das Problem überhaupt nichts mit NAT zu tun hatte.

Der Lizenzserver hat seinen eigenen Hostnamen als Teil der Nutzlast eines vorherigen Pakets gesendet. Offensichtlich war dieser Hostname für die Anwendung nicht erreichbar, die 10 Sekunden sind also auf ein Timeout in der Anwendung zurückzuführen. Ich vermute, es wird der Hostname ausprobiert und dann nach 10 Sekunden die erste Adresse, die es hatte (so funktioniert es letztendlich).

Nachdem ich den Hostnamen des Lizenzservers zur Hosts-Datei auf dem Client-Computer hinzugefügt habe, funktioniert es.

Ich komme mir vor wie ein Vollidiot. Danke an alle, die nachgesehen haben.

verwandte Informationen