VPN-Upload langsamer als Download? Finden Sie heraus, welche Grenze Sie treffen

Die meisten Zugangsleitungen sind asymmetrisch, deshalb lädt ein Tunnel normalerweise langsamer hoch als herunter, und das ist die erwartete Antwort und kein Fehler. Die interessante Frage ist, ob Ihr Upload durch die Leitung begrenzt wird, durch etwas anderes, das sie bereits nutzt, oder durch einen Fluss, der stockt, statt gleichmäßig zu laufen. Diese drei erzeugen dieselbe Beschwerde und erfordern unterschiedliche Arbeit.

Drei Grenzen, die von der Fortschrittsanzeige aus gleich aussehen

Die Kapazität ist die erste, und sie ist eine Eigenschaft des Zugangsprodukts, nicht des Tunnels. Ein Uplink von wenigen Megabit ist bei Glasfaser für Privatkunden und bei vielen Mobilfunktarifen normal, und der Verschlüsselungsaufwand ist im Vergleich zu dieser Lücke klein. Die Kapselung fügt außerdem Bytes pro Paket hinzu, was den Nutzdurchsatz in beide Richtungen verringert und nicht nur in eine, sodass sie allein eine große Asymmetrie nicht erklären kann.

Die Konkurrenz ist die zweite. Cloud-Synchronisierung, Fotobibliotheken und Update-Agenten laden hoch, während der Rechner untätig wirkt, und ein zweites Gerät an derselben Leitung tut dasselbe. Die Warteschlange ist die dritte: ein gesättigter Uplink schiebt interaktiven Verkehr hinter Massendaten, sodass Gespräche abbrechen, während der Transfer selbst gesunden Fortschritt meldet.

Messen Sie eine Richtung nach der anderen

Verwenden Sie dasselbe Gerät, dasselbe Profil und dasselbe Ziel, und lassen Sie niemals beide Richtungen gleichzeitig laufen, es sei denn, Sie wollen genau die Konkurrenz beobachten. Pausieren Sie Ihre eigenen optionalen Übertragungen vor dem ersten Lauf. Zwei Läufe mit einem Schalter dazwischen klären das meiste.

iperf3 sendet standardmäßig vom Client, der einfache Lauf misst also Ihren Upload-Pfad; -R kehrt die Richtung um und misst den Download. Führen Sie sie mit einigen Minuten Abstand aus und notieren Sie beide Zahlen, statt sie zu mitteln:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Wenn die Upload-Zahl ein kleiner Bruchteil der Download-Zahl ist und über die Läufe stabil bleibt, entspricht die Form einer asymmetrischen Zugangsleitung, und der Tunnel ist nicht die Geschichte. Wenn der Upload zwischen den Läufen schwankt oder nach zehn Sekunden zusammenbricht, lesen Sie weiter.

Entscheiden Sie daran, wo sich der Upload ändert

Ändern Sie jeweils eine Variable und beobachten Sie, welche Richtung sich bewegt. Ein zweiter VPN-Endpunkt, der besser hochlädt, deutet auf diesen Endpunkt oder die Route dorthin. Derselbe langsame Upload von einem zweiten Gerät an derselben Leitung deutet auf die Leitung. Ein anderes Gerät an einer anderen Leitung, das ebenfalls langsam ist, deutet auf die Eingangsrichtlinie des Ziels, die Sie lokal nicht beheben können.

Notieren Sie Bytes pro Sekunde und die verstrichene Zeit für dieselbe Last, nicht eine einzelne Geschwindigkeitspunktzahl. Ein Backup-Client und ein Geschwindigkeitstest verwenden unterschiedliche Ziele und unterschiedliche Parallelität, daher beantwortet der Vergleich ihrer Zahlen nichts. Wenn kleine Anfragen in Ordnung sind und nur große Übertragungen kriechen, ist die Grenze wahrscheinlich gar nicht die Bandbreite.

Für den Alltag hilft es oft mehr als jede Tunnel-Einstellung, einen Hintergrund-Upload zu begrenzen oder außerhalb der Besprechungszeiten zu planen. Beurteilen Sie diese Änderung an der kombinierten Last: Ein Backup, das später fertig wird, aber keine Gespräche mehr ruiniert, ist meist der bessere Tausch.

Wenn Stocken die Langsamkeit schlägt

Eine Übertragung, die an einem wiederholbaren Punkt einfriert und dann weiterläuft, verhält sich wie ein MTU-Problem des Pfads und nicht wie eine Ratenbegrenzung. Der Tunnel verringert die nutzbare Nutzlast pro Paket, und ein Gerät, das die resultierende ICMP-Nachricht verwirft, lässt den Absender raten. Dieses Muster verdient einen eigenen Test, denn die Reparatur unterscheidet sich vom Einstellen einer Rate. Eine stetig niedrige Zahl deutet auf Kapazität, ein Ausbruch gefolgt von Stille auf eine Nutzlast, die der Pfad nicht tragen kann.

Testen Sie den Pfad mit einer Nutzlast, die nicht fragmentiert werden darf, und vergleichen Sie dann die MTU der Tunnel-Schnittstelle mit dem Wert, der durchkommt:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Wenn die große Sonde verschwindet, während eine kleinere erfolgreich ist, klemmen Sie die TCP-MSS am Tunnel fest, statt die Schnittstellen-MTU für jedes Protokoll zu senken. Anhaltendes Stocken nach diesem Punkt gehört zum Speicher oder zur Taktung der empfangenden Anwendung, nicht zum Netzwerkpfad.

Was Sie ändern und was Sie lassen sollten

Ändern Sie die Dinge, die Sie kontrollieren: Zeitpläne für Hintergrundübertragungen, die Wahl des Endpunkts und die MSS für einen stockenden Pfad. Halten Sie jede Änderung umkehrbar und auf eine Last beschränkt. Lassen Sie die Dinge in Ruhe, die die Messung als in Ordnung bezeichnet, einschließlich einer Download-Rate, die bereits zur Leitung passt.

Schreiben Sie die Zahlen vorher und nachher zusammen mit Profil, Endpunkt und Tageszeit auf, denn ein Upload-Problem, das mit dem Endpunkt wandert, ist eine Routing-Frage, und eines, das mit dem Gerät wandert, ist lokal. Dieser Eintrag ist es, der eine vage Beschwerde in eine Entscheidung verwandelt, und er kostet zwei Läufe desselben Befehls.