Frage Warum lehnt unsere Firewall (Ubuntu 8.04) das letzte Paket (FIN, ACK, PSH) mit einer RST ab?


Hintergrund, für eine lange Zeit hatten wir Probleme mit unserer Firewall, die manchmal dazu führt, dass HTTP-Anfragen teilweise geladen bleiben, bis TCP abläuft.

Nach der Verfolgung des Datenverkehrs auf der Firewall habe ich festgestellt, dass es nur während bestimmter 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 bestätigt und das erste RESPONSE-Paket wurde empfangen und bestätigt, dann sendet der Webserver den Rest des Antwortkörpers auf einmal (8 Pakete) einschließlich der letzten FIN, PSH) und bevor der Client irgendeinen davon bestätigt hat, REAGIERT die Firewall mit einem RST in Richtung des Webservers und hält den Client unendlich hängen.

Hier ist die gesamte Wireshark-Spur mit Paketen von beiden Seiten der Firewall. 192.168.126.161 ist die private IP-Adresse des Clients. 172.16.1.2 ist die IP des Webservers (zeigt nicht die echte öffentliche IP) und 10.1.1.1 ist die externe Firewall der Firewall (zeigt nicht die echte öffentliche IP)

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 den Paketdurchlauf entsprechend gegraben und protokolliert Diagramm und es scheint, dass das letzte eingehende Paket 2133 an rohem PREROUTING vorbeikommt, conntrack, mangle-PREROUTING aber dann verloren ist. Ich habe keine REJECT-Regeln in meinen iptables, ich protokolliere alle DROP-Regeln und keiner von ihnen zeigt an, wo Paket 2133 verloren geht.

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

Ich glaube also, dass einige interne implizite Routing- / Conntrack / Mangling-Regeln gelten, die die Verbindung aus irgendeinem Grund zurücksetzen. Vielleicht löst der Traffic 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 geloggt wird ...

Wenn diese Datei angefordert wird, funktioniert sie zu 100% von Windows-Hosts, aber sie schlägt auf bestimmten Linux-Hosts fehl und 99,9% aller Anfragen kommen durch, aber manchmal löst das Timing der Pakete dieses Verhalten in unserer Firewall aus.

BEARBEITEN Ok, jetzt habe ich Tonnen von Logging in iptables hinzugefügt und es scheint, dass das folgende passiert (weiß immer noch nicht warum!)

Für Pakete, die die Firewall erfolgreich durchlaufen, werden die folgenden Schritte ausgeführt, Tabellen- / Schrittreferenzen von Hier

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 abgewiesen 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 Seltsame ist, dass die Routing-Entscheidung für das Paket 2133 in Schritt 5 sich nun von der Routing-Entscheidung für die anderen Pakete unterscheidet. Bei der Analyse von Anfragen, die funktionieren, z. B. nicht hängen bleiben, wird auch das letzte FIN richtig geroutet. Es scheint wie ein Fehler im Kernel oder dass die Routing-Entscheidung in irgendeiner Weise statusbehaftet ist.

BEARBEITEN

Eine Sache, die diese Probleme verursachen könnte, ist die folgende Tatsache: Der Datenverkehr wird zwischen der Firewall und dem lokalen LAN geroutet, sodass das Client-LAN ​​nicht direkt über L2 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 repräsentiert 10.1.1.1 die externe IP-Adresse der Firewall, alle anderen Adressen sind die realen 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 der gleiche wie verwendet. Ich musste die Route 192.168.126.0/24 manuell hinzufügen, um das Lab-Netzwerk von eth0 (192.168.60.254) zu erreichen.

Hier sind einige umfangreiche Protokolle des Paketdurchlaufs für das letzte Paket 2133, das aufgrund der Weiterleitung an den lokalen Host (z. B. die Firewall) zurückgewiesen 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 externe IP durch 10.1.1.1 ersetzt und die IP des Webservers außerhalb des NAT'ed Netzwerks wird durch 172.16.1.2 ersetzt

BEARBEITEN Breaking News!

Ok letzter Versuch war, das RST-Paket abzulegen, sehr, sehr interessant, ich habe eine iptables-Regel hinzugefügt, die alle RST-Pakete gelöscht hat, die auf dem Webserver liegen, von dem wir Probleme beim Anfordern von Dateien haben. Und dann es hat funktioniert zB wird das letzte FIN-, ACK-, PSH-Paket 2133 in dem obigen Protokoll fallengelassen, aber da der RST fallengelassen wird, hat der Webserver Zeit, alle ACKs zu holen und entscheidet dann, das letzte Paket erneut zu übertragen, Paket 2133, und jetzt geht es weiter durch die Firewall, da das Kontraktmodul nun gesehen hat, dass ACK vom Client zurückkommt und das letzte Paket ACK, FIN mit der endgültigen Nutzlast zulässt.

Es ist definitiv ein Timing- / Fenster-Problem, diese spezielle Datei mit dem Timing der ACKs vom Client löst etwas in Conntrack aus, das das letzte Paket vom Webserver ablehnt.

Bisher haben das googeln und das Lesen von Kernel-Dokumenten nichts ergeben, was zu diesem Verhalten führen könnte. Der nächste Schritt wird sein, den Kernel-Quellcode für das Routing- / Conntrack-Modul zu lesen.

PROBLEM GELÖST

Nun, zumindest jetzt wissen wir genau, was passiert und haben einen Workaround, der das Problem löst.

Sergey wies auf die sehr wertvolle -m Status - Status INVALID Matching-Regel, die eine Menge im Debugging geholfen, ich merke jetzt, dass ein Iptables-Setup ohne eine explizite Regel für ungültige Pakete nicht abgeschlossen ist, so seltsames Verhalten scheint manchmal zu passieren.

Beim Aktivieren der Anmeldung im conntrack-Modul für das, was das ungültige Paket verursacht, was passiert, ist es ziemlich offensichtlich und ich hatte meinen Verdacht diesbezüglich.

[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 

Wiederum ist 172.16.1.2 der externe Webserver (der sich falsch verhält) und 10.1.1.1 ist die externe Adresse der Firewall.

Der Webserver schiebt mehr Daten über die Leitung, als der Client im Empfangsfenster angekündigt hat (conntrack ist State-full und überprüft dies), es scheint, dass es beim Eintreffen des FIN-Pakets ausbucht, da das Empfangsfenster tatsächlich viel überschritten wird vorhin.

Ich glaube, dass es durch falsches TCP-Offloading in der Netzwerkkarte auf dem Webserver verursacht wurde. Als ich anfing, dies zu analysieren, nahm ich Captures auf dem Webserver und gemäß den tcpdump / wireshark-Traces wurden Jumbo-Frames von der TCP-Ebene im Kernel geschrieben, die dann von der Netzwerkkarte in kleinere Frames mit MTU = 1500 segmentiert wurde. Dies muss natürlich auf dem Webserver angesprochen werden, da es nicht korrekt ist, dass das TCP-Verhalten mehr Daten sendet, als der Empfänger Werbeanzeigen in seinem Empfangsfenster hat.

Sowohl Polynom als auch Sergey lieferten wertvolle Informationen, aber Sergey wies mich auf das genaue Verhalten des Conntrack / NAT-Moduls bezüglich des Paketdurchlaufs hin.


19
2017-09-09 09:21


Ursprung


Haben Sie REJECT-Anweisungen in Ihrer iptables-Konfiguration? Wenn ja, prüfen Sie, ob Sie die Protokollierung verwenden können, um herauszufinden, um welche Regel es sich handelt. - Ladadadada
Nein, keine Regeln ablehnen, es scheint, als ob das REJECT außerhalb von iptablesm geschieht, während der Routing-Entscheidung - ernelli
Ist es möglich, dass die Firewall keine Schiebefenster unterstützt? Wie kann eine Aufnahme von einem funktionierenden Client mit dieser verglichen werden? - joeqwerty
Wenn es funktioniert, sendet der Client ACKs vor dem finalen FIN vom Server, abgesehen davon, dass alle Pakete korrekt an den Client weitergeleitet werden und keine RST-Pakete zurückgegeben werden. Ich habe einen Dump von einer großen Datei (300k) untersucht und dann gibt es keine Probleme. Ein Trace aus einer kleinen Datei funktioniert ebenfalls, das letzte Paket mit FIN wird weitergeleitet. Können Sie bitte näher erläutern "Firewall unterstützt keine Schiebefenster" - ernelli
Können Sie die Verbindung zwischen dem Router und dem Lab-Client erweitern? Sie haben / 24 Netmasks auf der 60 und 126, so ist es nicht klar, wie die Lab-Clients Verkehr senden können? Ist ihre Netzmaske nicht a / 24? Gibt es eine Art Proxy-Proxy? Gibt es einen Alias ​​auf eth0: 1 für die 126.0 / 24? - polynomial


Antworten:


Eine ähnliche Situation wird beschrieben bei http://www.spinics.net/lists/netfilter/msg51408.html: Einige Pakete, die von NAT verarbeitet worden sein sollten, wurden irgendwie als INVALID anstatt als ESTABLISHED markiert und gingen in die INPUT-Kette. Sie sollten einige Regeln hinzufügen mit -m state --state INVALID um dies zu überprüfen, und die Antwort auf http://www.spinics.net/lists/netfilter/msg51409.html schlägt vor, dass ein solches INVALID-Paket immer DROPped sein sollte, weil NAT nicht ordnungsgemäß auf ihnen ausgeführt wird, daher können Adressen in ihnen falsch sein.

Wenn Ihre problematischen Pakete wirklich als INVALID markiert sind, fügen Sie hinzu iptables -I INPUT -m state --state INVALID -j DROP wahrscheinlich wird das Problem umgehen (das defekte Paket wird nicht zum lokalen Prozess gelangen und die RST-Antwort nicht verursachen, dann wird TCP nach einer Zeitüberschreitung von dem verlorenen Paket wiederhergestellt). Dann können Sie versuchen, das Problem weiter zu debuggen, wie in http://www.spinics.net/lists/netfilter/msg51411.html:

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 kombiniert mit einer TCP-Prüfsummen-Offload-Brüche.)


8
2017-09-18 11:53





Ich habe dieses Verhalten bei 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 in den gleichen Raum wie ephemere Ports auf der Box NAT war. Dies würde genau dieses Verhalten verursachen, wenn die beiden kollidierten, weil der Kernel nun annahm, dass die Verbindung für den lokalen Rechner bestimmt war. Zu diesem Zweck gibt es ein paar Dinge, die Sie überprüfen können. Zuerst geben Sie die Konfiguration des ausgehenden Ports in iptables an (mit --to-ports)? Oder haben Sie den ephemeren Portbereich auf der Maschine geändert:

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

Um zu diagnostizieren, können Sie Ihre Aufnahme einrichten und sehen, ob Sie irgendwelche anderen Anfragen mit der gleichen externen fw IP, Port-Combo innerhalb von 3 * MSL Zeit vor der RST sehen (~ 180s denke ich).

Obwohl ich nicht sicher bin, ob das die Antwort ist, würde ich das in der Situation zuerst ausschließen und dann ein paar andere Dinge betrachten.

Ist das einfach zu reproduzieren? Ist es möglich, mehr Diagnosen von der Firewall-Box zu erfassen und das Problem auftreten zu sehen? Ich würde versuchen zu erfassen:

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

jede Sekunde oder so beim Versuch zu reproduzieren und zu sehen, ob es etwas lokal an den Port binden und wie die Masquerade-Tabelle während des Problems ausgesehen hat.

Wenn die Firewall den RST-Ausgang abbricht, führt die eventuelle ACK vom internen Client dazu, dass die Verbindung erfolgreich ist?

Letzte Sache, siehst du alle Protokolle? Haben Sie dmesg bereits überprüft? Hast du *. * In der Firewall-Box in der Syslog-Konfiguration auf eine Datei gesetzt, um sicherzugehen?

Lass mich wissen, was du findest! Ich schätze die Menge der Informationen sehr, die Sie in der Frage zur Verfügung gestellt haben, danke.


3
2017-09-15 03:08



Danke für deine Mühe, ich kann den Fehler 100% reproduzieren, alle Anfragen über die Firewall funktionieren bis auf sehr wenige. Diejenigen, die nicht arbeiten, scheinen ein genaues Größen / Timing-Problem zu treffen. Ich kann mehrere Wireshark-Traces für größere / kleinere Anfragen zwischen demselben Client / Webserver über die Firewall hinzufügen, was alles funktioniert, aber die obige Spur ist diejenige, die stecken bleibt. Ich habe neue Informationen hinzugefügt, die das Problem verdeutlichen könnten. - ernelli
/ proc / sys / net / ipv4 / ip_local_port_range ist auf [32768 61000] eingestellt. netstat zeigt keine lokal gebundenen Ports an. ip_conntrack zeigt die Verbindung als etabliert an, z.B. glaubt sie, dass sie noch offen ist, da das letzte FIN nicht an den Client weitergeleitet wurde. Der Status ist Pakete = 10 Bytes = 12084 [ASSURED] mark = 0 secmark = 0 use = 1 - ernelli