8
WireGuard: Geschwindigkeit bei Verwendung von Raspberry Pi 4 extrem stark schwankend
Hallo in die Runde,
folgende Ausgangslage:
Ein vServer, der als WireGuard-Zentrale fungiert. Daran hängen mehrere Clients, von denen manche ihre Verbindung direkt durch die FritzBox aufbauen, manche durch einen Raspberry Pi 4, da der Router kein WireGuard kann.
Nun haben ich z. B. beim Traffic von FritzBox -> vServer -> FritzBox hohe Datenraten von teilweise über 100 Mbit/s. Alles gut.
Aber die Raspberry Pis machen mir Sorgen. Bei denen ist die Geschwindigkeit extrem schwankend, vor allem beim ausgehenden Traffic, also der in Richtung vServer. Teilweise geht die Geschwindigkeit auf unter 1 Mbit/s runter und ist kaum noch brauchbar. In die andere Richtung ist es besser, aber auch bei weitem nicht das, was man erwarten könnte. Manchmal ist es auch so, dass es sehr schnell losgeht und nach einigen Sekunden bricht es extrem ein. Ob FTP oder iPerf oder etwas anderes spielt keine Rolle, das hat sich bisher immer gleich verhalten.
Nun habe ich schon mit der MTU herumgespielt, da die ja wohl möglicherweise eine Rolle spielt. Zuerst dachte ich, ich hätte mit 1430 einen optimalen Wert gefunden, aber kurz danach war trotz der Änderung alles wieder wie vorher. Hat jemand eine Idee, wo ich noch ansetzen könnte? Ich hatte zuvor eine OpenVPN-Verbindung (per TCP, WireGuard ist ja UDP) auf den Raspis laufen und diese war kein Problem in Sachen Geschwindigkeit. Gibt es noch irgendetwas, was ich evtl. an den Systemeinstellungen der Raspis angepasst werden sollte?
Die Konfiguration ganz grob...
(MTU habe ich wieder rausgenommen, nachdem das ja nichts gebracht hat.)
vServer:
Die andern Peers sehen genau so aus.
alle Clients sehen so aus:
folgende Ausgangslage:
Ein vServer, der als WireGuard-Zentrale fungiert. Daran hängen mehrere Clients, von denen manche ihre Verbindung direkt durch die FritzBox aufbauen, manche durch einen Raspberry Pi 4, da der Router kein WireGuard kann.
Nun haben ich z. B. beim Traffic von FritzBox -> vServer -> FritzBox hohe Datenraten von teilweise über 100 Mbit/s. Alles gut.
Aber die Raspberry Pis machen mir Sorgen. Bei denen ist die Geschwindigkeit extrem schwankend, vor allem beim ausgehenden Traffic, also der in Richtung vServer. Teilweise geht die Geschwindigkeit auf unter 1 Mbit/s runter und ist kaum noch brauchbar. In die andere Richtung ist es besser, aber auch bei weitem nicht das, was man erwarten könnte. Manchmal ist es auch so, dass es sehr schnell losgeht und nach einigen Sekunden bricht es extrem ein. Ob FTP oder iPerf oder etwas anderes spielt keine Rolle, das hat sich bisher immer gleich verhalten.
Nun habe ich schon mit der MTU herumgespielt, da die ja wohl möglicherweise eine Rolle spielt. Zuerst dachte ich, ich hätte mit 1430 einen optimalen Wert gefunden, aber kurz danach war trotz der Änderung alles wieder wie vorher. Hat jemand eine Idee, wo ich noch ansetzen könnte? Ich hatte zuvor eine OpenVPN-Verbindung (per TCP, WireGuard ist ja UDP) auf den Raspis laufen und diese war kein Problem in Sachen Geschwindigkeit. Gibt es noch irgendetwas, was ich evtl. an den Systemeinstellungen der Raspis angepasst werden sollte?
Die Konfiguration ganz grob...
(MTU habe ich wieder rausgenommen, nachdem das ja nichts gebracht hat.)
vServer:
[Interface]
Address = 10.252.1.0/24
ListenPort = 51820
PrivateKey = xxx
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.252.1.0/24 -o ens6 -j MASQUERADE
PreDown =
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.252.1.0/24 -o ens6 -j MASQUERADE
Table = auto
[Peer]
PublicKey = xxx
PresharedKey = xxx
AllowedIPs = 10.252.1.1/32,192.168.3.0/24
PersistentKeepalive = 15Die andern Peers sehen genau so aus.
alle Clients sehen so aus:
[Interface]
PrivateKey = xxx
DNS = 8.8.8.8,8.8.4.4
[Peer]
PublicKey = xxx
PresharedKey = xxx
AllowedIPs = 10.252.1.0/24,192.168.3.0/24
Endpoint = vServerIP:51820
PersistentKeepalive = 15
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671383
Url: https://administrator.de/forum/wireguard-geschwindigkeit-bei-verwendung-von-raspberry-pi-4-extrem-stark-schwankend-671383.html
Ausgedruckt am: 19.02.2025 um 04:02 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Hast Du schon Mal geprüft, ob die Geschwindigkei stabil ist, wenn Du die Verbindung ohne VPN aufbaust?
lks
Hast Du schon Mal geprüft, ob die Geschwindigkei stabil ist, wenn Du die Verbindung ohne VPN aufbaust?
lks
Zuvor lief genau auf dieser Strecke eine OpenVPN-Verbindung (Raspi -> Raspi, ohne vServer). Die lieferte die höchstmögliche Geschwindigkeit des Anschlusses.
Wie immer die gleiche Leier: Unnötiges, falsches und Performance fressendes NAT/Masquerading im Tunnel. 
Da muss man sich dann über "Schwankungen" nicht groß wundern. Wundern muss man sich als Admin nur darüber warum das immer und immer wieder falsch konfiguriert wird?! 🙄
Firewall Settings haben in der VPN Definition nichts zu suchen! Einmal ganz davon abgesehen das der RasPi bez. Debian insgesamt keine antiken iptables mehr supportet sondern allein nur noch die neuen nftables. Wenn Firewall Regeln dann immer nur in der /etc/nftables.conf!!
Lesen und verstehen und die Konfig entspr. korrigieren:
Merkzettel: VPN Installation mit Wireguard
Zweiter Fehler ist der überflüssige Preshared Key wenn man so oder so schon mit Keys arbeitet. Steht auch in der offiziellen WG Doku. Aber einige brauchen halt zum Gürtel scheinbar auch noch den Hosenträger...
Dritter Fehler: Keepalives auf dem VPN Responder (Server) sind unsinnig. Netztechnisch macht es nur Sinn das der Initiator (Client) die Keepalives aufrecht erhält. Nebenbei ist 15 ein viel zu hohes Intervall. UDP Session Timeouts liegen in Router oder Firewalls zw. 45 und 60 Sek. Mit "35" macht man also nix falsch. Überflüssige Keepalives kosten auch Performance. Umso mehr wenn sie unnötigerweise noch vom Responder kommen.
Vierter Fehler: Falsche Subnetzmaske und damit falsche Krypto Key Routing in der Client Konfig für die Server IP in der AllowedIP Definition! Warum es am Peer in der Server Konfig richtig ist, hier aber falsch weiss wohl auch nur der TO?!
Da muss man sich dann über "Schwankungen" nicht groß wundern. Wundern muss man sich als Admin nur darüber warum das immer und immer wieder falsch konfiguriert wird?! 🙄
Firewall Settings haben in der VPN Definition nichts zu suchen! Einmal ganz davon abgesehen das der RasPi bez. Debian insgesamt keine antiken iptables mehr supportet sondern allein nur noch die neuen nftables. Wenn Firewall Regeln dann immer nur in der /etc/nftables.conf!!
Lesen und verstehen und die Konfig entspr. korrigieren:
Merkzettel: VPN Installation mit Wireguard
Zweiter Fehler ist der überflüssige Preshared Key wenn man so oder so schon mit Keys arbeitet. Steht auch in der offiziellen WG Doku. Aber einige brauchen halt zum Gürtel scheinbar auch noch den Hosenträger...
Dritter Fehler: Keepalives auf dem VPN Responder (Server) sind unsinnig. Netztechnisch macht es nur Sinn das der Initiator (Client) die Keepalives aufrecht erhält. Nebenbei ist 15 ein viel zu hohes Intervall. UDP Session Timeouts liegen in Router oder Firewalls zw. 45 und 60 Sek. Mit "35" macht man also nix falsch. Überflüssige Keepalives kosten auch Performance. Umso mehr wenn sie unnötigerweise noch vom Responder kommen.
Vierter Fehler: Falsche Subnetzmaske und damit falsche Krypto Key Routing in der Client Konfig für die Server IP in der AllowedIP Definition! Warum es am Peer in der Server Konfig richtig ist, hier aber falsch weiss wohl auch nur der TO?!
Danke. Nur leider ändert das alles nichts. NAT/Maquerading raus (welches nur dafür da ist, damit Clients auch das Internet des vServer bekommen können), Preshared Keys raus, Subnetzmaske geändert. Macht alles keinen Unterschied.
Ich vermute irgendwie, dass das am Router oder auch am Raspberry Pi des Peers liegt. Nur wüsste ich nicht, wo ich ansetzen sollte.
Ich vermute irgendwie, dass das am Router oder auch am Raspberry Pi des Peers liegt. Nur wüsste ich nicht, wo ich ansetzen sollte.
Zitat von @DigiAndi:
Zuvor lief genau auf dieser Strecke eine OpenVPN-Verbindung (Raspi -> Raspi, ohne vServer). Die lieferte die höchstmögliche Geschwindigkeit des Anschlusses.
Zuvor lief genau auf dieser Strecke eine OpenVPN-Verbindung (Raspi -> Raspi, ohne vServer). Die lieferte die höchstmögliche Geschwindigkeit des Anschlusses.
Das ist aber eine ganz andere Strecke aus über den vServer als erstes wurde ich Mal die Strecken direk ausmessen. Über die auch sder Tunnel geroutet wird. Abgesehen davon ist ein vServer auch Schwankungen unterworfen, je nachdem, wie viel Ressourcen er gerade abbekommt. Da wäre ein Root-Server als VPN-Hub eher angebracht.
lks
Natürlich ist das eine andere Strecke. Aber die letzte Meile ist diesselbe und da ist deutlich mehr drin als das, was derzeit WireGuard liefert.
Das Problem besteht jedenfalls schon auf dem Weg zum vServer. Das kann ich per iPerf sehen. Dass es überall Schwankungen gibt, ist vollkommen klar und ich erwarte ja keine konstanten 100 Mbit/s. Aber es sind die meiste Zeit nicht mehr als 2 Mbit/s drin - und das kann ja nicht sein.
Der vServer selbst ist auch nicht das Problem. Ich schrieb ja eingangs, dass eine bzw. die mehrern FritzBoxen als Peer volle Geschwindigkeit liefern.
Das Problem besteht jedenfalls schon auf dem Weg zum vServer. Das kann ich per iPerf sehen. Dass es überall Schwankungen gibt, ist vollkommen klar und ich erwarte ja keine konstanten 100 Mbit/s. Aber es sind die meiste Zeit nicht mehr als 2 Mbit/s drin - und das kann ja nicht sein.
Der vServer selbst ist auch nicht das Problem. Ich schrieb ja eingangs, dass eine bzw. die mehrern FritzBoxen als Peer volle Geschwindigkeit liefern.
Zitat von @DigiAndi:
Natürlich ist das eine andere Strecke. Aber die letzte Meile ist diesselbe und da ist deutlich mehr drin als das, was derzeit WireGuard liefert.
Natürlich ist das eine andere Strecke. Aber die letzte Meile ist diesselbe und da ist deutlich mehr drin als das, was derzeit WireGuard liefert.
Ja, aber das heißt doch. daß die Strecke zum vSrrver das Problem zu sein Schein, egal was auf der letzten Meile los ist.
Das Problem besteht jedenfalls schon auf dem Weg zum vServer. Das kann ich per iPerf sehen.
Hast im Tunnel oder auserhalb der Tunnels gemessen? Wenn es außerhalb des Tunnels diese Schwankungen gibt, ist das vermutlich sußerhalb Deines Einflußbereiches und der Pi unschuldig.
Wenn es Diskrepanzen im und außerhalb des Tunnels gibt, muß man da Mal nachforschen durch passende Wiresharkmitschnitte.
Dass es überall Schwankungen gibt, ist vollkommen klar und ich erwarte ja keine konstanten 100 Mbit/s. Aber es sind die meiste Zeit nicht mehr als 2 Mbit/s drin - und das kann ja nicht sein.
Bei falscher Konfiguration oder Einschränkungen auf der Route oder Probleme beim peering kann das durchaus sein.
lks
Ich vermute irgendwie, dass das am Router oder auch am Raspberry Pi des Peers liegt.
Ggf. mit htop mal checken wer viele Resourcen zieht. Auch wenn der iPerf3 Test über den Tunnel rennt.Rennen noch andere Prozesse auf dem RasPi?
Das Problem besteht jedenfalls schon auf dem Weg zum vServer.
Im Zweifel hier auf dem vServer einmal parallel ein IKEv2 VPN Server einrichten und mit den bordeigenen und damit hardwarenahen und besser integrierten VPN Clients testen!IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
