Warum ein VPN bei großen Übertragungen hängt, bei kleinen aber nicht

Eine Seite lädt, ein Ping gelingt, und eine Dateikopie hängt jedes Mal an derselben Stelle. Dieses Muster deutet auf die Paketgröße hin, nicht auf Bandbreite oder Zugangsdaten. Kapselung fügt jedem Paket Bytes hinzu, sodass eine Nutzlast, die auf dem ursprünglichen Pfad passte, das Limit überschreiten kann, sobald sie durch einen Tunnel läuft. In diesen Gesprächen werden drei verschiedene Zahlen MTU genannt, und ihre Verwechslung führt zu einer Einstellung, die eine Anwendung repariert und eine andere zerstört.

Drei Zahlen, die man MTU nennt

Die Interface-MTU ist die konfigurierte Grenze für ein Paket auf dieser Verbindung. Die Pfad-MTU ist die kleinste Grenze entlang der Route; sie wird ermittelt, nicht konfiguriert. Die TCP-MSS ist die Nutzlastgröße, die ein Peer als empfangbar angibt, und sie leitet sich aus den beiden anderen ab, statt eine eigene physische Grenze zu sein.

Ein Tunnel hat eine innere und eine äußere Sicht. Das äußere Paket trägt das gekapselte plus die Header, die das Protokoll benötigt, daher ist die nutzbare innere Größe kleiner, als der äußere Pfad zulässt. Auch der Pfad zum VPN-Server unterscheidet sich vom Pfad des Servers zum Ziel.

Die Pfad-MTU-Ermittlung lässt einen Sender die funktionierende Größe erfahren, hängt aber davon ab, dass Rückmeldung ankommt. Filtert ein Zwischengerät die betreffenden ICMP-Nachrichten, sendet der Sender weiter Pakete, die nie vollständig werden, und das ist das klassische schwarze Loch. Das Symptom ist unverwechselbar, wenn man es kennt: Der Handshake gelingt, die erste Nutzlast voller Größe verschwindet, und die Verbindung wird schließlich zurückgesetzt oder hängt. Nichts im Anwendungsprotokoll sieht nach einem Netzwerkproblem aus.

Prüfen Sie den Pfad mit einer Nutzlast, die Sie kontrollieren

Eine Probe ist ein Beleg über eine Route und eine Größe, keine empfohlene Einstellung. Nehmen Sie einen Host, der antwortet, und variieren Sie nur die Größe der Nutzlast.

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

Der erste Befehl sendet eine Linux-Probe mit deaktivierter Fragmentierung und einer Nutzlast von 1372 Byte, der zweite macht dasselbe unter Windows, wo die Nutzlast mit -l gesetzt wird. Eine Antwort bedeutet, dass diese Größe den Pfad überstanden hat. Eine Meldung über nötige Fragmentierung ist aufschlussreich, während ein Timeout mehrdeutig ist, weil der Host oder ein Zwischengerät ICMP einfach verwerfen kann.

Tasten Sie die Größe in wenigen Schritten ab, statt bis auf das Byte binär zu suchen. Sie wollen feststellen, ob eine Größengrenze existiert, nicht für jedes Netz eine Zahl veröffentlichen. Die Zahl, die Sie finden, gilt für diesen Pfad, dieses Protokoll und diese Adressfamilie.

IPv4 und IPv6 fragmentieren unterschiedlich, daher sagt ein Probenergebnis der einen Familie nichts über die andere. Testen Sie die Familie, die die Anwendung tatsächlich nutzt.

MSS-Clamping hilft nur TCP

Bei TCP wird die effektive Nutzlast während des Handshakes ausgehandelt, und ein Router auf dem Pfad kann diesen Wert nach unten umschreiben, damit beide Endpunkte kleinere Segmente senden. Das leistet MSS-Clamping, und es funktioniert, ohne den Client überhaupt anzufassen.

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

Die erste Regel begrenzt die angekündigte MSS für weitergeleitete TCP-Handshakes auf die Pfad-MTU, und die zweite zeigt die eigene MTU des Tunnel-Interfaces, damit Sie sie mit dem vergleichen können, was der Pfad zulässt. Clamping ist die am wenigsten invasive Reparatur für eine TCP-Anwendung, die nach dem Handshake hängt.

Für UDP bewirkt es nichts. Ein Sprach- oder Spieleclient, der große Datagramme sendet, ignoriert eine MSS-Einstellung völlig, weil es keinen Handshake zum Umschreiben gibt. Wenn die fehlerhafte Anwendung UDP nutzt, sehen Sie sich stattdessen die Paketgrößenoptionen des Clients an. Die beiden Protokolle scheitern unterschiedlich und werden mit unterschiedlichen Werkzeugen repariert, deshalb gehört das Protokoll in den ersten Satz des Tickets.

OpenVPN bietet Optionen wie tun-mtu, mssfix und fragmentbezogene Einstellungen, und ihr Verhalten hängt von der Version und davon ab, ob der Datenkanal AEAD ist. Lesen Sie das Handbuch für die verwendete Version und ändern Sie jeweils eine Option.

Ändern Sie eine unterstützte Einstellung und wiederholen Sie beide Läufe

Behalten Sie das ursprüngliche Profil, ändern Sie einen einzigen unterstützten Wert und wiederholen Sie sowohl die kleine Anfrage, die funktionierte, als auch die große Übertragung, die scheiterte. Ändert sich nur die große, haben Sie die Größe gejagt. Ändern sich beide, hat sich etwas anderes mitbewegt.

Ein niedrigerer Wert kann das Symptom lindern und fügt doch Overhead hinzu, daher ist die kleinstmögliche Zahl nicht das Ziel. Das Ziel ist eine Größe, die der Pfad zuverlässig mit dem geringsten Verlust trägt. Notieren Sie Wert, Pfad und Client-Version im Ticket, denn dieselbe Zahl anderswo anzuwenden ist eine Vermutung.

Funktioniert dasselbe Profil aus einem anderen vertrauenswürdigen Netz, halten Sie diesen Unterschied in der Diagnose fest, statt den Client für repariert zu erklären. Die Variable, die sich geändert hat, ist der Pfad, und der Pfad ist das, was die Probe gemessen hat.