VPN-Ping funktioniert, Dateiübertragung stockt
Die erfolgreiche Übertragung kleiner Pakete garantiert nicht, dass auch größere Pakete den VPN-Pfad passieren. Schematische Darstellung.
Bei der Fernwartung einer Anlage meldet der Industrierouter eine aktive VPN-Verbindung. Ping-Anfragen werden beantwortet, und die Verbindung zur Steuerung lässt sich aufbauen. Trotzdem stockt eine Dateiübertragung, die Weboberfläche des Bediengeräts lädt nur teilweise oder eine größere Anfrage wird nicht abgeschlossen.
Prüfen Sie zuerst, ob der Fehler mit der Paketgröße auf dem tatsächlichen Anwendungspfad zusammenhängt. Ein erfolgreicher kleiner Ping beweist nicht, dass größere Pakete den Tunnel passieren können. VPN-Overhead und fehlende Rückmeldungen zur Path MTU sind mögliche Ursachen. Eine gescheiterte Übertragung einer großen Datei allein reicht jedoch nicht für eine MTU-Diagnose. RFC 2923 beschreibt den typischen Fall: Ping und interaktive Verbindungen funktionieren, während umfangreiche Datenübertragungen beim Senden größerer Pakete stocken.
DAS WICHTIGSTE IN KÜRZE
Testen Sie denselben Tunnel, dasselbe Ziel und denselben WAN-Pfad wie die betroffene Anwendung. Wiederholen Sie die Tests mit verschiedenen Paketgrößen und in beiden Richtungen.
Unterscheiden Sie zwischen dem inneren IP-Paket und dem gekapselten äußeren Paket. Der äußere Pfad muss den zusätzlichen VPN-Overhead aufnehmen können.
Leiten Sie Anpassungen aus den Paketgrößentests und den ICMP-Rückmeldungen ab. TCP-MSS-Clamping kann TCP-Verkehr helfen, verkleinert aber nicht direkt UDP-Datagramme.
Ändern Sie jeweils nur eine Einstellung, bauen Sie neue Verbindungen auf und wiederholen Sie die ursprünglich fehlgeschlagene Übertragung, bevor Sie die Störung als behoben dokumentieren.
WARUM GRÖSSERE PAKETE SCHEITERN
Die MTU bezeichnet hier die maximale IP-Paketgröße, die ein Link transportieren kann. Die Path MTU, kurz PMTU, entspricht der kleinsten MTU aller Teilstrecken auf dem Übertragungsweg. Ein Paket, das im Produktions-LAN Platz findet, kann nach der VPN-Kapselung auf dem Weg zum entfernten Gateway zu groß sein.
Kapselung benötigt zusätzliche Bytes. Beispielsweise kann IPsec NAT Traversal ESP in UDP transportieren. Die äußere IP-Version, das VPN-Protokoll und weitere Tunnel beeinflussen den Overhead. Aus einer WAN-MTU von 1500 lässt sich daher keine innere Tunnel-MTU von 1500 ableiten.
Bei der klassischen IPv4 Path MTU Discovery verwirft ein Router ein zu großes Paket mit gesetztem Don't-Fragment-Bit (DF), wenn er es nicht weiterleiten kann. Er sendet eine ICMP-Meldung „fragmentation needed“ zurück. Der Absender nutzt diese Rückmeldung, um die folgenden Pakete zu verkleinern. IPv6 PMTUD verwendet dagegen ICMPv6-Meldungen vom Typ Packet Too Big. Router auf dem Übertragungsweg fragmentieren IPv6-Pakete nicht.
Wird die notwendige Rückmeldung gefiltert oder falsch verarbeitet, kann der Absender weiterhin Pakete senden, die den Pfad nicht passieren. Prüfen Sie beim VPN sowohl, ob die Rückmeldung vom äußeren Pfad den Tunnelendpunkt erreicht, als auch, wie dieser den inneren Verkehr behandelt. Wer nur im LAN der SPS nach ICMP sucht, sieht nicht den gesamten Ablauf.
„Groß“ bezieht sich hier auf ein einzelnes Paket, nicht auf die Gesamtgröße der Datei. Tritt der Fehler nur bei einem bestimmten Dateityp, einer Anwendungsaktion oder nach einer festen Zeitspanne auf, ohne reproduzierbare Paketgrößengrenze, müssen auch andere Ursachen untersucht werden.
DEN VPN-PFAD TESTEN
Untersuchen Sie den tatsächlichen industriellen Anwendungspfad und wiederholen Sie anschließend die ursprünglich fehlgeschlagene Übertragung. Illustrative Industrieszene.
Verwenden Sie nach Möglichkeit Testrechner unter Ihrer Kontrolle an beiden VPN-Enden. Ihre Ergebnisse helfen bei der Eingrenzung des Pfads. Die abschließende Prüfung muss jedoch wieder mit der ursprünglichen speicherprogrammierbaren Steuerung (SPS), dem Bediengerät (HMI) oder dem betroffenen Anwendungsendpunkt erfolgen.
1. Den Pfad dokumentieren
Notieren Sie Routermodell, Firmware, VPN-Protokoll, innere und äußere IP-Version, WAN-Verbindung, Quell- und Zieladressen sowie die aktuellen MTU-/MSS-Einstellungen. Stellen Sie sicher, dass der Testverkehr tatsächlich durch den vorgesehenen Tunnel läuft. Ein Ping an die öffentliche Routeradresse, an seine Tunneladresse und an einen Rechner hinter dem Tunnel prüft unterschiedliche Pfade.
Reproduzieren Sie den ursprünglichen Fehler und halten Sie Richtung, Zeitpunkt und Fehlermeldung fest, bevor Sie Einstellungen ändern.
2. Paketgrößen testen
Beginnen Sie mit einem kleinen Paket, das zuverlässig ankommt. Erhöhen Sie die Größe und grenzen Sie den Bereich ein, in dem Fehler auftreten. Wiederholen Sie jede Größe: Ein einzelner Timeout kann gewöhnlicher Paketverlust sein.
Ersetzen Sie auf einem Linux-Testrechner mit iputils ping <remote-host-ip> durch die Adresse eines kontrollierten IPv4-Rechners, der über das VPN erreichbar ist:
ping -4 -M do -s 1200 -c 4 <remote-host-ip>
ping -4 -M do -s 1372 -c 4 <remote-host-ip>Dies sind beispielhafte Testpakete, keine empfohlenen MTU-Einstellungen. Laut iputils-ping-Handbuch legt -s die Datenlänge fest. -M do setzt DF, berücksichtigt aber weiterhin die PMTU-Prüfungen des Kernels. Mit 20 Byte IPv4-Header und 8 Byte ICMP-Header ergeben 1372 Datenbytes ein 1400 Byte großes inneres IP-Paket, noch ohne VPN-Overhead. Zusätzliche IP-Optionen verändern die Rechnung.
Die lokale Meldung „message too long“ kann bedeuten, dass der Kernel das Testpaket bereits vor dem Senden abgewiesen hat. Ein Timeout allein zeigt nicht, wo es verloren ging. Dokumentieren Sie Befehl, Nutzdatenlänge und Ergebnis. Für ICMP und Anwendungsverkehr können außerdem unterschiedliche Richtlinien gelten. Diese Linux-Befehle sind weder Router-CLI-Anweisungen noch IPv6-Tests.
3. ICMP-Rückmeldungen prüfen
Zeichnen Sie, soweit zugänglich, den Verkehr an den relevanten inneren und äußeren Schnittstellen beider VPN-Endpunkte auf. Suchen Sie nach der Stelle, ab der größere Pakete nicht mehr erscheinen, nach IPv4-Meldungen „fragmentation needed“ oder IPv6-Meldungen „Packet Too Big“ und danach, ob die Rückmeldung den richtigen Endpunkt erreicht.
Vergleichen Sie bei TCP den Verbindungsaufbau mit den anschließenden Daten und Wiederholungsübertragungen. Wiederholt gesendete große Segmente sind ein in RFC 2923 beschriebenes Indiz. Wiederholungsübertragungen allein belegen jedoch noch kein MTU-Blackhole, bei dem zu große Pakete ohne verwertbare Rückmeldung verloren gehen.
Beobachtung | Nächste Prüfung |
|---|---|
Relevante ICMP-Fehler erreichen einen Endpunkt, trotzdem bleiben die Pakete zu groß. | Verarbeitung am Endpunkt und effektive Tunnel-MTU prüfen. |
Fehler beginnen wiederholt bei einer bestimmten Paketgröße, Rückmeldungen sind jedoch nicht sichtbar. | Weitere Schnittstellen beobachten und Filterung beziehungsweise Rückwegverarbeitung untersuchen. |
Fehler hängen nicht konsistent mit der Paketgröße zusammen. | Neben der MTU-Hypothese auch Anwendungsverhalten, Geräteressourcen und Verbindungszustand prüfen. |
Fehlende ICMP-Meldungen an einem einzelnen Mitschnittpunkt beweisen nicht, dass kein Gerät solche Meldungen erzeugt hat.
4. Beide Richtungen testen
Prüfen Sie Übertragungen vom Anlagenstandort zur Fernwartungsstation und in umgekehrter Richtung getrennt. Ordnen Sie jedem Ergebnis Quelle, Ziel und WAN-Pfad zu. Ein kontrollierter Vergleich ohne VPN kann helfen, betrifft aber einen anderen Pfad und muss separat dokumentiert werden.
Ändern Sie MTU, MSS, Keepalive und VPN-Protokoll nicht gleichzeitig. Auch wenn die Übertragung danach funktioniert, lässt sich sonst kaum erkennen, welche Änderung wirksam war.
MTU ODER MSS ANPASSEN?
Übersteigt das gekapselte Paket die Kapazität des äußeren Pfads, prüfen Sie die Dokumentation der VPN-Implementierung zur effektiven Tunnel-MTU. Werden notwendige ICMP-Rückmeldungen blockiert oder falsch verarbeitet, korrigieren Sie diese Behandlung. Kleinere Pakete können den Betrieb wiederherstellen, ohne das zugrunde liegende Rückmeldungsproblem zu beheben. Halten Sie diesen Unterschied fest.
MSS begrenzt die TCP-Datenlänge
Die TCP MSS beschreibt die TCP-Datenlänge ohne IP- und TCP-Header. MSS-Clamping senkt den Wert, der in Paketen zum TCP-Verbindungsaufbau angekündigt wird, wenn diese ein Gerät mit einer entsprechenden Regel passieren. Das beeinflusst die späteren TCP-Segmentgrößen der Gegenstelle. Es ist nicht dasselbe wie eine geänderte Schnittstellen-MTU und verkleinert UDP-Datagramme nicht direkt.
Bei einer bereits ermittelten effektiven inneren IP-MTU von 1400 Byte ergibt das Abziehen ausschließlich der festen Header:
Innere IP-Version | Feste IP- und TCP-Header | Beispielhafte MSS |
|---|---|---|
IPv4 | 20 + 20 Byte | 1360 Byte |
IPv6 | 40 + 20 Byte | 1340 Byte |
Die MTU von 1400 Byte ist eine Rechenannahme, kein allgemeiner Einstellwert. RFC 6691 verlangt außerdem, dass der Absender die tatsächliche TCP-Datenlänge für mitgesendete IP- oder TCP-Optionen reduziert. Setzen Sie in diese Rechnung für innere Pakete nicht die MTU des äußeren Pfads ein.
Die MSS wird in SYN-Paketen einschließlich SYN-ACK ausgetauscht. Jede Ankündigung begrenzt, was der andere Endpunkt senden soll, wie RFC 9293 beschreibt. Bauen Sie nach einer Änderung der Clamping-Regel neue TCP-Verbindungen auf und prüfen Sie beide Richtungen. Eine bestehende Sitzung reicht nicht als Nachweis, dass die neue Regel greift.
Protokolleinstellungen unterscheiden
Das OpenVPN-2.6-Handbuch beschreibt mssfix für TCP im Tunnel und erklärt, dass die Option sinnvoll ist, wenn OpenVPN mit der Gegenstelle über UDP kommuniziert. Das Argument mtu ändert die Größenberechnung so, dass die äußeren IP- und UDP-Header enthalten sind. Behandeln Sie tun-mtu, mssfix und fragment nicht als austauschbar und übertragen Sie OpenVPN-Einstellungen nicht auf WireGuard oder IPsec.
Untersuchen Sie bei fehlerhaftem UDP-Verkehr die Datagrammgröße der Anwendung, die Kapselung und die Verfahren der Implementierung zur Ermittlung einer geeigneten Paketgröße separat. DPLPMTUD ermittelt nutzbare Paketgrößen mithilfe von Testpaketen und Empfangsbestätigungen, ohne auf ICMP-Packet-Too-Big-Rückmeldungen angewiesen zu sein. Ob das Verfahren verfügbar ist, hängt von der Anwendung oder Protokollimplementierung ab.
DIE LÖSUNG ÜBERPRÜFEN
Wiederholen Sie die ursprüngliche Übertragung über denselben Pfad. Prüfen Sie, ob sie vollständig abgeschlossen wird, kontrollieren Sie gegebenenfalls Dateigröße und Inhalt und testen Sie beide Richtungen mit neuen Verbindungen. Prüfen Sie bei Multi-WAN-Installationen jeden relevanten WAN-Pfad separat: Die PMTU kann sich mit dem Pfad ändern.
Bewahren Sie ein kurzes Übergabeprotokoll auf: ursprüngliches Fehlerbild, Testpfad, erfolgreiche und fehlgeschlagene Paketgrößen, beobachtete Rückmeldungen, Einstellungen vor und nach der Änderung, Übertragungsergebnisse und Rücksetzverfahren. Stellen kleinere Pakete den Betrieb wieder her, ohne dass die Engstelle bekannt ist, dokumentieren Sie: „Datenübertragung nach Anpassung der Paketgröße wiederhergestellt; Engstelle noch nicht lokalisiert.“
Für Wavetel-Geräte übermitteln Sie Modell, Firmware, VPN-Typ, Topologie und Testprotokoll an den technischen Support. Prüfen Sie die tatsächlich verfügbaren MTU-/MSS-Einstellungen und Mitschnittmöglichkeiten anhand der Firmware-Dokumentation. Eine Liste unterstützter VPN-Protokolle belegt diese Konfigurationsdetails nicht.
HÄUFIG GESTELLTE FRAGEN
Schließt ein erfolgreicher Ping MTU-Probleme aus?
Nein. Er bestätigt, dass dieses Testpaket in dieser Größe den Hin- und Rückweg bewältigt hat. Testen Sie größere Pakete und den tatsächlichen Anwendungspfad. Prüfen Sie anschließend, ob die Fehler konsistent mit der Paketgröße zusammenhängen.
Sollte jedes VPN MTU 1420 verwenden?
Nein. Die nutzbare Größe hängt vom Pfad und von der Kapselung ab. Ein Wert, der auf einer Verbindung funktioniert, kann auf einer anderen noch zu groß oder unnötig klein sein. Stützen Sie sich auf reproduzierbare Beobachtungen und die Dokumentation der Implementierung.
Warum hilft die MSS-Änderung nicht?
Prüfen Sie, ob eine neue TCP-Verbindung aufgebaut wurde, ob die Regel in der relevanten Richtung greift und ob sich die beobachteten SYN-/SYN-ACK-Werte geändert haben. UDP-Verkehr und Fehler ohne Bezug zur Paketgröße müssen separat untersucht werden.
Hilft WireGuard Keepalive bei großen Paketen?
PersistentKeepalive erhält NAT- oder Firewall-Zuordnungen während Leerlaufphasen. Es verändert die Kapazität des Pfads nicht. Bei einem nach längerer Inaktivität unerreichbaren Tunnel kann es relevant sein, nicht aber bei einer reproduzierbaren Paketgrößengrenze während laufender Übertragungen.
Kommentare