Wireguard Durchsatz instabil

Hallo zusammen,

ich bin mit meinem Latein am Ende und hoffe jemand von euch kann mir helfen.

Ich habe bei mir Zuhause ein NAS wo ich z.B. immich als Google Fotos alternative hoste. Da ich hinter einem CGNAT hänge kann ich es leider nicht einfach so freigeben/nutzen, da mir eine eindeutige öffentliche IPv4 fehlt. Meine Idee war daher ich erstelle auf meinem Root Server einen Wireguard Server und lasse das NAS zu diesem connecten.

Auf Seite des Root Servers läuft caddy und dient als reverse proxy der entsprechenden Wireguard IP+Port. Das ganze funktioniert auch soweit und meine Dienste sind erreichbar, jetzt kommt allerdings mein Problem. Der Durchsatz ist für 1-2 Sekunden entsprechend meines Uploads, danach kollabiert er und pendelt dann immer hin und her. An der MTU hab ich schon rumgeschraubt, kommt aber zum identischen Problem. Ich konnte das Problem bereits auf den Wireguard Tunnel beschränken, IPerf zeigt hier das identische verhalten sowie Paketverlust. Hat jemand eine Idee?

Danke für jede Form der Hilfe.

Quote from frank_m

Warum nicht per IPv6?

Je nach öffentlichem Netz etc. konnte ich über mein Handy das System via IPv6 nicht erreichen.

Quote from frank_m

Warum das? Warum keine direkte Portfreigabe?

Wollte etwas sprechendes für meine Eltern.

Quote from frank_m

Paketverluste wären eine sehr zuverlässige Erklärung für dein Problem. Hast du iperf mit UDP oder mit TCP getestet? Was für einen Internetanschluss hast du und gibt es UDP Paketverluste auch zu anderen Zielen? Es gibt ja einige öffentliche iperf Server im Netz, gegen die man testen kann.

Ich habe via TCP getestet. Ich hab einen Glasfaseranschluss mit 200Mbit Upload. Danke für den Tipp, ich hab mal gegen einen öffentlichen gestestet, auch hier retries aber die volle Bandbreite geht durch.

Quote from Hille

Bedenke, dass WireGuard, abhängig vom Durchsatz, ordentlich CPU Power benötigt.was haste für eine NAS bzw. Root Server ?

Ich hab einen RS 1000 G11, die CPU schlägt aber nicht besonders aus, soweit ich korrekt geguckt habe. Das NAS nutzt einen i5-12600K.

Quote from Hille

Das müsste bei 200Mbit ausreichend sein. Was haste für eine MTU auf beiden Geräten eingestellt für IPV4 ?

Aktuell steht es auf 1400, ich habe aber auch schon 1250, 1300, 1350 getestet mit gleichem Resultat.

Quote from Hille

Ich vermute mal, dass du einen dsl Anschluss hat. Rein rechnerisch wären es 1432 (IPv4). kannst es ja mal auf beiden Geräten testen

Glasfaser um genau zu sein, Deutsche Glasfaser ist mein Provider. Teste ich sofort, danke dir.

EDIT: Pendelt auch mit derm MTU leider weiter.

Quote from finnvweiss

Ich hatte mal ein ganz ähnliches Problem mit schwankendem Durchsatz über Wireguard. Bei mir war’s am Ende die MTU. Ich hab mit ping -M do -s rumgetestet, bis ich die größte Paketgröße ohne Fragmentierung gefunden hab, und dann die MTU in der Wireguard-Config entsprechend angepasst auf beiden Seiten. Seitdem läuft’s stabil.

Falls du das schon probiert hast, check mal auch die Congestion Control auf dem Server. bbr hat bei mir nochmal einen Schub gebracht im Vergleich zu cubic.

Bei mir stehen reno und cubic zur Verfügung, gibts davon eine die zu bevorzugen ist?

Quote from Hille

Haste geschaut, ob der MTU auch wirklich am wg0 eingestellt wurde ?

Ja ist gesetzt.

Quote from Homwer

Wie misst du deinen Durchsatz?

Iperf3 ?

Klingt ehr so als wäre der Cache vom NAS voll bei drehenden Platten.

Ja mit Iperf3, die Idee kann ich aber verneinen, weil es bei direkter Verbindung zum NAS nicht einbricht.

Quote from frank_m

Da Wireguard mit UDP und nicht mit TCP arbeitet, werden die Congestion Control Algorithmen gar nichts ändern.

Du musst mit UDP testen, ob es Paketverluste gibt, ob sie von der Paketgröße oder der Paketfrequenz abhängen, usw. Alles andere bringt dich nicht weiter. Immer dran denken: UDP. Nicht TCP. Die klassischen Tipps für Internetzugänge oder langsame Downloads gehen am Ziel vorbei.

Verstehe, darüber hatte ich nicht nachgedacht. Kannst du mir hier eine Vorgehensweise empfehlen, damit hatte ich bisher wenig Berührung.