Große Pakete verschwinden über IPsec, während kleine Pings weiter funktionieren

Entfernte Shells bleiben reaktionsfähig, kleine Sonden antworten, und dann kriecht eine Dateikopie und bleibt hängen, ohne einen Fehler, auf den jemand zeigen könnte. Ein Ping mit größerer Nutzlast reproduziert es sofort, und derselbe Transfer funktioniert aus dem lokalen Netz. An der Verschlüsselung ist nichts langsam; bestimmte Pakete kommen nie an. Zwei verschiedene Teilungen können diese Signatur erzeugen, und sie hinterlassen unterschiedliche Beweise.

Zwei Stellen, an denen ein Paket geteilt werden kann

Vor der Verschlüsselung kann der Router ein übergroßes inneres Paket teilen und jedes Stück einzeln schützen. Nach der Verschlüsselung wird das fertige äußere Paket geteilt, und die Gegenseite muss es wieder zusammensetzen, bevor sie irgendetwas entschlüsseln kann. Gleiches Symptom, andere Arbeit für den Empfänger und andere Stellschrauben für Sie.

Der Unterschied ist wichtig, weil eine Korrektur auf der falschen Seite eine Zahl ändert, ohne den Fehler zu verschieben. Ein am Interface abgelehntes Paket wird nie zu einem äußeren Paket, also kann keine Einstellung auf der Außenseite es retten.

Wo die Größenentscheidung wirklich fällt

Ein Tunnelinterface trägt eine IP MTU, und dieser Wert kann ein übergroßes inneres Paket ablehnen, lange bevor die IPsec-Stufe es sieht. Ein Bit im äußeren Header zu setzen, überprüft diese frühere Entscheidung nicht, weil das Paket bereits abgelehnt wurde. Deshalb verschlechtert eine höhere innere MTU die Lage manchmal, statt sie zu verbessern. Lesen Sie den Interfacewert und das äußere Verhalten, bevor Sie eines von beiden ändern, denn die billigere Änderung ist meist die, die das Symptom erklärt.

Prüfen Sie zuerst den Interfacewert, dann das äußere Verhalten. Zwei Zahlen, zwei Stufen, und meist ist nur eine davon verantwortlich.

Das äußere Budget ist nicht das innere Budget

Jede Kapselung verbraucht Bytes für Header, und die Menge hängt vom Transport, der Adressfamilie und davon ab, ob NAT-Traversal im Spiel ist. Ein inneres Paket, das auf den lokalen Link passt, kann immer noch ein äußeres Paket erzeugen, das nicht auf den Pfad dahinter passt. Messen Sie den Overhead, statt ihn anzunehmen, denn jeder optionale Header schlägt auf die Rechnung. Ein Tunnel mit NAT-Traversal zahlt mehr als ein nackter, und der Unterschied reicht aus, um einen Transfer zu brechen, der gestern funktionierte.

Trägt das äußere Paket das Do-not-fragment-Bit, verwirft ein Hop, der es nicht weiterleiten kann, das Paket und sollte eine ICMP-Nachricht zurückgeben. Wird diese Nachricht irgendwo gefiltert, versucht der Sender es weiter, und der Benutzer sieht einen Stillstand ohne Erklärung. Dieser stille Verwerf ist der übliche Grund, warum ein Größenproblem als Geschwindigkeitsproblem gemeldet wird.

IPv6 entfernt eine der Optionen

IPv6-Router fragmentieren nicht im Transit, also passt das äußere Paket entweder oder es verschwindet mit einer Packet-Too-Big-Nachricht. Diese Nachricht wird der einzige Rückmeldungskanal, und sie zu blockieren bricht die Pfaderkennung für jeden folgenden großen Transfer. IPv4-Router dürfen ein großes Paket fragmentieren, wenn das Bit klar ist, was den Fehler verbirgt, bis etwas anderes dieses Bit setzt.

Auf einem gemischten Stack kann sich derselbe Tunnel für die beiden Familien unterschiedlich verhalten, weshalb ein Test über IPv4 eine IPv6-Beschwerde nicht klärt. Eine Prüfung, die nur eine Familie beansprucht, lässt die Hälfte der Antwort ungemessen.

TCP-Segmentpolitik ist keine allgemeine Antwort

Das Begrenzen der maximalen Segmentgröße hilft TCP-Flüssen und ist eine legitime Kontrolle, wenn das Problem auf sie beschränkt ist. Auf UDP hat es keine Wirkung, und UDP trägt DNS, einige Sprachprotokolle und einen wachsenden Anteil des Webverkehrs.

Wenden Sie es an und testen Sie dann die Arbeitslast, die gescheitert ist. Scheitert der UDP-Fall weiterhin, war die Segmentpolitik nie die Antwort, und das Interface-Budget braucht weiter Aufmerksamkeit. Bestimmen Sie zuerst das Protokoll der scheiternden Arbeitslast und wählen Sie dann die Kontrolle, die dazu gehört.

Die Reihenfolge der Arbeit

Notieren Sie die größte Nutzlast, die überlebt, dann die Interface-MTU, dann ob das äußere Paket das Do-not-fragment-Bit trägt, und schließlich ob die ICMP-Rückmeldung den Sender erreicht. Diese Reihenfolge grenzt den Fehler ein, ohne zu raten. Halten Sie jede Beobachtung mit Zeitstempel und Endpunkt fest, denn alle vier Zahlen verschieben sich, wenn sich der Pfad ändert.

Ändern Sie einen Wert, testen Sie den ursprünglichen Transfer erneut und behalten Sie das Ergebnis. Ein Tunnel, der eine große Sonde besteht, aber in der Anwendung weiter hängt, ist zu einem anderen Problem übergegangen, und das ist Fortschritt, der es wert ist, notiert zu werden. Der nächste Mensch hätte lieber die Zahlen als die Schlussfolgerung.