WireGuard langsam: Die echte Ursache finden

Woher langsame WireGuard-Geschwindigkeiten tatsächlich kommen

Langsame WireGuard-Verbindungen haben meist eine von vier Ursachen. Diese Ursachen sind jedoch nicht gleich wahrscheinlich. Die erste ist die MTU (Maximum Transmission Unit): Der Tunnel erzeugt Pakete, die für eine Verbindung im Übertragungsweg zu groß sind. Dadurch stocken umfangreiche Übertragungen, während kleine Übertragungen problemlos funktionieren. Die zweite Ursache ist der Übertragungsweg selbst, der bereits vor dem Einrichten des Tunnels die Begrenzung darstellte. Die dritte ist die CPU eines kleinen gemeinsam genutzten VPS, auf dem die Verschlüsselung mit allen anderen Gastsystemen auf demselben Host um Rechenzeit konkurriert. Die vierte ist die eigene Verbindung des Peers.

Prüfen Sie diese Ursachen in dieser Reihenfolge. Die MTU steht an erster Stelle, weil sie die einzige Ursache in dieser Liste ist, die WireGuard selbst einführt. Außerdem wirken ihre Symptome nicht wie eine langsame Verbindung. Eine falsche MTU zeigt sich meist an einem Tunnel, der sofort eine Verbindung herstellt, auf ping antwortet, eine SSH-Anmeldung akzeptiert und dann beim ersten Kopieren einer Datei einfriert.

Ein Symptom sollten Sie vor all diesen Prüfungen ausschließen. Wenn jede neue Website mehrere Sekunden benötigt, bevor sie mit dem Laden beginnt, und anschließend mit voller Geschwindigkeit übertragen wird, liegt das an der Namensauflösung und nicht am Datendurchsatz. DNS mit WireGuard hat eigene Fehlerursachen. Keine Änderung der MTU behebt diese Probleme.

Warum beträgt die WireGuard-MTU 1420?

Jedes Paket, das Sie in den Tunnel senden, wird verschlüsselt und in ein neues Paket eingebettet. Die zusätzliche Paketstruktur benötigt Bytes. Diese Bytes stehen dann nicht mehr für Ihre Nutzdaten zur Verfügung.

Der WireGuard-Datenheader ist 32 Bytes groß: ein 4 Byte großes Typfeld, ein 4 Byte großer Empfängerindex, ein 8 Byte großer Zähler und der 16 Byte große Poly1305-Authentifizierungstag. Darum liegt ein 8 Byte großer UDP-Header. Darum liegt wiederum der äußere IP-Header, der bei IPv4 20 Bytes und bei IPv6 40 Bytes groß ist. Die Kapselung benötigt daher insgesamt 60 Bytes, wenn es sich bei Ihrem Endpoint um eine IPv4-Adresse handelt, und 80 Bytes bei IPv6. Die WireGuard-Protokollseite dokumentiert das Nachrichtenformat, aus dem diese Werte stammen.

wg-quick schätzt diesen Wert nicht. Es liest die MTU der Schnittstelle aus, über die Ihr Endpoint geroutet wird, und zieht anschließend 80 ab. Auf einem normalen Ethernet-Pfad mit 1500 Bytes ergibt das 1420. Diesen Wert gibt ip link show wg0 aus. Es zieht 80 statt 60 ab, damit derselbe Wert auch dann sicher bleibt, wenn dieser Endpunkt irgendwann über IPv6 erreicht wird. Dort ist der äußere Header 20 Bytes größer.

[
  {
    "label": "Ethernet, IPv4 endpoint",
    "path_mtu": 1500,
    "encap_overhead": 60,
    "usable_wg0_mtu": 1440
  },
  {
    "label": "Ethernet, IPv6 endpoint",
    "path_mtu": 1500,
    "encap_overhead": 80,
    "usable_wg0_mtu": 1420
  },
  {
    "label": "PPPoE DSL, IPv4 endpoint",
    "path_mtu": 1492,
    "encap_overhead": 60,
    "usable_wg0_mtu": 1432
  },
  {
    "label": "Extra tunnel in the path",
    "path_mtu": 1400,
    "encap_overhead": 80,
    "usable_wg0_mtu": 1320
  }
]

Diese 4 Zeilen enthalten Rechenwerte, keine Messwerte. Auf einem unveränderten Pfad mit 1500 Bytes würde 1440 bei einem IPv4-Endpunkt passen. Der Standardwert 1420 lässt daher 20 Bytes ungenutzt. Dieser Spielraum ist beabsichtigt und stellt kein Problem dar.

Die letzte Zeile ist entscheidend. Wenn ein Abschnitt des Pfads nur 1400 Bytes transportiert, erzeugt ein Tunnel mit dem Wert 1420 bei jedem Segment mit maximaler Größe ein äußeres Paket von 1500 Bytes. Das sind 100 Bytes mehr, als dieser Abschnitt akzeptiert. Der passende Wert ist 1320.

Übernehmen Sie auch 1320 nicht einfach. Die Pfad-MTU hängt von Ihrem Pfad ab. Sie lässt sich nur durch eine Messung zuverlässig bestimmen.

Wie sich eine falsche MTU bemerkbar macht

Der Fehler tritt nicht schleichend auf. Kleine und große Pakete verhalten sich klar unterschiedlich.

• ping durch den Tunnel funktioniert bei jeder üblichen Größe.
• Eine SSH-Anmeldung wird abgeschlossen, und die Eingabe reagiert ohne Verzögerung.
• curl -I https://example.com liefert sofort Header zurück.
• curl https://example.com auf einer großen Seite bleibt nach den ersten Kilobytes hängen.
• scp einer großen Datei beginnt und bleibt dann bei einem bestimmten Prozentsatz stehen.
• Eine SSH-Sitzung friert in dem Moment ein, in dem Sie einen Befehl ausführen, der viel Ausgabe erzeugt.

Das geschieht, weil eine TCP-Verbindung erst dann Segmente in voller Größe erstellt, wenn größere Datenmengen übertragen werden. Der Handshake und die erste Anfrage passen unter jede MTU auf dem Übertragungsweg. Der Stillstand beginnt beim ersten Segment in voller Größe. Deshalb wirkt die Verbindung bis zu dem Punkt funktionsfähig, an dem sie unbrauchbar wird.

Ein äußeres Paket, das größer als die MTU der nächsten Verbindung ist, hat zwei mögliche Folgen.

Es wird fragmentiert. Ein Router teilt das Paket auf, und das entfernte Ende setzt die Teile wieder zusammen. Die Übertragung funktioniert, ist aber langsamer, weil nun zwei Pakete anstelle eines einzelnen übertragen werden und der Empfänger den Zustand vorhalten muss, bis beide Teile eingetroffen sind. Geht ein Fragment verloren, geht das gesamte ursprüngliche Paket verloren. Ein Übertragungsweg mit 1% Paketverlust verhält sich dadurch wie ein deutlich schlechterer Übertragungsweg. Viele Firewalls verwerfen IP-Fragmente außerdem entsprechend ihrer Richtlinien. Dadurch tritt der zweite Fall ein.

Es wird verworfen, und Sie erhalten möglicherweise keine Information darüber. Ein Router, der nicht fragmentieren darf, sendet eine ICMP-Nachricht (Internet Control Message Protocol) mit dem Inhalt "fragmentation needed" an den Absender zurück. Sie enthält die MTU, die der Router akzeptiert. Wenn diese Nachricht eintrifft, funktioniert die Path-MTU-Ermittlung, und der Absender verringert die Segmentgröße selbstständig. Viele Netzwerke filtern ICMP, sodass die Nachricht häufig nicht eintrifft. Nichts anderes meldet den Verlust. Das ist ein Blackhole: Das Paket verlässt den Absender, es kommt nichts zurück, an keinem Ende erscheint ein Fehler im Log, und die Übertragung bleibt hängen, bis ein Timeout eintritt.

Wie finde ich die richtige MTU?

Messen Sie den Pfad und führen Sie anschließend die Subtraktion durch. Testen Sie das Underlay, nicht den Tunnel. Pingen Sie daher vom Client aus die öffentliche Adresse des Servers und verbieten Sie Fragmentierung.

ping -M do -s 1472 -c 3 203.0.113.10

-M do setzt das DF-Bit (don't fragment), sodass kein Router auf dem Weg das Paket aufteilen darf. -s ist die Größe der ICMP-Nutzlast. Ein vollständiges IPv4-Paket besteht aus dieser Nutzlast sowie 8 Bytes ICMP-Header und 20 Bytes IP-Header. -s 1472 ergibt daher genau 1500 Bytes auf der Leitung.

Drei Ergebnisse sind relevant. Saubere Antworten bedeuten, dass 1500 Bytes passen und die MTU nicht die Ursache ist. Ein lokaler Fehler bedeutet, dass die eigene Schnittstelle bereits kleiner ist als der angeforderte Wert:

ping: local error: message too long, mtu=1500

Eine Antwort von einem Router auf dem Weg liefert die Antwort direkt. Sie können an dieser Stelle aufhören:

From 203.0.113.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)

100% Paketverlust bei 1472 und saubere Antworten bei einer kleineren Größe ist der Blackhole-Fall. Kein Router liefert eine Information. Ermitteln Sie die Grenze daher durch Halbieren. Halten Sie eine Größe fest, von der Sie wissen, dass sie funktioniert, und eine, von der Sie wissen, dass sie fehlschlägt. Testen Sie den Mittelwert und verschieben Sie je nach Ergebnis die entsprechende Grenze. Jeder Durchlauf halbiert den verbleibenden Bereich. Fünf oder sechs Durchläufe reichen daher aus.

ping -M do -s 1472 -c 3 203.0.113.10   # 100% loss, so 1500 is too big
ping -M do -s 1272 -c 3 203.0.113.10   # replies, so 1300 fits
ping -M do -s 1372 -c 3 203.0.113.10   # replies, so 1400 fits
ping -M do -s 1422 -c 3 203.0.113.10   # 100% loss, so 1450 is too big
ping -M do -s 1397 -c 3 203.0.113.10   # 100% loss, so 1425 is too big
ping -M do -s 1384 -c 3 203.0.113.10   # 100% loss, so 1412 is too big

tracepath führt dieselbe Suche selbstständig durch. Führen Sie den Befehl einmal aus, bevor Sie mit der Halbierung beginnen:

tracepath -n 203.0.113.10

Die letzte Zeile meldet das ermittelte Ergebnis:

     Resume: pmtu 1492 hops 12 back 12

Betrachten Sie beide Tools als Ausgangspunkt, nicht als Beweis. Einige Hosts begrenzen ICMP oder verwerfen ICMP vollständig. Eine Halbierung kann daher eine kleinere MTU melden, als der Pfad tatsächlich unterstützt. Der zuvor fehlschlagende Transfer ist der maßgebliche Test.

Wenden Sie den Wert zunächst live an. Bei einem falschen Wert können Sie die Änderung dann mit einem Befehl rückgängig machen:

sudo ip link set mtu 1320 dev wg0

Wiederholen Sie den Transfer, der hängen blieb. Wenn er abgeschlossen wird, machen Sie den Wert im [Interface]-Block des Clients dauerhaft:

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
MTU = 1320

sudo wg-quick down wg0 && sudo wg-quick up wg0
ip link show wg0

ip link show wg0 sollte nun mtu 1320 ausgeben. Wenn weiterhin der alte Wert ausgegeben wird, hat wg-quick nicht die von Ihnen bearbeitete Datei eingelesen. Prüfen Sie, ob Sie /etc/wireguard/wg0.conf bearbeitet haben und ob MTU unter [Interface] und nicht unter [Peer] steht. Unter [Peer] wird die Einstellung ignoriert.

Die MTU ist eine Eigenschaft einer einzelnen Schnittstelle. Sie wird niemals zwischen Peers ausgehandelt. Wenn Sie sie nur auf dem Client setzen, werden lediglich die vom Client gesendeten Pakete verkleinert. Der Server erstellt weiterhin Pakete mit seiner eigenen wg0-MTU. Downloads können daher weiterhin im Blackhole verschwinden, nachdem Uploads funktionieren. Setzen Sie den Wert an beiden Enden oder begrenzen Sie MSS auf dem Server.

Warum MSS-Clamping TCP behebt und sonst nichts

Wenn der Server Datenverkehr für seine Peers weiterleitet, wie es bei jedem standardmäßigen WireGuard-VPS-Setup mit NAT (network address translation) der Fall ist, behebt eine Regel das TCP-Problem für jeden Peer. Dadurch müssen Sie keinen Wert auf jedem Client suchen, den Sie nicht kontrollieren.

MSS (maximum segment size) ist eine TCP-Option, die jede Seite in ihr SYN-Paket einträgt. Damit gibt sie an, wie groß ein empfangsbereites Segment sein darf. Beim Clamping wird diese Option unterwegs an die tatsächliche Pfad-MTU angepasst. Dadurch einigen sich beide Enden vor der ersten Datenübertragung auf kleinere Segmente. Das funktioniert, weil die Anpassung während des Handshakes erfolgt. Sie ist außerdem nicht von einer ICMP-Nachricht abhängig, die der Pfad wahrscheinlich filtert.

Fügen Sie mit nftables diese Tabelle unterhalb Ihrer vorhandenen Tabellen zu /etc/nftables.conf hinzu:

table inet mangle {
  chain forward {
    type filter hook forward priority mangle; policy accept;
    tcp flags syn tcp option maxseg size set rt mtu
  }
}

Laden Sie die Konfiguration mit sudo systemctl reload nftables neu. Auf einem System mit iptables entspricht dies einer einzelnen Zeile:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Bestätigen Sie, dass die Regel auf dem Pfad liegt, den die Pakete nehmen. Führen Sie sudo nft list table inet mangle oder sudo iptables -t mangle -L FORWARD -n -v aus, während ein Client neue Verbindungen öffnet, und beobachten Sie, wie der Zähler steigt. Ein Zähler, der bei null bleibt, bedeutet, dass die Pakete diesen Hook nicht durchlaufen. Die Regel hat dann keine Wirkung.

Nun zu den tatsächlichen Einschränkungen. Clamping betrifft nur TCP und nur weitergeleiteten Datenverkehr. Ein Dienst, der direkt auf dem WireGuard-Server läuft, durchläuft den Forward-Hook daher nicht und wird nicht angepasst. Außerdem betrifft die Regel nur Verbindungen, die nach dem Laden der Regel geöffnet werden. Bestehende Sitzungen behalten die bereits ausgehandelte MSS.

UDP bleibt unverändert, weil UDP keinen Handshake hat, den die Regel anpassen könnte. Der meiste UDP-Datenverkehr funktioniert trotzdem. QUIC, das Transportprotokoll unter HTTP/3, ermittelt die nutzbare Paketgröße selbst und beginnt absichtlich mit kleinen Paketen. Nicht funktionieren dagegen UDP-Anfragen, die ein einzelnes großes Datagramm senden und dessen vollständige Übertragung erwarten, beispielsweise eine DNSSEC-Antwort (DNS security extensions) mit mehr als 1400 Bytes. Diese Abfragen laufen in einen Timeout und werden über TCP wiederholt. Für den Benutzer äußert sich das als langsame Website und nicht als vollständig ausgefallene Website.

Ist die CPU meines VPS das Limit?

WireGuard verschlüsselt mit ChaCha20-Poly1305 und tauscht Schlüssel mit Curve25519 aus. AES kommt im Datenpfad nicht zum Einsatz. Daraus folgt ein Punkt, der häufig falsch verstanden wird: Die AES-NI-Instruktionen Ihrer CPU bringen WireGuard keinen Vorteil. Ein Host mit AES-NI bietet Ihnen damit keine WireGuard-spezifische Leistungsfunktion. ChaCha20 wurde ausgewählt, weil es in reiner Software schnell ist, auch auf CPUs ohne jegliche kryptografische Beschleunigung.

Das bedeutet nicht, dass WireGuard kostenlos ist. Auf einem VPS mit 1 vCPU verarbeitet ein Kern sowohl die Verschlüsselung als auch die Netzwerk-Interrupts und muss zusätzlich die Aufgaben Ihrer Anwendung erledigen.

Messen Sie dies, während eine Übertragung läuft:

sudo apt install -y sysstat
mpstat -P ALL 1

Lesen Sie drei Spalten ab. %soft ist die Softirq-Zeit. Dort fällt die Paketverarbeitung des Kernels an. %steal ist die Zeit, in der der Hypervisor die CPU einem anderen Mandanten überlassen hat. %idle ist die verbleibende Zeit.

%soft nahe 100 auf Ihrem einzigen Kern bedeutet, dass das System seine Obergrenze bei der Paketverarbeitung erreicht hat. Das ist ein echtes Limit, das sich durch zusätzliche Kerne erhöhen lässt. top zeigt gleichzeitig ksoftirqd/0 an der Spitze der Prozessliste. Das ist dieselbe Feststellung aus einer anderen Perspektive.

%steal über einigen Prozent bedeutet, dass Sie dieses Limit nicht selbst beheben können. Der Host ist überbucht, und Ihre vCPU wartet auf einen physischen Kern. Das kommt bei den günstigsten Shared-Tarifen häufig vor und ändert sich im Tagesverlauf. Steal Time durch einen ausgelasteten Nachbarn erfordert eine eigene Untersuchung. Kein MTU-Wert wird dabei helfen.

Ein weiterer Faktor ist die Implementierung, die der Client verwendet. Das Linux-Kernelmodul ist der schnelle Pfad und verteilt die Verschlüsselung eines Peers auf mehrere Kerne. wireguard-go, die Userspace-Implementierung, ist langsamer. Sie wird von macOS- und iOS-Clients verwendet, weil diese Plattformen einer Anwendung das Laden eines Kernelmoduls nicht erlauben.

Ist es der Pfad oder die eigene Verbindung des Peers?

Bevor Sie etwas optimieren, ermitteln Sie auf demselben Client im Abstand von einigen Minuten zwei Werte: den Durchsatz ohne Tunnel und den Durchsatz mit Tunnel. Ohne dieses Wertepaar arbeiten Sie nur mit Vermutungen.

Führen Sie iperf3 -s auf dem Server aus. Für den direkten Test muss TCP 5201 über die öffentliche Adresse erreichbar sein. Öffnen Sie den Port daher für die Dauer des Tests und entfernen Sie die Regel anschließend wieder. Bestätigen Sie, dass der Port wieder geschlossen ist, statt dies anzunehmen.

# on the client, outside the tunnel
iperf3 -c 203.0.113.10
# then through the tunnel
iperf3 -c 10.8.0.1

Liegen die beiden Werte nahe beieinander, verursacht WireGuard nur sehr wenig Overhead und der Netzwerkpfad ist der begrenzende Faktor. Liegt der Tunnelwert deutlich unter dem direkten Wert, während %soft niedrig blieb, prüfen Sie erneut die MTU. Fragmentierung verringert den Durchsatz, ohne etwas vollständig ausfallen zu lassen. Sie erscheint daher hier als prozentualer Verlust und nicht als Hänger.

Testen Sie beide Richtungen, weil Heimanschlüsse normalerweise asymmetrisch sind. iperf3 -c 10.8.0.1 -R kehrt den Datenfluss um, sodass der Server sendet. Ein Client an einem Anschluss mit 500/20 kann niemals mehr als 20 Mbit Upload in den Tunnel übertragen. Keine Änderung auf dem Server kann das beeinflussen.

Testen Sie anschließend mit parallelen Datenströmen:

iperf3 -c 10.8.0.1 -P 4

Wenn vier Datenströme zusammen deutlich mehr übertragen als ein einzelner, kann eine einzelne TCP-Verbindung den Pfad nicht vollständig auslasten. Der Durchsatz eines einzelnen Datenstroms ist durch das Empfangsfenster geteilt durch die Round-Trip-Zeit begrenzt. Bei einem Pfad mit 150 ms ist daher ein großes Fenster erforderlich, um viele Daten zu übertragen. Prüfen Sie Ihre eigenen Grenzwerte:

sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

Der dritte Wert in jeder Ausgabe ist der maximale Wert, auf den Linux das Fenster automatisch anpassen kann. Paketverlust begrenzt einen einzelnen Datenstrom ebenfalls stark, weil die TCP congestion control auf Paketverlust reagiert und die Wiederherstellung bei einem langen Pfad viel Zeit benötigt. Führen Sie mtr -rwc 100 203.0.113.10 auf dem Client über hundert Zyklen aus, um festzustellen, an welcher Stelle entlang der Route Paketverlust auftritt. Beginnt der Verlust an einem Hop und setzt sich bis zum letzten Hop fort, ist er real. Tritt der Verlust nur an einem mittleren Hop auf und verschwindet danach wieder, behandelt dieser Router ICMP-Pakete mit niedrigerer Priorität. Das bedeutet nichts.

Für ein reproduzierbares Bild des Servers selbst, getrennt vom Netzwerk, benchmarken Sie den VPS mit einer dokumentierten Methode, damit Sie denselben Test nach einer Änderung erneut ausführen und die Ergebnisse direkt vergleichen können.

Was WireGuard nicht beheben kann

WireGuard ist ein Tunnel. Er kann nicht schneller sein als die langsamste Verbindung auf dem verwendeten Pfad. Außerdem macht er den Pfad immer geringfügig langsamer.

WireGuard komprimiert nicht. Es gibt kein Gegenstück zu comp-lzo von OpenVPN, und es ist auch keines geplant, weil die Komprimierung vor der Verschlüsselung Informationen über den Klartext preisgibt. Die meisten großen Datenmengen sind bereits komprimiert. In der Praxis entstehen Ihnen dadurch keine Nachteile. Dies ist einer der tatsächlichen Unterschiede, die Sie beim Vergleich von WireGuard und OpenVPN berücksichtigen sollten. Die Entscheidung ist bewusst Teil des Designs.

Ein Full Tunnel ändert die Route jedes Pakets. Datenverkehr, der zuvor von Ihnen zu einem nahe gelegenen CDN (Content Delivery Network) lief, läuft nun von Ihnen zu Ihrem VPS und anschließend zum CDN. Befindet sich der VPS auf einem anderen Kontinent, verursacht jede Anfrage diesen Umweg. Die Round-Trip-Zeit steigt entsprechend. Kein Konfigurationswert kann diese Zeit verkürzen. Verschieben Sie den VPS näher zu den Clients. Alternativ verwenden Sie einen Split Tunnel, sodass nur der für das VPN bestimmte Datenverkehr den längeren Weg nimmt. Welcher Datenverkehr wohin geleitet wird, wird vollständig durch AllowedIPs bestimmt. Cryptokey-Routing erklärt, wie diese Entscheidung getroffen wird.

Provider-Limits liegen außerhalb des Tunnels und werden leicht übersehen. Ein Tarif mit einem monatlichen Bandbreitenlimit begrenzt die Geschwindigkeit des Ports häufig stark, sobald das Limit erreicht ist. Der Tunnel wirkt dann fehlerhaft. Prüfen Sie Ihr Provider-Panel, bevor Sie einen Abend lang die MTU untersuchen.

PersistentKeepalive beeinflusst den Durchsatz nicht. Der Wert hält ein NAT-Mapping offen, damit der Server weiterhin einen Client hinter einem Heimrouter erreichen kann. Ein Wert unter 25 Sekunden erzeugt zusätzlichen Datenverkehr und behebt nichts.

In dieser Reihenfolge messen

1. Reproduzieren Sie das Problem und prüfen Sie, ob es sich um einen Hänger oder eine gleichmäßige Verlangsamung handelt. Ein Hänger deutet auf die MTU hin. Eine gleichmäßige Verlangsamung nicht.
2. Führen Sie mit ping -M do vom Client zur öffentlichen Adresse des Servers eine Bisektion durch und notieren Sie die Pfad-MTU.
3. Ziehen Sie 80 ab, setzen Sie diese MTU auf beiden Seiten auf wg0 und testen Sie die Übertragung, bei der der Fehler auftrat, erneut.
4. Aktivieren Sie MSS-Clamping auf dem Server, wenn dieser Datenverkehr für Peers weiterleitet.
5. Führen Sie während einer Übertragung mpstat -P ALL 1 aus und lesen Sie %soft und %steal ab.
6. Führen Sie iperf3 außerhalb und innerhalb des Tunnels in beide Richtungen aus, jeweils mit einem einzelnen Datenstrom und mit -P 4.
7. Führen Sie mtr -rwc 100 zum Server aus und achten Sie auf Paketverlust, der bis zum letzten Hop bestehen bleibt.

Ändern Sie den Server-Tarif erst, wenn Schritt 5 zeigt, dass die CPU die Begrenzung darstellt. Die Schritte 1 bis 4 kosten nichts und lösen die meisten Meldungen über einen langsamen Tunnel.

FAQ

Warum ist mein WireGuard-Tunnel bei Pings schnell, bei Downloads aber langsam?

Diese Aufteilung ist typisch für ein MTU-Problem. Kleine Pakete passen unter jede Verbindung auf dem Pfad, daher funktionieren ping und eine SSH-Anmeldung. Bei einer umfangreichen Übertragung sind die Segmente vollständig ausgelastet. Ihre gekapselte Variante ist größer, als manche Verbindung akzeptiert. Verwirft der Router diese Pakete, ohne eine ICMP-Nachricht zurückzusenden, meldet nichts den Verlust und die Übertragung bleibt hängen. Ermitteln Sie die Pfad-MTU mit einer ping -M do-Bisektion zur öffentlichen Adresse des Servers. Ziehen Sie 80 Bytes für die Kapselung ab und setzen Sie das Ergebnis an beiden Enden als MTU von wg0.

Welche MTU sollte ich für WireGuard festlegen?

Es gibt keinen universellen Wert. Genau deshalb funktioniert der Standardwert 1420 bei manchen Benutzern nicht. 1420 entspricht 1500 minus 80 Bytes für WireGuard-Header, UDP-Header und den äußeren IPv6-Header. Wenn Ihr Pfad weniger als 1500 Bytes überträgt, was bei PPPoE-DSL und bei Verkehr durch einen weiteren Tunnel üblich ist, benötigen Sie einen kleineren Wert. Messen Sie zuerst die Pfad-MTU und ziehen Sie anschließend 80 davon ab.

Ersetzt MSS-Clamping das Festlegen der MTU?

Nein. Clamping schreibt die MSS-Option im TCP-Handshake um, sodass beide Enden kleinere Segmente senden. Dadurch wird TCP korrigiert, ohne das Interface zu ändern. UDP hat keinen umschreibbaren Handshake und bleibt daher unverändert. Clamping gilt außerdem nur für Verkehr, den der Server weiterleitet. Ein Dienst, der direkt auf dem WireGuard-Server läuft, profitiert davon nicht. Verwenden Sie beides: eine korrekte MTU am Interface und Clamping für Peers, deren Konfiguration Sie nicht kontrollieren.

Macht ein schnellerer VPS-Tarif WireGuard schneller?

Nur wenn die CPU der begrenzende Faktor ist. Ein Befehl zeigt Ihnen, ob das der Fall ist. Führen Sie mpstat -P ALL 1 aus, während eine Übertragung läuft. %soft nahe 100 auf Ihrem einzigen Kern bedeutet, dass die Paketverarbeitung die Grenze bildet. Mehr Kerne erhöhen dann den Durchsatz. Ein hoher %steal bedeutet, dass der Host überbelegt ist. In diesem Fall benötigen Sie einen anderen Tarif oder einen anderen Host. Sind beide Werte niedrig, während der Tunnel weiterhin langsam ist, ist die CPU nicht ausgelastet. Ein größerer Tarif ändert dann nichts.

Warum ist mein Mac im selben Netzwerk langsamer als mein Linux-Client?

Der Linux-Client verwendet das WireGuard-Modul im Kernel. Es verarbeitet Pakete im Kernel-Space und verteilt die Verschlüsselung eines Peers auf mehrere CPU-Kerne. Die macOS- und iOS-Apps verwenden wireguard-go, eine Implementierung im Userspace, weil diese Plattformen das Laden eines Kernel-Moduls durch eine Anwendung nicht erlauben. Im Userspace wird jedes Paket zwischen Kernel und Anwendung kopiert. Diese Kopiervorgänge verringern den Durchsatz. Der Unterschied ist erwartbar. Keine Client-Einstellung kann ihn beseitigen.