Beiträge von MCKraemer

Zitat von frank_m

iperf3 Tests hast du zu deinem Server ja schon gemacht. Auf Client Seite kannst du durch ein einfaches "-u" UDP Tests durchführen. Bedenke, dass du dabei eine Geschwindigkeit mit angeben musst, sonst findet der Test nur mit 1 MBit/s statt. Ich würde mit 100 MBit/s anfangen und mich dann nach oben unten vortasten, bis die Paketfehlerrate in der Schlussstatistik bei maximal 2% ist. Das ist dann die etwa zu erwartende UDP Datenrate zwischen deinen Systemen.

iperf3 -c <server> -u -b 100M

Connecting to host 10.8.0.1, port 5201
[  5] local 10.8.0.2 port 42779 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  35.8 MBytes   300 Mbits/sec  27199
[  5]   1.00-2.00   sec  35.8 MBytes   300 Mbits/sec  27174
[  5]   2.00-3.00   sec  35.8 MBytes   300 Mbits/sec  27174
[  5]   3.00-4.00   sec  35.8 MBytes   300 Mbits/sec  27173
[  5]   4.00-5.00   sec  35.8 MBytes   300 Mbits/sec  27175
[  5]   5.00-6.00   sec  35.8 MBytes   300 Mbits/sec  27173
[  5]   6.00-7.00   sec  35.8 MBytes   300 Mbits/sec  27174
[  5]   7.00-8.00   sec  35.8 MBytes   300 Mbits/sec  27173
[  5]   8.00-9.00   sec  35.8 MBytes   300 Mbits/sec  27175
[  5]   9.00-10.00  sec  35.8 MBytes   300 Mbits/sec  27174
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   358 MBytes   300 Mbits/sec  0.000 ms  0/271764 (0%)  sender
[  5]   0.00-10.02  sec   219 MBytes   183 Mbits/sec  0.079 ms  0/271763 (0%)  receiver

Das sieht für mich überraschend gut aus, wie kann denn TCP so schlecht performen über den Tunnel während UDP keinerlei Probleme macht.

Zitat von TBT

Unabhängig von den Paketverlustproblemen zum Setup: genau beim geschilderten Problem (bevor mans selbst strickt) kann Pangolin helfen. Pangolin wird auf dem Internet Server installiert, die zugehörige Plug-and-Play Komponente Newt kommt auf den CGNAT Server. Supersimpel und schnell einzurichten, zudem kann Pangolin Zugangsrechte verwalten und auch an andere ID Provider angeschlossen werden. SSO kanns auch.

Kurz zu meinem Verständnis, Pangolin nutzt doch Wireguard unter der Haube, inwiefern soll es hier also einen Unterschied geben?

Zitat von 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.

Zitat von 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.

Zitat von Hille

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

Ja ist gesetzt.

Zitat von 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?

Zitat von 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.

Zitat von 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.

Zitat von 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.

Zitat von frank_m

Warum nicht per IPv6?

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

Zitat von frank_m

Warum das? Warum keine direkte Portfreigabe?

Wollte etwas sprechendes für meine Eltern.

Zitat von 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.

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.

Zitat von frank_m

Das würde tatsächlich vieles einfacher machen. Ich bin mir noch nicht ganz sicher, ob die letzte iptables-Regel für die Antwort-Pakete ausreicht, aber das werden wir sehen. Setz das mal so auf und nimm deine 4 Regeln her und etabliere sie auf dem Host. Ich glaube, dann bist du schon sehr weit hin.

Wireguard ist jetzt direkt auf dem Hostsystem, ping gegen Unraid klappt und auch ein curl auf die entsprechende interne wiregaurd IP + Port sieht gut aus.
Hab noch einen Eintrag für die iptables ergänzt und das ganze funktioniert. Perfekt, vielen lieben Dank!

Da hätte ich mir noch Tage mit Podman den Schädel eingeschlagen.

Hi,

erstmal danke für den Versuch mir zu helfen. Ich versuche deine Fragen mal zu beantworten.

Zitat von frank_m

Was heißt in dem Zusammenhang "auf der Netcup Seite"? Ich nehme an, in einer Bash Shell auf dem VPS. Aber im Container? Im Host-System? Wie sieht die Adress-Verteilung auf dem VPS aus? Kommt man vom Host direkt an das VPN Interface und das Transport-Netz, um die andere Seite zu erreichen?

Ich hab aus der Shell des Wireguard Containers gepingt. Nein vom Host selbst kommst du nicht daran, das muss alles über iptables im Container gesteuert werden. Müsste dann einen anderen Port des Containers anpingen und den Aufruf entsprechend forwarden im Container z.B. an Unraid.

Zitat von frank_m

Ich seh in deiner Frage keine IP-Tables Regeln ... Das wäre wichtig, weil du dir ja Gedanken über die Ziele dieser Regeln gemacht hast. Das hängt mit der ersten Frage zusammen.

iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 52500 -m conntrack --ctstate NEW -j ACCEPT;

iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT;

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 52500 -j DNAT --to-destination 10.8.0.3;

iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 52500 -d 10.8.0.3 -j SNAT --to-source 10.8.0.1;

Zitat von frank_m

Welche genau? Input? Forwarding?

Den Port für Wireguard selbst sowie die weiteren Ports die ich nutzen wollte. Forwarding müsste hier doch nicht erlaubt werden, da es innerhalb des Containers stattfindet oder?

Zitat von frank_m

Warum das? Der Server läuft ja nicht im Container.

Gewisse Container wollte ich direkt via IP + Port des Servers zur Verfügung stellen, ohne davor einen Reverse Proxy zu nutzen. Hab daher den Container mit Wireguard direkt an diese Ports gebunden.

Zitat von frank_m

Ums ehrlich zu sagen, ich sehe einige Buzzwörter in diesem Beitrag, die mir nicht gefallen. ufw, Podman, Docker, .... Für so ein einfaches Setup unglaublich viel Overhead, der nicht sein müsste. Vielleicht laufen andere Dinge auf dem Server, die eine Kapselung sinnvoll machen. Aber Docker z.B. bringt dir alle Firewall-Regeln durcheinander und harmoniert mit ufw so überhaupt nicht. Einfach ein blankes Linux, Wiregaurd drauf und 2 iptables Regeln, und du wärst glücklich.

Okay, danke für das Feedback. Ich hatte mir schon gedacht, dass das vielleicht ein bisschen Overkill sein könnte. Dann schmeiß ich den Container mal raus und installier Wireguard direkt auf dem System.

Hallo zusammen,

ich betreibe einen Root-Server mit Debian 12. Weiter betreibe ich in den eigenen vier Wänden ein NAS mit Unraid. Auf dem NAS laufen mehrere Anwendungen die ich bisher durch einen Cloudflare Tunnel zur Verfügung stelle, da ich hinter einem CGNAT bin.

Ich hab mir in den letzten Tagen überlegt, dass ich das zukünftig gerne ändern würde und hierfür anstatt Cloudflare mein Netcup Server nutzen möchte. Ich habe daher wg-easy als Container via Podman auf Debian zum laufen gebracht. Weiter habe ich Unraid dazu bekommen sich auch erfolgreich mit dem wireguard Server zu verbinden, auf der Netcup-Seite kann ich unraid erfolgreich über die wireguard interne IP pingen.

Allerdings scheitere ich seit Tagend daran das forwarding mithilfe der iptable hinzubekommen, vlt hab ich aber auch etwas viel banaleres vergessen. ufw wurde an den entsprechenden stellen geöffnet und auch der Container mit den entsprechenden Ports gemappt.

Hier einmal die yaml:

version: "3.8"
services:
wg-easy:
network_mode: caddy
environment:
- WG_HOST=meineServerIP
- PASSWORD_HASH=meinPasswort
- UI_TRAFFIC_STATS=true
- UI_CHART_TYPE=1
image: ghcr.io/wg-easy/wg-easy
container_name: wg-easy
volumes:
- $HOME/docker/volumes/wg:/etc/wireguard
ports:
- "51820:51820/udp"
- "51850:51850/tcp"
restart: unless-stopped
cap_add:
- NET_ADMIN
- NET_RAW
- SYS_MODULE
sysctls:
- net.ipv4.ip_forward=1
- net.ipv4.conf.all.src_valid_mark=1

Ich hätte gerne das der Port 51850 bei meinem NAS landen würde. Hat hier jemand eine Idee, danke für jede Form der Hilfe.

Viele Grüße

Vielen Dank euch allen für die Hilfe!

Es hat wirklich an der Konvertierung in RAW gelegen. Nachdem ich mir diesen Umweg gespart habe hat alles ohne Probleme funktioniert.

In dem oben verlinkten Thread wurde geschrieben ich muss von qcow2 in raw konvertieren um mit qemo-img einen resize machen zu können.

Partitionierung etc. komplett futsch, fragt sich nur bei welchem Schritt. Ich fange nochmal von vorne an.

Nicht ganz, ich lande in der Dracut Emergency Shell

pasted-from-clipboard.png

Dann zählt er bis in die Unendlichkeit hoch...

Den vermutlich wichtigen Teil vergessen, sorry...

pasted-from-clipboard.png

pasted-from-clipboard.png

Hallo zusammen,

leider habe ich anscheinend etwas falsch gemacht. Ich habe unter Ubuntu den Snapshot mit Gparted geöffnet und die Partition auf eine Größe von ~100GB verkleinert. Dann alles in RAW konvertiert einen resize gemacht und damit die Größe auf 120GB geändert.

Hochgeladen und auf dem Server installiert mit folgendem Ergebnis:

pasted-from-clipboard.png

pasted-from-clipboard.png

pasted-from-clipboard.png