Ein paar Worte über Path MTU Discovery Black Hole

Ein paar Worte über Path MTU Discovery Black Hole



Anstatt mitzumachen


Einmal für jeden echten Systemadministrator (oder einen, der als solcher handelt), kommt ein Moment der Wahrheit. Er hat das Schicksal, den Router auf einem Computer mit installiertem GNU / Linux zu konfigurieren. Diejenigen, die dies bereits bestanden haben, wissen, dass dies nicht kompliziert ist und dass es möglich ist, ein paar Teams zu treffen. Und jetzt findet unser Administrator diese Befehle, treibt sie in die Konsole und geht stolz zu den Benutzern, um zu sagen, dass alles bereits funktioniert. Aber da war es - Benutzer sagen, dass ihre Lieblingsseiten nicht geöffnet werden. Nachdem ich einige Zeit meines Lebens damit verbracht habe, die Details herauszufinden, hat sich herausgestellt, dass sich die meisten Websites wie folgt verhalten:
1. Wenn Sie die Seite öffnen, wird der Titel geladen und sonst nichts.
2. In diesem Zustand bleibt die Seite auf unbestimmte Zeit hängen.
3. Die Browser-Statusleiste zeigt die ganze Zeit an, dass die Seite geladen wird.
4. Pings und Verfolgung dieser Seite sind in Ordnung;
5. Die Telnet-Verbindung zu Port 80 funktioniert ebenfalls einwandfrei.
Ein entmutigter Administrator ruft den technischen Support des Anbieters an, lässt ihn jedoch schnell los und rät ihm, den Router unter Windows einzurichten. Wenn er dort nicht funktioniert, kaufen Sie einen Hardware-Router.
Ich denke, diese Situation ist vielen bekannt. Einige sind selbst reingefallen, einige hatten Freunde mit ihr und einige hatten solche Admins in Foren und anderen Konferenzen getroffen. Also: Wenn Sie eine solche Situation haben, dann - Herzlichen Glückwunsch! Sie werden mit Path MTU Discovering Black Hole konfrontiert . In diesem Artikel wird erläutert, warum dies geschieht und wie dieses Problem behoben werden kann.



Begriffe, die zum Verständnis des Artikels benötigt werden.


MTU (Maximum Transmission Unit) - Mit diesem Begriff wird die maximale Paketgröße (in Byte) festgelegt, die auf der Datenverbindungsschicht des OSI-Netzwerkmodells übertragen werden kann. Für Ethernet sind dies 1500 Byte. Wenn ein größeres Paket ankommt (zum Beispiel über Token Ring), werden die Daten wieder zu Paketen von nicht mehr als MTU (d. H. Nicht mehr als 1.500 Bytes) zusammengesetzt. Der Vorgang des erneuten Zusammenbaus von Paketen unter einer anderen MTU wird als Fragmentierung bezeichnet und ist für den Router teuer.
PMTU (Path MTU) - Dieser Parameter gibt die kleinste MTU unter den MTU-Datenkanälen zwischen Quelle und Empfänger an.
PMTU-Erkennung ist eine PMTU-Erkennungstechnologie, mit der die Router entlastet werden sollen. Beschrieben in RFC 1191im Jahr 1988. Der Kern der Technologie besteht darin, dass bei der Verbindung von zwei Hosts der Parameter DF (Nicht fragmentieren) festgelegt wird, wodurch die Paketfragmentierung verhindert wird. Dies führt dazu, dass der Knoten, dessen MTU kleiner als die Paketgröße ist, die Übertragung des Pakets ablehnt und eine ICMP-Nachricht vom Typ Ziel nicht erreichbar sendet. Die Fehlermeldung wird vom MTU-Wert des Knotens begleitet. Der sendende Host reduziert die Paketgröße und sendet sie erneut. Eine solche Operation findet statt, bis das Paket klein genug ist, um den Zielhost ohne Fragmentierung zu erreichen.
MSS (Maximum Segment Size) - die maximale Segmentgröße, d.h. Der größte Datenblock, den TCP an das entfernte andere Ende der Verbindung sendet. Es wird nach folgender Formel berechnet:
Schnittstellen-MTU - Header_IP_Size (20 Bytes) - Header_TCP_Size (20 Bytes). Insgesamt normalerweise 1460 Bytes. Wenn eine Verbindung hergestellt ist, kann jede Seite ihre eigene MSS deklarieren. Der kleinste Wert wird ausgewählt. Weitere Details finden Sie hier .
Flag DF (Nicht fragmentieren) - Ein Bit im Flags-Feld des IP-Paket-Headers, das, wenn es auf eins gesetzt ist, anzeigt, dass dieses Paket nicht fragmentiert werden darf. Wenn ein Paket mit einem solchen Flag größer als die MTU der nächsten Weiterleitung ist, wird dieses Paket verworfen, und dem Absender wird ein ICMP-Fehler gesendet: "Fragmentierung ist erforderlich, aber das Bitfragment ist nicht gesetzt" (Fragmentierung erforderlich, aber kein Fragmentbit gesetzt).

Testgelände


Dieses Problem ist in der Praxis am besten bekannt (aber nicht in Zeitnot, wenn der Chef über das Ohr schreit). Zu diesem Zweck habe ich ein Testnetzwerk erstellt (siehe Abb


. 1) . 1. Testen Sie das Netzwerk.

Dies ist eine vereinfachte Version des globalen Netzwerks. Rollen:
1. Ein Computer namens deb-serv-03 ist unser Linux-Router. Achtung - Auf der eth2-Schnittstelle wurde die MTU-Größe auf 1400 Byte reduziert.
2. deb-serv-05 - ein Client im lokalen Netzwerk;
3. deb-home - ein Router, der sich beim Provider befindet;
4. deb-serv - Ein Webserver im Internet, mit dem wir Daten austauschen wollen. Wir erhalten von www.site.local eine Seite mit einer Größe von 5,9 KB.
Natürlich ist die Kette in Wirklichkeit viel größer, aber für ein anschauliches Beispiel reicht dies aus. Auf allen Computern in diesem Netzwerk wird Debian GNU / Linux 5.0 Lenny ausgeführt. An verschiedenen Stellen im Netzwerk kontrolliere ich die Situation mit dem Programm tcpdump.

Normale Erkennung von PMTU


Lassen Sie uns zuerst sehen, was im Netzwerk passiert, wenn Sie eine Seite öffnen. Erfahren Sie, wie Pakete vom Webserver ablaufen. Wir betrachten die Ausgabe von TCPDUMP # 1 (auf eth0 deb-serv): Ich liste nur die ersten 10 Pakete auf und schneide den gesamten Überschuss in der Standardausgabe von tcpdump ab. Wir zerlegen: 1. In den Zeilen 1 bis 3 sehen wir den TCP-Verbindungsaufbau. Die Parteien tauschen SYN-, SYN-ACK- und ACK-Pakete aus. Hierbei ist das Optionsfeld zu beachten, nämlich der zwischen den Parteien ausgetauschte MSS-Parameter. Auf beiden Seiten sind es 1460 Bytes. Dies bedeutet, dass die maximale Größe der Pakete, die die Teilnehmer untereinander senden, 1460 (MSS) +20 (TCP-Header) +20 (IP-Header) = 1500 Byte beträgt. 2. Senden Sie in Zeile 4 eine Anfrage für eine Webseite von deb-serv-05. Zeile 5 bestätigt den Erhalt dieses Pakets.

1 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [S], seq 2947128725, win 5840, options [mss 1460...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [S.], seq 757312786, ack 2947128726, win 5792, options [mss 1460...], length 0
3 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:2897, ack 118, win 181, options [...], length 2896
7 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
8 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:1349, ack 118, win 181, options [...], length 1348
9 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1349:2697, ack 118, win 181, options [...], length 1348
10 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556





3. In Zeile 6 sehen wir die Antwort auf die Anfrage (dh das Senden eines Teils der Webseite). Wahrscheinlich aufgrund der Besonderheiten von pcap auf dieser Schnittstelle sieht tcpdump ein Paket mit einer Größe von 2948 Bytes, während 2 Pakete mit einer Größe von 1500 bzw. 1452 Bytes an das Netzwerk gehen. Wenn Sie sich die detailliertere Ausgabe von tcpdump ansehen, werden Sie feststellen, dass sich das DF-Flag in diesem Paket befindet (genauer gesagt, in den Paketen): 4. Wenn diese Datenpakete deb-serv-03 erreichen, werden sie verworfen, weil sie die Verbindung zu MTU 1400 und nicht durchlaufen können kann nicht fragmentiert werden (DF-Flag), und als Antwort wird ein ICMP-Nachrichtentyp 3-Code 4 generiert: ICMP 172.16.5.3 nicht erreichbar - muss fragmentiert werden (mtu 1400) , was wir in Zeile 7 sehen (in Zeile 10 eine Nachricht für die zweite Paket). Diese Nachricht sendet die gewünschte MTU.
IP (tos 0x0, ttl 64, id 5177, offset 0, flags [DF], proto TCP (6), length 2948)
192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:2897, ack 118, win 181, options [nop,nop,TS val 86620459 ecr 4922429], length 2896


5. In den Zeilen 8 und 9 sehen wir, wie deb-serv, nachdem es MTU = 1400 erhalten hat, dasselbe Stück der Webseite in Paketen mit einer Größe von 1400 Bytes sendet. Diese Pakete erreichen deb-serv-05, wo eine Bestätigung generiert wird, und so weiter, bis die gesamte Seite übertragen wurde. Die Größe aller nachfolgenden Pakete wird nicht mehr als 1400 Bytes betragen.
Dieses Beispiel zeigt das in RCF1911 beschriebene Transport MTU Determination Procedure (PMTU). Ich habe es in vereinfachter Form in Abbildung 2 dargestellt.


Abbildung 2. Das Verfahren zur Bestimmung der PMTU.

Treffen mit Path MTU Discovery Black Hole


Stellen Sie sich nun vor, ein neuer Spezialist wäre zu dem Anbieter gekommen und hätte (beispielsweise zum Schutz vor ICMP-Flood) beschlossen, das Senden von ICMP-Paketen über deb-home, das jetzt in seiner Verantwortung liegt, zu untersagen. Wir schauen uns an, was passiert:
TCPDUMP # 1-Ausgabe (auf eth0 deb-serv): TCPDUMP # 2-Ausgabe (auf eth0 deb-serv-03):

1 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [S], seq 1723325723, win 5840, options [mss 1460...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [S.], seq 2482933888, ack 1723325724, win 5792, options [mss 1460...], length 0
3 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:2897, ack 118, win 181, options [...], length 2896
7 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
8 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
9 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
10 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448




1 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [S], seq 1723325723, win 5840, options [mss 1460...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [S.], seq 2482933888, ack 1723325724, win 5792, options [mss 1460...], length 0
3 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
7 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
8 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1449:2897, ack 118, win 181, options [...], length 1448
9 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
10 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
11 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
12 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
13 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
14 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
15 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
16 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
17 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
18 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
19 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
20 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448


Wie Sie sehen, ist die Situation durchaus zu erwarten. Die ersten 6 Zeilen in jeder Ausgabe sind genau die gleichen wie bei der normalen Übertragung (siehe Beschreibung im vorherigen Beispiel). Aber dann beginnen die Unstimmigkeiten. ICMP 3: 4 wird auf dieselbe Weise auf deb-serv-03 generiert (Zeilen 7, 9, 11.13, 15, 17, 19 in TCPDUMP # 2), aber deb-serv empfängt es nicht und sendet weiterhin Pakete mit einer Größe von 1500 Bytes (Zeilen mit 6 bis 12 in TCPDUMP # 1 und 6, 8, 10, 12, 14, 16, 18 und 20 in TCPDUMP # 2). Jedes Mal, wenn die Zeit zwischen Neuübertragungen zunimmt (in diesen Beispielen habe ich die Zeitstempel verworfen, aber der TCP-Neuübertragungsmechanismus funktioniert tatsächlich auf diese Weise). In diesem Fall können keine Daten übertragen werden, die größer als PMTU sind. Leider weiß TCP dies nicht und sendet weiterhin Pakete mit dem MSS, der zum Zeitpunkt des Verbindungsaufbaus ausgewählt war. Diese Situation heißtPfad MTU Discovery Black Hole (Schwarzes Loch in der Definition der Transport-MTU). Ich habe versucht, es in vereinfachter Form in Abb. 3.


Abb. 3. Schwarzes Loch in der Definition von PMTU.

Dieses Problem ist überhaupt nicht neu. Es ist in RFC 2923 im Jahr 2000 beschrieben. Dennoch stößt es bei vielen Anbietern weiterhin auf beneidenswerte Hartnäckigkeit. Schuld daran ist jedoch der Anbieter: Er muss ICMP-Typ-3-Code 4 nicht blockieren. Außerdem möchte er in der Regel nicht auf die „Stimme der Vernunft“ hören (dh auf Kunden, die das Problem verstehen).

Lösen des PMTU-Problems


Wir werden keinen technischen Support anrufen, sondern versuchen, das Problem aus eigenen Mitteln zu lösen.
Linux-Entwickler, die auch darüber Bescheid wissen, haben in iptables eine spezielle Option bereitgestellt. Zitat aus man iptables: Meine kostenlose Übersetzung für diejenigen, die ein knappes Englisch haben: Wie Sie sehen können, haben sie eine Menge Dinge geschrieben, sogar ungefähre Problemsymptome beschrieben. Und dieses Verhalten der Anbieter wurde als "kriminelle Inkompetenz" bezeichnet, was ich ihnen voll und ganz zustimme. Lassen Sie uns untersuchen, wie diese Option in unserem Beispiel funktioniert. Fügen Sie die empfohlene Regel zu deb-serv-03 hinzu: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN, RST SYN -j TCPMSS -set-mss 1360 Und schauen Sie, was passiert ist: TCPDUMP # 1 output (on eth0 deb -serv):

TCPMSS
This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface’s MTU minus 40 for IPv4 or 60 for IPv6, respectively). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table. This target is used to overcome criminally braindead ISPs or servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too Big" packets. The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:
1) Web browsers connect, then hang with no data received.
2) Small mail works fine, but large emails hang.
3) ssh works fine, but scp hangs after initial handshaking.
Workaround: activate this option and add a rule to your firewall configuration like:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

--set-mss value
Explicitly set MSS option to specified value.

--clamp-mss-to-pmtu
Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6).

These options are mutually exclusive.




TCPMSS
Это действие позволяет изменять значение MSS в TCP SYN пакетах, для контроля максимального размера пакетов в этом соединении (Обычно ограничивая его MTU исходящего интерфейса минус 40 байт для IPv4 или минус 60 для IPv6). Конечно, это действие может использоваться только в сочетании с -p tcp. Разрешено это только в таблице mangle. Это действие используется для преодоления преступной некомпетентности провайдеров и серверов, блокирующих "ICMP Fragmentation Needed" или "ICMPv6 Packet Too Big" пакеты. Симптомы этой проблемы – все прекрасно работает на вашем сетевом экране или роутере, но машины за ним никогда не смогут обмениваться большими пакетами:
1) Веб браузеры связываются, но просто висят без пересылки данных.
2) маленькие электронные письма приходят нормально, но большие висят.
3) ssh работает отлично, но scp висит после начальных рукопожатий(прим пер: процесс установки TCP соединения также называют "тройным рукопожатием").
Решение: активировать эту опцию и добавить правило, подобное нижеприведенному, в конфигурацию своего сетевого экрана:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

--set-mss значение
Явная установка в опции MSS специфического значения.

--clamp-mss-to-pmtu
Автоматическая установка значения MSS в (path_MTU - 40 для IPv4; -60 для IPv6).
Эти опции являются взаимоисключающими.






1 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [s], seq 1484543117, win 5840, options [mss 1360...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [s.], seq 2230206317, ack 1484543118, win 5792, options [mss 1460...], length 0
3 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [p.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], seq 1:2697, ack 118, win 181, options [...], length 2696
7 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 1349, win 2184, options [...], length 0
8 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], seq 2697:5393, ack 118, win 181, options [...], length 2696
9 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [fp.], seq 5393:6380, ack 118, win 181, options [...], length 987
10 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 2697, win 2908, options [...], length 0


Ausgabe von TCPDUMP # 3 (auf eth0 deb-serv-05): Wir analysieren: 1. In den Zeilen 1-3 kennen wir die TCP-Verbindung bereits. Beachten Sie jedoch die MSS-Werte. In TCPDUMP # 1 erhält deb-serv-05 einen Wert von 1360, während in TCDUMP # 3 zu sehen ist, dass ein Paket mit MSS = 1460 verlassen wird. Genau so funktioniert die Regel mit –set-mss 1360. Sie bearbeitet den MSS-Wert für die Weiterleitung von Paketen. Für das zurückgekehrte SYN-Paket wird dieser Wert ebenfalls bearbeitet. 2. In den Zeilen 4 und 5 beider Schlussfolgerungen beobachten wir erneut das Senden einer GET-Anfrage und die Bestätigung des Eingangs.

1 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [S], seq 1484543117, win 5840, options [mss 1460...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [S.], seq 2230206317, ack 1484543118, win 5792, options [mss 1360...], length 0
3 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 1:1349, ack 118, win 181, options [...], length 1348
7 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 1349:2697, ack 118, win 181, options [...], length 1348
8 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 1349, win 2184, options [...], length 0
9 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 2697, win 2908, options [...], length 0
10 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 2697:4045, ack 118, win 181, options [...], length 1348





3. In Zeile 6 für TCPDUMP # 1 und in den Zeilen 6 und 7 für TCPDUMP # 3 sehen wir, wie Pakete mit Daten gesendet werden, aber jetzt überschreitet die Größe jedes Pakets nicht 1400 Bytes. Wieder tritt bei TCPDUMP # 1 ein seltsamer Fehler auf, bei dem ein großes Paket sichtbar ist, während bei TCPDUMP # 3 die Ankunft von 2 Paketen beobachtet wird.
4. Der weitere Paketaustausch entspricht den Regeln des TCP-Protokolls. Aber niemals hat eine Paketgröße 1400 Bytes überschritten.

In vereinfachter Form ist das Verhalten von MSS in Abb. 2 dargestellt. 4. Ich habe den Datenaustausch nicht angezeigt, da er dem üblichen Verhalten ähnelt.

Abb. 4. Ändern Sie MSS im laufenden Betrieb.

Obwohl in man iptables zwei Optionen beschrieben sind, habe ich bisher nur eine angewendet. Welche Option Sie benötigen, hängt von der jeweiligen Situation ab. Alle Situationen können in 2 Typen unterteilt werden:

1. Auf Ihrem Router werden Standorte normal geöffnet, und auf Clients im lokalen Netzwerk treten Probleme auf.
In diesem Fall befindet sich die kleinste MTU auf dem gesamten Pfad auf Ihrem Server. In der Regel sind dies einige Verkapselungsprotokolle wie PPPoE, PPtP usw. Die beste Option für diese Situation ist –clamp-mss-to-pmtu, wodurch automatisch die minimale MSS für alle Transitpakete festgelegt wird.

2. Auf Ihrem Router und den Clients im lokalen Netzwerk werden keine Standorte geöffnet.
In diesem Fall befindet sich die kleinste MTU irgendwo beim Anbieter, und es ist schwierig, sie mit Standardmitteln zu berechnen. Speziell dafür habe ich ein kleines Python-Skript geschrieben (das sich nicht wirklich um PEP8 und die Unfähigkeit, in den Fuß zu schießen, kümmert), mit dessen Hilfe die erforderliche MSS-Größe für diese Situation bestimmt werden kann:

#!/usr/bin/env python
# -*-coding: utf-8 -*-
import socket
import os
import time
import sys
# Полное имя веб сервера на котором проводятся испытания. Следует выбирать из
# сайтов, которые точно не работают.
HOST = 'www.site.local'
# Временной интервал, в течении которого следует ожидать ответа от сайта.
# Слишком маленькое значение может породить ложные срабатывания, слишком
# большое - долгое время работы скрипта.
TIMEOUT = 25.0
# Количество байт, которые надо получить с веб сервера, чтобы убедится что он
# наверняка работает. Рекомендуется устанавливать большим нежели значение MTU
BUF = 3000
# Значение MTU на интерфейсе в интернет.
MTU = 1500
# Значение MSS будет искаться в пределе от MTU-LIM-40 до MTU-40. Запрещено
# ставить значение больше MTU и не рекомендуется ставить значения более чем
# 100-200 - это может привести к большому времени работы скрипта.
LIM = 100
# Задержка между обращениями к сайту. Рекомендуется устанавливать отличной от
# нуля на медленном канале.
TRY_TIME = 0
def set_mss(mss, action='A'):
    return os.system("iptables -t mangle -%s OUTPUT -p tcp --tcp-flags \
            SYN,RST SYN -j TCPMSS --set-mss %d" % (action, mss) )
def check_connection(host):
    sock = socket.socket()
    sock.connect( (host, 80) )
    sock.send('GET / HTTP/1.1\r\nHost: %s\r\n\r\n' % host)
    sock.settimeout(TIMEOUT)
    try:
        answer_size = len( sock.recv(BUF) )
    except:
        answer_size = 0
    sock.close()
    return answer_size
def main():
    mss = MTU - 40
    if not check_connection(HOST):
        mss = MTU - 40 - LIM
        set_mss(mss)
        if not check_connection(HOST):
            set_mss(mss,'D')
            print "Error: Too small LIM"
            sys.exit(1)
        else:
            while check_connection(HOST):
                time.sleep(TRY_TIME)
                set_mss(mss,'D')
                if mss >= MTU-40:
                    print "Error in determining MSS"
                    sys.exit(1)
                mss += 1
                set_mss(mss)
            set_mss(mss,'D')
            mss -= 1
    print 'MSS = %d' % (mss)
if __name__ == '__main__':
    main()
    sys.exit(0)


Sie müssen das Skript mit Superuser-Berechtigungen ausführen. Der Algorithmus seiner Arbeit lautet wie folgt:
1. Wir versuchen, eine bestimmte Datenmenge von einer Site mit einem normalen MSS-Wert abzurufen.
2. Wenn dies nicht funktioniert, senken Sie das MSS an der iptables OUTPUT-Kette auf MTU-40-LIM.
3. Wenn wir die Daten auch danach nicht erhalten können, erhalten wir die Fehlermeldung, dass das LIM zu klein ist.
4. MSS wird ständig erweitert. Wir suchen nach dem Moment, in dem die Daten nicht mehr ankommen. Danach leiten wir den letzten Arbeitswert von MSS ab.
5. Wenn wir zu MSS = MTU-40 gelangen, zeigen wir einen Fehler an, der besagt, dass wir MSS nicht bestimmen können. Diese Situation ist falsch, weil wir in Absatz 1 eine ähnliche Prüfung durchführen und wenn die Ergebnisse nicht übereinstimmen, ist dies eine Gelegenheit zum Nachdenken.

Nach Erhalt der gewünschten MSS müssen Sie diese in die entsprechende Regel eintragen. Sie können auf ein Skript verzichten, indem Sie den MSS-Wert mit den Augen senken. Es ist jedoch besser, dies mit Sicherheit herauszufinden - der Aufwand für das Senden von Paketen ist geringer.

In den Foren finden Sie häufig Tipps zum Verringern der MTU für eine bestimmte Benutzeroberfläche. Sie müssen verstehen, dass dies kein Allheilmittel ist und das Ergebnis davon abhängt, welche Schnittstelle zu senken ist. Wenn wir die TCP-Verbindungen an einer der Schnittstellen der Teilnehmer verringern, hat dies Auswirkungen, da die deklarierte MSS der minimalen Paketgröße entspricht. Wenn es sich jedoch nicht um Endpunkte, sondern um einen der Transitrouter handelt, hat dies keine Auswirkungen, wenn die Option --clamp-mss-to-pmtu nicht aktiviert ist.

Ich hoffe, dieser Artikel wird Ihnen helfen, ein ähnliches Problem sowohl zu Hause als auch mit Ihren Freunden und Bekannten zu lösen. Ich wende mich noch einmal an die Experten der Anbieter - OHNE EXTREME ANFORDERUNGEN ICMP TYPE 3 CODE 4 NICHT BLOCKIEREN - dies schafft Probleme für Ihre Kollegen.

Jetzt auch beliebt: