MSS-Clamping auf einem VPN-Gateway: Was es behebt und was nicht

Kleine Anfragen funktionieren, große Downloads hängen, und jemand schlägt MSS-Clamping vor. Der Vorschlag ist oft genug richtig, um einen Versuch in der richtigen Reihenfolge zu verdienen, und oft genug falsch, um einen Nachmittag zu verschwenden, wenn man ihn blind anwendet. Die drei Prüfungen unten trennen ein echtes TCP-Größenproblem von einem UDP-Problem, von einer kaputten Path-MTU-Erkennung und von einem Clamp, der den Handshake nie sieht, den er umschreiben soll.

Beginnen Sie mit der Form des Fehlers

Ein Größendefekt hat eine Signatur: Die Verbindung kommt zustande, Authentifizierung und kleine Antworten gelingen, und dann bleibt eine Übertragung unbegrenzt stehen, sobald sie ein Segment voller Größe braucht. Seiten, die Text laden, aber nie ein Bild fertig bekommen, sind derselbe Fehler in kleinerem Maßstab. Wenn gar nichts verbindet, liegt das Problem früher im Pfad und Clamping hilft nicht. Ein Clamp kann keinen Handshake reparieren, der nie ankam.

Die Signatur existiert, weil der Handshake der Ort ist, an dem die Segmentgröße vereinbart wird. Jede Seite kündigt eine maximale Segmentgröße als TCP-Option an, und Sender respektieren die Ankündigung des Gegenübers. Kann der Pfad ein so großes Segment nicht tragen, zeigt sich der Fehler später, wenn der Sender es endlich versucht.

Behalten Sie den Transport im Blick, während Sie dieses Symptom lesen. Clamping ist ein Umschreiben einer TCP-Option, also ist ein Sprach- oder Videoanruf, der unter demselben Tunnel stockt, kein MSS-Problem und wird durch Clamping nicht besser. Notieren Sie den Transport, bevor Sie eine TCP-Option anfassen.

Bepreisen Sie den Pfad und vergleichen Sie ihn dann mit dem Tunnel

Zwei Zahlen zählen, und sie werden oft verwechselt. Die Path-MTU ist das größte Paket, das der Pfad ohne Fragmentierung trägt, und die angekündigte MSS für IPv4 ist dieser Wert minus der 40 Byte IP- und TCP-Header, oder minus 60 für IPv6. Tunnelkapselung verbraucht einen Teil des Budgets, bevor das innere Paket überhaupt beginnt.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

Der Ping mit dem Do-not-fragment-Bit sagt Ihnen, ob ein Paket dieser Nutzlastgröße überlebt; passen Sie die Größe an, bis es scheitert, und Sie haben das Pfadlimit empirisch gefunden. Die tracepath-Ausgabe meldet die entlang der Route entdeckte MTU, was schneller ist, wenn es funktioniert, und weniger zuverlässig, wenn ein Zwischenhop die Sonden filtert.

Ziehen Sie nun den Overhead des Tunnels ab. Ein äußerer IP-Header, ein UDP-Header und ein tunnelspezifischer Header gehen alle von denselben 1500 Byte ab, daher ist die nutzbare innere MTU auf einem typischen Ethernet-Unterbau niedriger, als die physische Strecke vermuten lässt. Liegt die berechnete innere MTU unter dem, was Ihre Gegenstellen ankündigen, haben Sie einen echten Clamp-Kandidaten gefunden statt einer Vermutung. Liegt der berechnete Wert bereits über der Ankündigung der Gegenstellen, hören Sie hier auf und suchen Sie anderswo.

Setzen Sie den Clamp dorthin, wo der Handshake vorbeikommt

Ein Clamp funktioniert, indem er die MSS-Option in den SYN- und SYN-ACK-Paketen umschreibt, während sie das Gateway passieren. Sitzt die Regel auf einer Schnittstelle, die keine der beiden Richtungen je durchläuft, schließt die Aushandlung unverändert ab und das Symptom bleibt, weshalb die Platzierung das Ergebnis stärker entscheidet als der Wert.

Die Richtung ist die andere Hälfte. Clamping in nur einer Richtung repariert die Hälfte der Flows und lässt den Rest auf scheinbar sporadische Weise scheitern, also wenden Sie es auf beide Richtungen des weitergeleiteten Verkehrs an. Die klassische Linux-Form für eine Tunnelschnittstelle ist eine Mangle-Regel, die SYN-Pakete trifft:

iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Beachten Sie, was --clamp-mss-to-pmtu tatsächlich tut: es leitet den Wert aus der MTU der Route ab, was nicht immer das reale Nutzlastbudget des Tunnels ist. Bei einem routenbasierten Tunnel, bei dem sich innere Route und äußerer Pfad unterscheiden, ist ein in der vorigen Prüfung berechneter expliziter Wert vorhersehbarer als ein automatischer.

Prüfen Sie mit einer neuen Verbindung nach und halten Sie die Rückmeldung lebendig

Eine bestehende Verbindung behält die ausgehandelte MSS, weshalb Testen in derselben Sitzung nichts beweist. Öffnen Sie nach der Änderung eine frische Verbindung und lesen Sie den ausgehandelten Wert direkt ab, statt ihn aus einer Übertragung abzuleiten, die zufällig fertig wird.

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

Der erste Befehl meldet die MSS des Sockets zusammen mit seinem Überlastungszustand, was die schnellste Bestätigung ist, dass der Clamp gewirkt hat. Der zweite bestätigt, dass die Regel, die Sie hinzugefügt zu haben glauben, die vorhandene Regel ist, in der Tabelle, in die sie gesetzt wurde.

Dann schützen Sie den Mechanismus, den Sie nicht repariert haben. Die Path-MTU-Erkennung hängt davon ab, dass ICMP-Fragmentation-needed-Nachrichten den Sender erreichen, eine Firewall, die sie verwirft, wird also große Übertragungen weiter kaputt machen, selbst mit korrektem Clamp. Erlauben Sie diese Nachrichten für den Tunnelpfad oder akzeptieren Sie, dass Clamping eine Politik kompensiert, für die Sie sich entschieden haben.

Widerstehen Sie zuletzt der Versuchung, den Clamp als Stellschraube zu behandeln. Er begrenzt die Segmentgröße, was auf Pfaden Durchsatz kostet, die ihn nie brauchten. Nach den drei Prüfungen angewandt, ist er eine gezielte Reparatur; zuerst angewandt, ist er eine Änderung, die den ursprünglichen Fehler verdeckt und jedem späteren Test eine zweite Variable hinzufügt. Dieser Tausch lohnt sich bewusst, nicht standardmäßig.

Notieren Sie die gemessene Path-MTU, den abgezogenen Tunnel-Overhead, die hinzugefügte Regel und die danach gesehene MSS. Vier Zahlen machen den nächsten Vorfall zu einem Nachschlagen statt einer Untersuchung.