Warum lehnt unsere Firewall (Ubuntu 8.04) das endgültige Paket (FIN, ACK, PSH) mit einem RST ab?

Hintergrund Lange Zeit hatten wir Probleme mit unserer Firewall, die manchmal dazu führten, dass HTTP-Anforderungen teilweise geladen blieben, bis das TCP-Zeitlimit abgelaufen war.

Nach dem Verfolgen des Datenverkehrs auf der Firewall ist mir aufgefallen, dass er nur unter bestimmten Zeitbedingungen auftritt, z. B. wenn der Webserver die gesamte Antwort gesendet hat, bevor der Client sein zweites ACK für die Nutzlast gesendet hat. [SYN, SYN / ACK, ACK] wurde ausgetauscht, REQUEST wurde gesendet und ACK'ed und das erste RESPONSE-Paket wurde empfangen und ACK'ed, dann sendet der Webserver den Rest des Antwortkörpers auf einmal (8 Pakete) (einschließlich der letzten FIN, PSH) und bevor der Client eine dieser ACKs ausgeführt hat, LEHNT die Firewall eine RST gegenüber dem Webserver AB und lässt den Client unendlich hängen.

Hier ist der gesamte Wireshark-Trace mit Paketen von beiden Seiten der Firewall. 192.168.126.161 ist die private NAT'et-IP-Adresse des Clients. 172.16.1.2 ist die Webserver-IP (zeigt nicht die echte öffentliche IP an) und 10.1.1.1 ist die externe Firewall-IP (zeigt nicht die echte öffentliche IP an)

2105 0.086275 192.168.126.161  172.16.1.2       TCP 37854 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=89375083 TSER=0
2106 0.000066 10.1.1.1         172.16.1.2       TCP 37854 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=89375083 TSER=0
2107 0.002643 172.16.1.2       10.1.1.1         TCP http > 37854 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460
2108 0.007705 172.16.1.2       192.168.126.161  TCP http > 37854 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460
2109 0.006301 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0
2110 0.000025 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0
2111 0.000007 192.168.126.161  172.16.1.2       HTTP GET /test/style.css HTTP/1.1 
2112 0.000015 10.1.1.1         172.16.1.2       HTTP GET /test/style.css HTTP/1.1 
2113 0.001536 172.16.1.2       10.1.1.1         TCP http > 37854 [ACK] Seq=1 Ack=111 Win=32658 Len=0
2114 0.000014 172.16.1.2       192.168.126.161  TCP http > 37854 [ACK] Seq=1 Ack=111 Win=32658 Len=0
2115 0.002274 172.16.1.2       10.1.1.1         HTTP HTTP/1.1 200 OK  (text/css)
2116 0.000025 172.16.1.2       192.168.126.161  HTTP HTTP/1.1 200 OK  (text/css)
2117 0.005689 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=1461 Win=8760 Len=0
2118 0.000024 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=1461 Win=8760 Len=0
2119 0.001536 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2120 0.000026 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2121 0.000007 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2122 0.000023 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2123 0.000313 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2124 0.000030 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2125 0.000007 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2126 0.000023 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2127 0.000009 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2128 0.000023 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2129 0.001108 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2130 0.000035 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2131 0.000008 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2132 0.000022 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2133 0.000007 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
REJECT-->
2134 0.000089 10.1.1.1         172.16.1.2       TCP 37854 > http [RST] Seq=111 Win=0 Len=0
CLIENT FIRST ACK-->
2135 0.002421 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=2921 Win=11680 Len=0
2136 0.000033 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=2921 Win=11680 Len=0
2137 0.000007 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=4381 Win=14600 Len=0
2138 0.000014 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=4381 Win=14600 Len=0
2139 0.000008 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=5841 Win=17520 Len=0
2140 0.000014 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=5841 Win=17520 Len=0
2141 0.000007 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=7301 Win=20440 Len=0
2142 0.000013 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=7301 Win=20440 Len=0
2143 0.000007 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=8761 Win=23360 Len=0
2144 0.000015 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=8761 Win=23360 Len=0
2145 0.000007 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=10221 Win=26280 Len=0
2146 0.000013 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=10221 Win=26280 Len=0
2147 0.001059 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=11681 Win=29200 Len=0
2148 0.000018 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=11681 Win=29200 Len=0

Ich habe die Paketdurchquerung gemäß dieser Tabelle ausgegraben und protokolliert, und es scheint, dass das zuletzt eingehende Paket 2133 an Raw-PREROUTING, Conntrack, Mangle-PREROUTING vorbeikommt, aber dann verloren geht. Ich habe keine REJECT-Regeln in meinen iptables, ich protokolliere alle DROP-Regeln und keine zeigt an, wo das Paket 2133 verloren geht.

Ich würde gerne das TRACE-Ziel für den eingehenden Filter verwenden, aber leider wird Ubuntu 8.04 nicht mit Unterstützung für das TRACE-Ziel ausgeliefert.

Daher glaube ich, dass einige interne Regeln für implizites Routing / Conntrack / Mangling gelten, die aus irgendeinem Grund die Verbindung zurücksetzen. Vielleicht löst der Datenverkehr einen DOS-Schutz aus, aber ich habe keine Ahnung, wo ich das konfigurieren / analysieren soll. Das Frustrierendste ist, dass ein Paket abgelehnt wird und nichts protokolliert wird ...

Das Anfordern dieser Datei funktioniert ebenfalls zu 100% von Windows-Hosts, schlägt jedoch auf bestimmten Linux-Hosts fehl und 99,9% aller Anforderungen werden durchgestellt, aber manchmal löst das Timing der Pakete dieses Verhalten in unserer Firewall aus.

BEARBEITEN Ok, jetzt habe ich Tonnen von iptables hinzugefügt und es scheint, als ob folgendes passiert (weiß immer noch nicht warum!)

Für Pakete, die die Firewall erfolgreich durchlaufen, werden die folgenden Schritte ausgeführt, von hier aus Tabellen- / Schrittverweise

Table 3-3 step

2     raw-pre
      conntrack
3     mangle-pre
4     [nat-pre]
5     routing-decision -> destination forward
6     mangle-fwd
7     filter-fwd
8     mangle-post
9     [nat-post]

Paket 2133, das abgelehnt wird, durchläuft diese Schritte:

Table 3-1 steps for the incoming FIN,ACK packet 2133
2     raw-pre
      conntrack
3     mangle-pre
4     [nat-pre]
5     routing-decision -> destination local
6     mangle-input
7     filter-input
8     local process emits RST -> webserver

Table 3-2 steps for the outgoing RST packet 2134 in response to 2133
1     raw-out
2     routing decision
      conntrack
3     mangle-out
      reroute-check
4     [nat-out]
5     filter-out
6     mangle-post
7     nat-post

Das Merkwürdige ist, dass sich die Weiterleitungsentscheidung für das Paket 2133 in Schritt 5 jetzt von der Weiterleitungsentscheidung für die anderen Pakete unterscheidet. Bei der Analyse von Anfragen, die funktionieren, z. B. hängen bleiben, wird auch das letzte FIN ordnungsgemäß weitergeleitet. Es scheint ein Fehler im Kernel zu sein oder die Routing-Entscheidung ist in gewisser Weise zustandsbehaftet.

BEARBEITEN

Eine Sache, die diese Probleme verursachen könnte, ist die folgende Tatsache: Der Datenverkehr wird zwischen der Firewall und dem lokalen LAN geleitet, sodass das Client-LAN ​​nicht über L2 direkt mit der Firewall verbunden ist.

                +---------------------------+       +------------------+                         +------------------------+
                |                           |       |      Router      |   (   Lab network    )  |                        |
( Internet ) -- + eth1                 eth0 +-------+                  +-- (                  ) -+ Client 192.168.126.161 |
                | 10.1.1.1   192.168.60.254 |       |                  |   ( 192.168.126.0/24 )  |                        |
                +---------------------------+       +------------------+                         +------------------------+

In diesem Bild stellt 10.1.1.1 die externe IP-Adresse der Firewall dar, alle anderen Adressen sind die tatsächlich verwendeten IP-Adressen.

Hier ist die Routing-Tabelle auf der Firewall:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.1.0        0.0.0.0         255.255.255.240 U     0      0        0 eth1
192.168.126.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.60.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         10.1.1.15       0.0.0.0         UG    0      0        0 eth1

Beachten Sie, dass 10.1.1.0 und Standard-gw 10.1.1.15 zusammengesetzt sind, der Rest ist genau derselbe wie verwendet. Ich musste die Route 192.168.126.0/24 manuell hinzufügen, um von eth0 (192.168.60.254) zum Labornetzwerk zu gelangen.

Hier einige ausführliche Protokolle zur Paketdurchquerung für das letzte Paket 2133, das aufgrund der Weiterleitung an den lokalen Host (z. B. die Firewall) abgelehnt wird.

[16406874.374588] raw pre IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 
[16406874.374625] mangle pre IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 
[16406874.374667] mangle in IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 
[16406874.374699] filter in IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 
[16406874.374780] mangle out IN= OUT=eth1 SRC=10.1.1.1 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=0 RES=0x00 RST URGP=0 
[16406874.374807] mangle post IN= OUT=eth1 SRC=10.1.1.1 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=0 RES=0x00 RST URGP=0 
[16406874.378813] mangle pre IN=eth0 OUT= MAC=00:02:b3:b9:ff:b4:00:90:1a:10:0c:dd:08:00 SRC=192.168.126.161 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=35424 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=11680 RES=0x00 ACK URGP=0 
[16406874.378863] mangle fwd IN=eth0 OUT=eth1 SRC=192.168.126.161 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=62 ID=35424 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=11680 RES=0x00 ACK URGP=0 

Wieder einmal wurde unsere fw external IP durch 10.1.1.1 und die IP des Webservers außerhalb des NAT'ed-Netzwerks durch 172.16.1.2 ersetzt

EDIT Breaking News!

Ok, der letzte Versuch war, das RST-Paket zu löschen, sehr, sehr interessant. Ich habe eine iptables-Regel hinzugefügt, die alle RST-Pakete auf den Webserver überträgt, von dem wir Probleme beim Anfordern von Dateien haben. Und dann hat es funktioniert, z. B. wird das letzte FIN-, ACK-, PSH-Paket 2133 im obigen Protokoll verworfen. Da jedoch die RST-Datei verworfen wird, hat der Webserver Zeit, alle ACK-Ants abzurufen, und entscheidet, das letzte Paket, Paket 2133, erneut zu übertragen. und jetzt geht es durch die Firewall, da das Contrack-Modul nun gesehen hat, dass ACKs vom Client zurückkommen, und das letzte ACK-FIN-Paket mit der endgültigen Nutzlast zulässt.

Es ist also definitiv ein Timing / Window-Problem. Diese spezielle Datei löst mit dem Timing der ACKs vom Client etwas im Conntrack aus, das das endgültige Paket vom Webserver ablehnt.

Das Durchsuchen und Lesen von Kernel-Dokumenten hat bisher nichts ergeben, was zu diesem Verhalten führen könnte. Im nächsten Schritt wird der Kernel-Quellcode für das Routing- / Conntrack-Modul gelesen.

PROBLEM GELÖST

Nun, zumindest wissen wir jetzt genau, was passiert, und haben eine Problemumgehung, die das Problem löst.

Sergey wies auf die sehr wertvolle Übereinstimmungsregel -m state --state INVALID hin, die beim Debuggen sehr hilfreich war. Jetzt ist mir klar, dass ein iptables-Setup ohne explizite Regel für INVALID-Pakete nicht vollständig ist.

Als ich die Anmeldung im conntrack-Modul für die Ursache des ungültigen Pakets aktivierte, war es ziemlich offensichtlich, was passiert, und ich hatte diesbezüglich einen Verdacht.

[16659529.322465] nf_ct_tcp: SEQ is over the upper bound (over the window of the receiver) IN= OUT= SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=40874 DF PROTO=TCP SPT=80 DPT=55498 SEQ=658735108 ACK=1194081763 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 

Auch hier ist 172.16.1.2 der externe Webserver (der sich nicht korrekt verhält) und 10.1.1.1 die externe Adresse der Firewall.

Der Webserver überträgt mehr Daten über die Leitung, als der Client im Empfangsfenster angekündigt hat (conntrack ist statusvoll und überprüft dies). Es scheint, dass conntrack beim Eintreffen des FIN-Pakets ausfällt, da das Empfangsfenster tatsächlich viel überschritten wird vorhin.

Ich glaube, dass es durch falsches TCP-Offloading in der Netzwerkkarte auf dem Webserver verursacht werden kann. Als ich anfing, dies zu analysieren, machte ich Aufnahmen auf dem Webserver und gemäß den tcpdump / wireshark-Spuren wurden Jumbo-Frames von der TCP-Schicht im Kernel geschrieben, die dann von der Netzwerkkarte in kleinere Frames mit MTU = 1500 segmentiert wurden. Dies muss natürlich im Webserver behoben werden, da es nicht korrekt ist, mehr Daten zu senden, als der Empfänger im Empfangsfenster anzeigt.

Sowohl Polynomial als auch Sergey lieferten wertvolle Beiträge, aber Sergey wies mich auf das genaue Verhalten des Conntrack / NAT-Moduls in Bezug auf die Paketdurchquerung hin.

Eine ähnliche Situation ist unter http://www.spinics.net/lists/netfilter/msg51408.html beschrieben : Einige Pakete, die von NAT hätten verarbeitet werden sollen, wurden als UNGÜLTIG anstatt EINGESTELLT markiert und gingen an die INPUT-Kette. Sie sollten einige Regeln hinzufügen -m state --state INVALID, um dies zu überprüfen, und die Antwort unter http://www.spinics.net/lists/netfilter/msg51409.html schlägt vor, dass ein solches INVALID-Paket immer DROPPED sein sollte, da NAT auf ihnen nicht ordnungsgemäß ausgeführt wird , daher können die Adressen in ihnen falsch sein.

Wenn Ihre problematischen Pakete wirklich als UNGÜLTIG markiert sind, kann iptables -I INPUT -m state --state INVALID -j DROPdas Problem möglicherweise durch Hinzufügen umgangen werden (das beschädigte Paket gelangt nicht zum lokalen Prozess und verursacht keine RST-Antwort; TCP wird nach einer Zeitüberschreitung vom verlorenen Paket wiederhergestellt). Anschließend können Sie versuchen, das Problem weiter zu debuggen, wie unter http://www.spinics.net/lists/netfilter/msg51411.html beschrieben :

echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid

(In diesem speziellen Fall wurde das Problem durch eine defekte Netzwerkhardware entlang des Pfades verursacht, wahrscheinlich in Verbindung mit einer TCP-Prüfsummen-Offload-Brokenness.)

Ich habe dieses Verhalten auf anderen Firewall-Typen gesehen und das Verhalten war so identisch, dass ich dachte, ich würde es dort rauswerfen.

Das Problem, das ich hatte, war, dass die Firewall sich in den gleichen Bereich wie die ephemeren Ports auf der Box eingeschlichen hat. Dies würde genau dieses Verhalten hervorrufen, wenn die beiden kollidierten, da der Kernel jetzt davon ausging, dass die Verbindung für den lokalen Computer bestimmt war. Zu diesem Zweck gibt es ein paar Dinge, die Sie überprüfen können. Geben Sie zuerst die Outbound-Port-Konfiguration in iptables an (mithilfe von --to-ports)? Oder haben Sie den kurzlebigen Anschlussbereich auf dem Computer geändert:

$ cat /proc/sys/net/ipv4/ip_local_port_range

Zur Diagnose können Sie Ihr Capture einrichten und feststellen, ob andere Anforderungen mit derselben externen FW-IP-Port-Kombination innerhalb von 3 * MSL-Zeit vor dem RST (~ 180s, glaube ich) angezeigt werden.

Ich bin mir zwar noch nicht sicher, ob das die Antwort ist, aber wenn ich in dieser Situation wäre, würde ich das zuerst ausschließen und dann ein paar andere Dinge betrachten.

Ist das einfach zu reproduzieren? Ist es möglich, weitere Diagnosen über die Firewall-Box zu erfassen und das Problem zu erkennen? Ich würde versuchen zu erfassen:

$ netstat -anp
$ cat /proc/net/ip_conntrack

jede Sekunde oder so, während Sie versuchen, zu reproduzieren und festzustellen, ob lokal etwas mit dem Port verbunden ist und wie die Maskeradentabelle während des Problems aussah.

Wenn Sie den RST-Ausgang durch eine Firewall schützen, führt die eventuelle Bestätigung durch den internen Client dazu, dass die Verbindung erfolgreich hergestellt wird?

Zuletzt sehen Sie alle Protokolle? Hast du dmesg schon gecheckt? Haben Sie *. * In der Firewall-Box in der Syslog-Konfiguration auf eine Datei eingerichtet, um dies sicherzustellen?

Lassen Sie mich wissen, was Sie finden! Ich bin sehr dankbar für die Menge an Informationen, die Sie in der Frage angegeben haben, danke.