So testen Sie die VPN-Geschwindigkeit, damit die Zahlen etwas bedeuten

Ein Geschwindigkeitstest misst nie das VPN. Er misst einen Pfad, und das Einschalten des Tunnels ersetzt einen Teil dieses Pfads, bevor sich das erste Byte bewegt. Deshalb zeigt ein Laptop bei einer Seite einen gesunden Wert und bei einer anderen einen schlechten, ohne dass sich auf einer der beiden Seiten etwas geändert hätte. Lesen Sie das Ergebnis als Beweis über eine Route, nicht als Punktzahl für ein Produkt.

Drei Dinge entscheiden, ob der Vergleich etwas wert ist: ob beide Läufe dasselbe Ziel getroffen haben, ob das Zugangsnetz stillgehalten wurde und ob Sie die Verzögerung neben dem Volumen festgehalten haben.

Was der Tunnel vor dem ersten Byte umschreibt

Der Client packt jedes Paket in einen weiteren Header, sodass die nutzbare Nutzlast pro Paket schrumpft. Die Kosten fallen pro Paket an, nicht pro Übertragung, was bedeutet, dass eine große Datei mehr Pakete braucht als dieselbe Datei ohne Tunnel. Solcher Overhead zeigt sich als Paketanzahl, nicht als sichtbare Einstellung.

Daraus folgen zwei Konsequenzen. Ein Test aus großen Blöcken spürt die Kosten pro Paket, während ein Test aus vielen kleinen Anfragen stattdessen die Roundtrips spürt. Und wenn die Pfad-MTU-Erkennung irgendwo unterwegs blockiert wird, landet der Tunnel bei einer kleineren Paketgröße, und der Durchsatz fällt aus einem Grund, der nichts mit Verschlüsselungsverfahren zu tun hat.

Sie können die Obergrenze direkt beobachten. Fragen Sie unter Linux nach der größten Nutzlast, die ohne Fragmentierung durchkommt, und wiederholen Sie das dann mit aktivem Tunnel:

ping -M do -s 1472 -c 3 203.0.113.10

Schlägt das fehl, gehen Sie auf 1,400 herunter und versuchen es erneut. Ein Tunnel, der nur 1,380 Byte trägt, sagt Ihnen, dass etwas weiter unten auf dem Pfad enger klemmt, und kein Tuning am Client hebt das an.

Warum der Testserver wandert, wenn der Tunnel hochkommt

Die meisten Werkzeuge wählen einen nahen Server anhand der öffentlichen Adresse, die sie sehen. Mit aktivem Tunnel gehört diese Adresse zum Ausgangsknoten, also kann das Werkzeug einen Host in einer anderen Stadt oder einem anderen Land wählen. Dann vergleichen Sie zwei Ziele, und der Abstand zwischen ihnen enthält die Entfernung vom Ausgang zum Testhost.

Legen Sie den Server vor dem ersten Lauf per Name oder ID fest und halten Sie ihn für jeden weiteren Lauf. Wenn das Werkzeug ihn nicht hält, wählen Sie ein Ziel, das Sie kontrollieren, und steuern es selbst: iperf3 -c test.example.net -R -t 20 hält das Ziel fest und liefert Ihnen eine Zahl, die Sie mit der von gestern vergleichen können.

Ändern Sie eine Variable, und der Unterbau ist keine

Funk ist die übliche versteckte Änderung. Die Signalstärke verschiebt sich, wenn der Laptop sich bewegt, und die Kanalbelegung verschiebt sich, wenn ein Nachbar ein Gespräch beginnt, also sind zwei Läufe zehn Minuten auseinander im WLAN keine Wiederholungen desselben Tests. Kabel, oder eine feste Position mit notiertem Signalpegel, entfernt den größten Teil dieses Rauschens. Eine Notiz des Signalpegels zu Beginn und am Ende jedes Laufs reicht meist, um zu zeigen, ob zwei Läufe zusammengehören.

Gerätelast gehört in dieselbe Kiste. Ein Client, der auf einem Kern verschlüsselt, stößt lange vor der Leitung an seine eigene Grenze, und eine Hintergrundsynchronisierung stößt früher an. Beobachten Sie die CPU während des Laufs und notieren Sie, was sonst noch offen war. Energieeinstellungen können hier ebenfalls zubeißen, denn ein Laptop im Akkubetrieb drosselt den Prozessor womöglich lange bevor die Leitung überhaupt ausgelastet ist.

Halten Sie den Unterbau still, statt über ihn zu mitteln. Drei Läufe, die übereinstimmen, sagen mehr als zehn in verschiedenen Räumen.

Verzögerung, Verlust und ICMP beantworten verschiedene Fragen

Ping schickt eine kleine Sonde an eine feste Adresse, und viele Netze antworten auf ICMP mit niedriger Priorität oder ignorieren es ganz. Fehlende Antworten beschreiben die Sonde, nicht die Pakete der Anwendung. Eine Umlaufzeit, die unter Last steigt, bedeutet meist, dass sich eine Warteschlange füllt, nicht dass die Route länger wurde.

Um zu erfahren, ob der Tunnel Verzögerung hinzufügt, vergleichen Sie ein Ziel mit und ohne ihn, oder vergleichen Sie zwei Ausgänge, die vom selben Zugangsnetz erreichbar sind. Führen Sie die Sonde mehrfach aus und schauen Sie auf die Streuung, denn ein Mittelwert verbirgt genau die Schwankung, die ein Gespräch unbrauchbar macht.

Zurück zu der Aufgabe, die sich langsam anfühlte

Ein Benchmark, der sich verbessert, während das Gespräch noch stockt hat etwas anderes beantwortet. Führen Sie die Aufgabe erneut aus, mit der die Untersuchung begann, ob das nun ein Meeting, eine Dateifreigabe oder eine Remotedesktop-Sitzung war. Wenn die Zahl besser wurde und die Aufgabe nicht, saß der Engpass dort, wo der Test nie hinkam, etwa beim Server hinter dem Tunnel oder bei Ihrer Upload-Strecke.

Protokollieren Sie jeden Lauf mit Gerät, Zugangsnetz, Endpunkt, Protokoll, Ziel und Zeit. Ein Lauf, der nie verbunden hat, ist ein Erreichbarkeitsergebnis und kein Durchsatz von null, also legen Sie ihn unter diesem Etikett ab, statt ihn zu löschen.

Eine kurze Liste vor dem nächsten Vergleich

Legen Sie das Ziel fest und schreiben Sie auf, warum Sie es gewählt haben. Notieren Sie die Paketgröße, die der Pfad zulässt, damit ein späterer Einbruch eine Erklärung hat. Halten Sie das Zugangsnetz identisch, notieren Sie die CPU-Last und nehmen Sie drei Läufe, bevor Sie einem Unterschied glauben.

Ändern Sie dann genau eine Sache und wiederholen Sie es. Der Vergleich, den Sie erklären können, schlägt den mit der größeren Zahl.