Seiten laden, aber Uploads stocken im VPN: Welche Ursache gewinnt
Ein größenabhängiges Stocken passt zu einem Pfad-MTU-Fehler, aber auch zu DNS, einem Anwendungslimit oder einem flatternden Tunnel. Vier Beobachtungen entscheiden, welche davon zutrifft.
Seiten laden, das VPN meldet sich verbunden, und ein Datei-Upload friert jedes Mal an derselben Stelle ein. Vier Erklärungen passen zu dieser Beschreibung: ein Paketgrößenproblem, ein Namensauflösungsproblem, ein Anwendungslimit und ein Tunnel, der sich ständig zurücksetzt. Jede davon lässt sich durch eine andere Beobachtung bestätigen oder ausschließen, also geht es bei der Entscheidung um die Wahl des richtigen Tests statt um das Raten der Ursache.
Vier Kandidaten und eine Form
Beginne mit der Form des Fehlers, denn sie schließt den größten Teil der Liste aus, bevor irgendein Werkzeug geöffnet wird. Ein Stocken bei einer gleichbleibenden Größe ist ein Größenproblem, bis das Gegenteil bewiesen ist. Ein Stocken an zufälligen Stellen ist ein Verlust- oder Stabilitätsproblem. Ein Fehler, bevor die Verbindung aufgebaut wird, ist ein Namensproblem.
Der vierte Kandidat ist die Anwendung. Upload-Limits, Request-Timeouts und Body-Size-Obergrenzen des Proxys erzeugen Fehler, die im Browser wie Netzwerkfehler aussehen, und sie treffen meist als Ablehnung ein, nicht als Hänger.
Schreibe die beobachtete Form auf, bevor du etwas testest. „Bleibt bei ungefähr derselben Byte-Zahl stehen, jedes Mal, bei aktivem Tunnel“ ist ein viel stärkerer Ausgangspunkt als „Uploads funktionieren nicht“.
Halte dann den Pfad beim Testen fest. Ausgang, Protokoll und Server gleichzeitig zu ändern liefert ein Ergebnis, das du keinem davon zuordnen kannst. Eine Variable pro Durchlauf, und schreib sie auf.
Halbiere die Größe, bevor du an die Richtlinie gehst
Der billigste Unterscheider ist eine Sonde, die eine Zahl variiert. Sende Do-not-fragment-Pings mit steigender Größe an das Ziel, lade eine Datei, die du kontrollierst, zum selben Dienst hoch und vergleiche dann, wo jedes davon stoppt.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadDer erste Befehl meldet, ob ein Paket voller Größe den Pfad überhaupt übersteht. Bei einer MTU von 1500 Byte ist die größte ICMP-Payload, die nicht fragmentiert wird, 1472 Byte, und ein Tunnel nimmt mehr aus diesem Budget, bevor das innere Paket beginnt. Der zweite liefert dir eine Größe und eine Dauer für eine Übertragung auf Anwendungsebene, und das ist die Zahl, auf die es wirklich ankommt.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Lies das Paar zusammen. Sonden, die oberhalb einer Schwelle scheitern, und ein Upload, der nahe derselben Schwelle stoppt, sind eine stimmige Geschichte. Sonden, die alle erfolgreich sind, während der Upload bei einer Byte-Zahl stockt, die der Pfad offensichtlich trägt, deuten auf die Anwendung oder den Server, und keine MTU-Arbeit wird das ändern. Dieses negative Ergebnis ist so viel wert wie ein positives. Es entfernt den teuersten Zweig der Untersuchung.
Prüfe dann die Stabilität während der Übertragung, denn ein Tunnel, der mitten in einem großen Upload den Schlüssel erneuert, erzeugt einen Fehler, der größenabhängig aussieht, ohne es zu sein. Der Uptime-Wert ist der billigste Weg, das zu belegen.
Zwischen Reparatur und Behelfslösung entscheiden
Wenn die Belege auf die Größe deuten, gibt es zwei ehrliche Antworten und eine unehrliche. Die ehrlichen sind, die Pfad-MTU-Erkennung wiederherzustellen, indem man das nötige ICMP-Feedback zulässt, oder die angekündigte Segmentgröße zu begrenzen, damit Gegenstellen kleinere Segmente senden. Die unehrliche ist, eine Interface-MTU auf einen aus einem Forum kopierten Wert zu senken und nie zu prüfen, was sie geändert hat.
Die Wahl hängt davon ab, was du kontrollierst. In einem Netz, das du betreibst, ist das Zulassen der ICMP-Nachrichten die sauberere Lösung, weil sie den Mechanismus für jedes Protokoll funktionsfähig hält. Auf einem Pfad, den du nicht kontrollierst, ist die Begrenzung die praktikable Option, und sie sollte eng statt serverweit angewendet werden.
Wenn die Belege auf die Anwendung deuten, repariere die Anwendung oder ihre Proxy-Konfiguration. Eine 413-Antwort und eine hängende Verbindung sind verschiedene Fehler, und der zweite ist meist ein Timeout irgendwo in einer Kette, die einen Proxy mit eigenen Grenzen enthält.
So oder so, behalte die ursprünglichen Werte und teste nach dem Zurückrollen erneut. Eine Änderung, die mit einer funktionierenden Übertragung zusammenfällt, ist kein Beleg dafür, dass sie sie verursacht hat, und die Fähigkeit zum Rückgängigmachen ist das, was eine Diagnose von einem Zufall trennt.
Halte die Entscheidung fest, damit sie den nächsten Vorfall überlebt
Vier Fakten genügen: die beobachtete Fehlerform, die Sondenergebnisse, die vorgenommene Änderung und das Ergebnis des erneuten Tests. Damit kann die nächste Person erkennen, ob es dasselbe Problem ist oder ein neues mit demselben Symptom.
Notiere auch den Pfadkontext, denn ein MTU-Befund gilt für eine bestimmte Strecke. Ein Laptop, der zu Hause funktioniert und im Hotel scheitert, hat zwei Pfade, und eine auf einen davon angewendete Korrektur sagt nichts über den anderen.
Widerstehe schließlich der Zusammenfassung, „das VPN habe die Uploads kaputt gemacht“. Der Tunnel war in beiden Fällen vorhanden, im funktionierenden wie im fehlerhaften; geändert hat sich die Größe des Pakets, das der Pfad tragen musste, oder die Stelle, an der die Übertragung gestoppt wurde. Den tatsächlichen Mechanismus zu benennen, macht die Notiz nützlich.