Warum die Wi-Fi-Angabe deines Routers den VPN-Durchsatz nicht vorhersagt

Ein Router mit einem Wi-Fi-Aufkleber von 3,000 Mbps kann verschlüsselten Datenverkehr trotzdem nur mit einem Bruchteil dieser Zahl bewegen, und keine der beiden Zahlen ist unehrlich. Die Funkbewertung beschreibt eine Best-Case-Modulation der Funkstrecke, die der Chipsatz unterstützt; die VPN-Zahl beschreibt, wie schnell ein Gerät verschlüsselte Pakete durch die CPU des Routers und aus deiner Zugangsleitung hinaus schieben kann. Das sind verschiedene Schichten, verschiedene Paketgrößen und verschiedene Messmethoden. Behandle die Zahl auf der Schachtel als Obergrenze, die niemand erreicht, nicht als Prognose für deine Tunnelgeschwindigkeit.

Schritt 1: Bilde die vier Schichten ab, die die Zahl begrenzen

Fast jede Beschwerde über einen langsamen Router, die ich bearbeitet habe, landet in einer von vier Ebenen: der Funkstrecke, der WAN-Zugangsrate, dem Weiterleitungspfad (NAT, Firewall, Verbindungsverfolgung) oder dem VPN-Kryptopfad. Sie stapeln sich, und die langsamste Ebene bestimmt das Ergebnis. Eine beworbene Wi-Fi-Rate spricht nur über die erste Ebene, und sie spricht großzügig darüber.

Diese Zahl ergibt sich aus Streams mal Kanalbreite mal der höchsten Modulation, die der Chipsatz aushandeln kann. Ein 2x2-Funk auf 5 GHz bei 80 MHz mit 1024-QAM wird mit knapp 1,200 Mbps beworben, aber Wi-Fi ist ein geteiltes Halbduplex-Medium: Clients wechseln sich ab, Wiederholungen und Verwaltungsverkehr verbrennen Sendezeit, und TCP legt seinen eigenen Overhead obendrauf. Ein Client, der unter idealen Bedingungen die Spitzenrate aushandelt, misst meist deutlich unter der Hälfte davon und weniger, sobald Nachbarnetze auftauchen.

Wenn die Tabelle auf den Funk zeigt, repariere zuerst die Funkseite: Band, Kanalbreite, Entfernung. Wenn sie unter den Funk zeigt, zählen die nächsten vier Schritte, und kein Antennenkauf wird das ändern.

Schritt 2: Nimm eine kabelgebundene Basislinie, bevor du den Funk anfasst

Steck das Notebook an Ethernet und miss zuerst den Pfad ohne den Tunnel, denn das gibt dir einen Nenner. Starte das Durchsatzwerkzeug auf der Gegenseite, auf dem VPS oder Heimserver, der das VPN beendet, und richte den Client auf dessen öffentliche Adresse, damit der Verkehr durch deinen Router und deine Zugangsleitung läuft.

# on the far host (VPN endpoint)
iperf3 -s

# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30

# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4

Zwei Zahlen aus diesem Block beantworten verschiedene Fragen. Ein Stream zeigt die Obergrenze pro Verbindung, die das Verhalten des TCP-Fensters und jede Formung pro Fluss auf dem Pfad einschließt. Vier Streams zeigen, ob die Strecke Kapazität hat, die du nicht nutzt, denn parallele Flüsse können eine Leitung füllen, die ein einzelner Fluss nicht füllt.

Halte es ehrlich: gleicher Host, Tageszeit und Dauer, und nichts anderes streamt im Haus. Eine Übertragung über dreißig Sekunden ist hier die richtige Einheit, und RFC 6349, der Rahmen für TCP-Durchsatztests, beruht genau auf dieser Überlegung, weil kurze Schübe und kleine Anfragen einer Strecke schmeicheln. Schreib die Basislinie auf, bevor du etwas änderst.

Schritt 3: Führe denselben Test durch den Tunnel aus

Wiederhole ihn jetzt gegen die Tunneladresse des Endpunkts, mit gleichem Client, gleicher Dauer und gleicher Streamzahl, bei aktivem Tunnel und ohne anderen Verkehr. Das Verhältnis der beiden Ergebnisse sagt dir, was Verschlüsselung und Kapselung auf dieser Hardware kosten; die absolute Zahl sagt dir, ob es für die Aufgabe reicht.

Beobachte die Zähler, während die Übertragung läuft. Bei WireGuard meldet wg show übertragene Bytes pro Peer; bei OpenVPN gibt dir eine Statusdatei, die im Intervall geschrieben wird, dieselbe Sicht.

watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status

Liegt die Tunnelzahl nahe der kabelgebundenen Basislinie, ist das VPN nicht dein Engpass, und du kannst aufhören, es zu beschuldigen. Ist sie nur ein Bruchteil der Basislinie, ist der Verlust im Krypto- und Weiterleitungspfad des Routers entstanden, und der nächste Schritt sagt dir, in welchem Teil.

Eine Warnung: Sobald sich die Exit-IP ändert, wählen manche Geschwindigkeitstests still einen anderen Messserver, sodass du am Ende zwei Ziele vergleichst. Pinn die Serveradresse selbst fest.

Schritt 4: Lies die CPU als Pfad, nicht als Durchschnitt

Ein Router, der 30 Prozent Gesamt-CPU zeigt, kann trotzdem gesättigt sein: Die Arbeit eines Tunnels landet meist auf einem Kern, einer Interrupt-Queue oder einem Kernel-Thread, sodass der Durchschnitt die Obergrenze verdeckt. Sieh dir Zahlen pro Kern und softirq an statt der Anzeige im Dashboard.

mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo

Drei Dinge zählen in dieser Ausgabe. Ein einzelner Kern nahe 100 Prozent, während die anderen untätig sind, deutet auf ein Limit pro Verbindung hin. Hoher %soft oder ein beschäftigter ksoftirqd auf einer CPU deutet auf Paketverarbeitung auf der Empfangsseite hin, die sich nicht über die Queues verteilt. Und ein fehlendes aes-Flag bedeutet, dass die CPU keine AES-Instruktionen hat, also läuft symmetrische Verschlüsselung in Software und kostet pro Paket viel mehr.

Auch die Implementierung zählt. Eine traditionelle OpenVPN-Instanz im Userspace verarbeitet die Pakete eines Tunnels weitgehend an einer Stelle, sodass eine schnelle Mehrkernbox für diesen Tunnel wie eine Einkernbox wirken kann. WireGuard im Kernel verteilt die Arbeit über CPUs, und das Data-Channel-Offload von OpenVPN verschiebt die Paketverarbeitung ebenfalls in den Kernel, aber nur in Builds und auf Plattformen, die es unterstützen. Eine Hardwarebeschleunigungs-Angabe auf der Marketingseite ist kein Beweis dafür, dass der Codepfad, den du ausführst, sie nutzt.

Schritt 5: Entscheide, was du änderst, in dieser Reihenfolge

Arbeite die Liste nach unten ab und stoppe bei der ersten Zeile, die zutrifft, denn alles darunter zu ändern bewegt die Zahl nicht.

1. Der kabelgebundene Direktdurchsatz liegt unter dem, was du bezahlst: Sprich mit dem Anbieter, denn der Tunnel kann keine Kapazität schaffen, die die Zugangsleitung nicht liefert. 2. Kabelgebunden direkt ist gut, aber ein Kern pinnt während des Tunneltests: Der Kryptopfad des Routers ist die Grenze. 3. Die CPU ist untätig, aber der Tunnel ist langsam: Prüfe MTU und Fragmentierung, dann die eigene Kapazität des fernen Endpunkts. 4. Nur Wi-Fi-Clients sind langsam: Wechsle Band oder Kanalbreite und akzeptiere, dass die beworbene Rate nie eine VPN-Zahl war.

Wenn der Router wirklich die Grenze ist, sind die ehrlichen Optionen ein Gerät mit AES-Instruktionen und einem schnelleren Weiterleitungspfad, ein Tunnel auf Kernelseite wie WireGuard statt einem im Userspace, oder den Client auf das Gerät selbst zu ziehen, damit der Router aufhört zu verschlüsseln. Authentifizierte Verschlüsselung abzuschalten, um einen Benchmark zu gewinnen, gehört nicht dazu; das tauscht eine Sicherheitseigenschaft gegen eine Zahl, die immer noch nicht zur Schachtel passt.

Bevor du etwas kaufst, führe Schritt 2 und 3 auf dem neuen Gerät mit demselben Server und derselben Dauer erneut aus, und vergleiche dann Verhältnisse statt Spitzen.