151002
Nov 07, 2024, updated at 18:10:42 (UTC)
2066
13
1
WireGuard: Instabile Verbindung zwischen Gateway und Client (über Server)
Hallo zusammen,
ich hoffe, hier auf jemanden zu treffen, der mir bei einem merkwürdigen Problem mit meiner WireGuard-Konfiguration weiterhelfen kann. Vielleicht hat jemand ähnliche Erfahrungen gemacht.
Ausgangssituation:
Server: Externer VPS mit 2.5 Gbit Anbindung
Client: 1 Gbit Down / 100 Mbit Up
Gateway im Heimnetzwerk: Linux-Server mit 1 Gbit Down / 100 Mbit Up
Verbindungen im Detail:
Client ↔ Server: Die Verbindung ist stabil und erreicht die maximale Geschwindigkeit, kein Problem hier.
Gateway ↔ Server: Ebenfalls stabil und schnell.
Problemfall: Gateway ↔ Client über den Server
Hier kommt es zu deutlichen Problemen: Die Verbindung ist extrem schwankend, meist nur 5–50 Mbit und alles andere als stabil. Bei iperf3-Tests zwischen Client und Gateway beobachte ich, dass die Übertragungsrate ständig hoch und runter geht. Oft sind es nur 20 Mbit oder weniger, manchmal steigen sie kurzzeitig auf 50-80 Mbit.
Was ich bereits versucht habe:
MTU-Optimierung: Die besten Ergebnisse konnte ich bisher mit einer MTU von 1280 erzielen. Jedoch ist das Problem damit nicht behoben.
Verschiedene Clients: Getestet habe ich unter Windows, Linux, Android und iOS – das Verhalten ist auf allen Plattformen gleich.
CPU-Auslastung geprüft: Auf allen beteiligten Systemen ist die CPU-Auslastung minimal und dürfte nicht der Grund für die Limitierungen sein.
Mein Ziel:
Ich möchte eine stabile, schnelle Verbindung vom Heimnetzwerk zu meinen Clients erreichen, sodass die Clients dabei auch die Internetverbindung des Heimnetzwerks nutzen können. Grundsätzlich erfüllt die aktuelle Konfiguration dieses Ziel, allerdings ist die Verbindung viel zu instabil, um darüber zu arbeiten.
Habt ihr eine Idee, was hier der Grund sein könnte oder Tipps, wie ich die Verbindung optimieren kann?
Danke vorab für jede Hilfe!
WG-Konfig Server:
WG-Konfig Gateway:
WG-Konfig Client:
ich hoffe, hier auf jemanden zu treffen, der mir bei einem merkwürdigen Problem mit meiner WireGuard-Konfiguration weiterhelfen kann. Vielleicht hat jemand ähnliche Erfahrungen gemacht.
Ausgangssituation:
Server: Externer VPS mit 2.5 Gbit Anbindung
Client: 1 Gbit Down / 100 Mbit Up
Gateway im Heimnetzwerk: Linux-Server mit 1 Gbit Down / 100 Mbit Up
Verbindungen im Detail:
Client ↔ Server: Die Verbindung ist stabil und erreicht die maximale Geschwindigkeit, kein Problem hier.
Gateway ↔ Server: Ebenfalls stabil und schnell.
Problemfall: Gateway ↔ Client über den Server
Hier kommt es zu deutlichen Problemen: Die Verbindung ist extrem schwankend, meist nur 5–50 Mbit und alles andere als stabil. Bei iperf3-Tests zwischen Client und Gateway beobachte ich, dass die Übertragungsrate ständig hoch und runter geht. Oft sind es nur 20 Mbit oder weniger, manchmal steigen sie kurzzeitig auf 50-80 Mbit.
Was ich bereits versucht habe:
MTU-Optimierung: Die besten Ergebnisse konnte ich bisher mit einer MTU von 1280 erzielen. Jedoch ist das Problem damit nicht behoben.
Verschiedene Clients: Getestet habe ich unter Windows, Linux, Android und iOS – das Verhalten ist auf allen Plattformen gleich.
CPU-Auslastung geprüft: Auf allen beteiligten Systemen ist die CPU-Auslastung minimal und dürfte nicht der Grund für die Limitierungen sein.
Mein Ziel:
Ich möchte eine stabile, schnelle Verbindung vom Heimnetzwerk zu meinen Clients erreichen, sodass die Clients dabei auch die Internetverbindung des Heimnetzwerks nutzen können. Grundsätzlich erfüllt die aktuelle Konfiguration dieses Ziel, allerdings ist die Verbindung viel zu instabil, um darüber zu arbeiten.
Habt ihr eine Idee, was hier der Grund sein könnte oder Tipps, wie ich die Verbindung optimieren kann?
Danke vorab für jede Hilfe!
WG-Konfig Server:
[Interface]
Address = 10.22.33.1/24
PrivateKey = XXXX
ListenPort = 51820
MTU = 1280
# IPv4 Forwarding aktivieren
PreUp = sysctl -w net.ipv4.ip_forward=1
# nftables Regeln setzen
PostUp = nft add table ip nat
PostUp = nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
PostUp = nft add rule ip nat postrouting oifname "ens6" ip saddr 10.22.0.0/16 ip daddr != {10.22.0.0/16, 10.22.33.0/24} masquerade
PostUp = nft add table ip filter
PostUp = nft add chain ip filter forward { type filter hook forward priority 0 \; }
PostUp = nft add rule ip filter forward iifname "wg0" oifname "ens6" ip daddr 10.22.0.0/16 accept
PostUp = nft add rule ip filter forward iifname "ens6" oifname "wg0" ip saddr 10.22.0.0/16 accept
PostUp = nft add rule ip filter forward iifname "wg0" oifname "wg0" ip saddr 10.22.33.0/24 ip daddr 10.22.33.0/24 accept
PostUp = nft add rule ip filter forward iifname "wg0" oifname "wg0" ip saddr 10.22.0.0/16 ip daddr 10.22.0.0/16 accept
# nftables Regeln entfernen
PreDown = nft delete table ip nat
PreDown = nft delete table ip filter
# Gateway
[Peer]
PublicKey = XXXX
AllowedIPs = 0.0.0.0/0
# Client 1
[Peer]
PublicKey = XXXX
AllowedIPs = 10.22.33.3/32
WG-Konfig Gateway:
[Interface]
Address = 10.22.33.2/24
PrivateKey = XXXX
DNS = 10.22.22.81
ListenPort = 51822
MTU = 1280
# IPv4-Weiterleitung aktivieren
PreUp = sysctl -w net.ipv4.ip_forward=1
# nftables Regeln für Routing
PostUp = nft add table ip filter
PostUp = nft add chain ip filter forward { type filter hook forward priority 0 \; }
# Erlaube Forwarding zwischen WireGuard-Netzwerk (10.22.33.0/24) und lokalem Netzwerk (10.22.0.0/16)
PostUp = nft add rule ip filter forward iifname "wg0" oifname "eth0" ip saddr 10.22.33.0/24 ip daddr 10.22.0.0/16 accept
PostUp = nft add rule ip filter forward iifname "eth0" oifname "wg0" ip saddr 10.22.0.0/16 ip daddr 10.22.33.0/24 accept
# Erlaube DNS und andere wichtige Dienste, falls benötigt (optional)
# Hier Beispielregel, um DNS über das Interface zu erlauben
PostUp = nft add rule ip filter forward iifname "wg0" oifname "eth0" ip daddr 10.22.22.81 udp dport 53 accept
# nftables Regeln beim Herunterfahren löschen
PreDown = nft delete table ip filter
# WireGuard Peer-Verbindung zum Server
[Peer]
PublicKey = XXXX
Endpoint = <Server-IP>:51820
AllowedIPs = 10.22.33.0/24
PersistentKeepalive = 25
WG-Konfig Client:
[Interface]
PrivateKey = XXXX
Address = 10.22.33.3/32
ListenPort = 51821
DNS = 10.22.22.81
MTU = 1280
[Peer]
PublicKey =XXXX
Endpoint = <Server-IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Please also mark the comments that contributed to the solution of the article
Content-ID: 669346
Url: https://administrator.de/contentid/669346
Printed on: December 14, 2024 at 16:12 o'clock
13 Comments
Latest comment
Bitte in aller Ruhe das hiesige Wireguard Tutorial lesen und entsprechend umsetzen:
Merkzettel: VPN Installation mit Wireguard
Die gröbsten Fehler im obigen Setup:
Ein mehr oder minder klassisches und einfaches Ruleset für die nftables Firewall (/etc/nftables.conf) in so einem Design sähe z.B. so aus:
.2.0 und .10.0 sind hier nur remote Beispiel IP Netze und müssen auf eigene Netze angepasst werden. 10.22.33.0/24 ist hier das interne WG Netz.
Wenn öffentlicher SSH Zugang auf den vServer besteht sollte ggf. zur besseren Sicherung die Authentisierung auf Zertifikate umgestellt werden und zusätzlich noch fail2ban installiert sein.
Merkzettel: VPN Installation mit Wireguard
Die gröbsten Fehler im obigen Setup:
- Wie leider so oft die falschen Subnetzmasken bei der internen IP Adressierung konfiguriert! Regel für die internen IPs: Verwendete Netzwerk Maske (z.B. /24) am internen Interface aber /32er Hostmasken in den AllowedIPs, andernfalls scheitert das interne Cryptokey Routing. Am Server ist es bis auf das Gateway richtig, am Gateway selber aber falsch!
- Das Gateway sollte in jedem Falle Split Tunneling verwenden aber niemals Gateway Redirect!
- Es ist wenig zielführend und auch kontraproduktiv die Firewall in die WG Kofig zu integrieren. Die nftables FW Funktion gehört da nicht hin sondern immer statisch in die /etc/nftables.conf! Das Tutorial gibt entsprechende Hinweise dazu. VPN ist VPN only und Firewall bleibt Firewall.
Ein mehr oder minder klassisches und einfaches Ruleset für die nftables Firewall (/etc/nftables.conf) in so einem Design sähe z.B. so aus:
#!/usr/sbin/nft -f
flush ruleset
# Interface name
define pub_iface = "eth0"
# Wireguard port
define wg_port = 55820
table inet drop-bad-ct-states {
chain prerouting {
type filter hook prerouting priority -150; policy accept;
# drop packets in "invalid" connection-tracking state
ct state invalid drop
# drop tcp packets for new connections that aren't syn packets
tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop
# drop XMAS packets.
tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
# drop NULL packets.
tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
# drop new connections over rate limit
ct state new limit rate over 1/second burst 20 packets drop
}
}
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# accept any localhost traffic
iif lo accept
# accept any wireguard traffic
iifname "wg0" accept
# accept traffic originated from us
ct state established,related accept
# accepted ICMP types
ip protocol icmp icmp type { time-exceeded, parameter-problem, destination-unreachable } accept
# accept common local TCP services on public interface
iif $pub_iface tcp dport { ssh } ct state new accept
# accept neighbour discovery otherwise IPv6 connectivity fails.
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
# Log and count dropped traffic
# log prefix "[nftables]Denied: " counter drop
# Only count dropped traffic
counter drop
}
chain output {
type filter hook output priority filter;
}
}
table ip nat {
define VPN_NETS = {
192.168.2.0/24, 192.168.10.0/24 }
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oifname $pub_iface ip daddr $VPN_NETS accept
ip saddr 10.22.33.0/24 oifname $pub_iface masquerade
}
}
Wenn öffentlicher SSH Zugang auf den vServer besteht sollte ggf. zur besseren Sicherung die Authentisierung auf Zertifikate umgestellt werden und zusätzlich noch fail2ban installiert sein.
Das Netzwerk des VPS Hoster hat auch genug Bandbreite und Forward für deine Kiste?
Hier kannst Du iperfen...
https://proof.ovh.net/
Hier kannst Du iperfen...
https://proof.ovh.net/
Es ist immer die Rede davon den Server im heimischen Netzwerk zu betreiben.
Ist eigentlich auch Unsinn, denn das eine hat mit dem anderen ja nichts zu tun. Bei einem DS-Lite Anschluss bist du zu einem vServer als VPN Jumphost gezwungen. Wenn man es richtig macht das das doch vollkommen normal sowas auf einem vServer zu betreiben. Das machen Millionen weltweit.Allerdings verstehe ich nicht wie ich das alles auf meinen Anwendungszweck anwenden soll?
Mmmmhhh, das verstehen wir jetzt nicht! 🤔 Oben sind die doch deine Fehler im Setup schon alle explizit genannt worden. Korrigiere die dann kommt das auch alles zum Fliegen. Ist doch ein übliches Prozedere das man Fehler beseitigt. Wozu muss man da nach einer "Anwendung" fragen?sollte mein Wireguard Netzwerk nicht im selben IP Bereich wie mein lokales Netzwerk liegen?
Das wäre tödlich solltest du das gemacht haben. Ist doch auch logisch, denn so gut wie alle VPN Protokolle werden geroutet, sprich müssen einzigartige Netze haben damit die IP Wegefindung eindeutig ist. IP Grundschule erste Klasse... 😉Also würde ich für mein WG-Netz z.B. 100.22.33.0/24 nehmen
Oha, es scheitert bei dir schon an den simpelsten Basics. Dieses Netz ist keine private IP und gehört Amazon:
NetRange: 100.20.0.0 - 100.31.255.255
CIDR: 100.24.0.0/13, 100.20.0.0/14
NetType: Direct Allocation
Organization: Amazon.com, Inc. (AMAZO-4)
RegDate: 2018-01-10
Updated: 2018-01-10
Ref: https://rdap.arin.net/registry/ip/100.20.0.0
Address: Amazon Web Services, Inc.
Address: P.O. Box 81226
City: Seattle
Das zu nutzen ist also keine besonders intelligente Idee!!
Du solltest dir ggf. zuallerst einmal ein paar Tips zur VPN IP Adressierung aneignen bevor du weitermachst. Oder dir jemanden an die Hand nehmen der weiss was er tut?! Die privaten RFC1918 IP Netze in denen gemeinhin sowas gemacht wird sollte man schon kennen.
Da du weder das einfache Firewall Setup noch NAT verstehst wird das eine recht steile Lernkurve für dich. Jemand der dir hilft wäre vermutlich nicht verkehrt.
Nur so viel zu deinen ToDos.
- Du musst die IP Adressierung und Masken anpassen in deinem WG Setup. Das Wireshark Tutorial zeigt funktionierende Praxisbeispiele, auch in den weiterführenden Links wie z.B. HIER an denen du dich einfach orientieren kannst.
- Das gesamte "PostUP..." Geraffel gehört idealerweise nicht in das VPN Setup sondern einzig und allein ins nftables Firewall Setup unter /etc/nftables.conf
- Hilfreich wäre eine kleine Topoligieskizze von dir welches IP Netz wo. Damit könnte man dir zielgerichtet helfen.
So kannst du gucken ob du genug Bandbreite bekommst.
Die günstigen VPS Hoster haben oft ein Bandbreitenprobleme auf den ersten Metern.
Die günstigen VPS Hoster haben oft ein Bandbreitenprobleme auf den ersten Metern.
Der WG-Client nutzt die Internetverbindung des VPS
Ja, das ist klar weil du hier wieder mal das falsche Gateway Redirect (0.0.0.0) benutzt anstatt Split Tunneling. Da wurdest du oben wiederholt drauf hingewiesen hast es aber schlicht ignoriert. AllowedIPs = 10.33.33.1/32, 10.22.0.0/16 Wäre hier richtig gewesen im Setup. Danach musst du einen Reboot machen und den Tunnel neu aufbauen damit das greift. Dann geht lediglich Zieltraffic zu den Adressen 10.33.33.1/32, 10.22.x.x/16 in den VPN Tunnel.
Ein paar Tips:
- DNS im Client anzugeben ist unsinnig und kannst du komplett weglassen. Das ist ausschliesslich nur dann erforderlich wenn du interne Hostnamen auflösen musst was bei dir aber vermutlich nicht der Fall ist. Folglich kannst du das weglassen, dann benutzt der Client den lokal gelernten DNS Server. Oder befindet sich hinter der .22.81 ein DNS Server? Vermutlich ist das der Fehler beim Client.
- MTU Settings solltest du erstmal weglassen. Die WG default MTU ist 1420 und in der Regel völlig ausreichend. Erst wenn du Schwierigkeiten mit Fragmentierung bekommst solltest du das anpassen sonst den Default belassen indem du es weglässt.
- Nebenbei: Hat es einen tieferen Sinn ein /16er Netz zu betreiben? 65.534 Endgeräte willst du ja wohl kaum adressieren zumal du ja so oder so nur mit 10.22.22er Adressen arbeitest. Warum also kein 10.22.22.0/24er Netz? Es besteht auch durch die .22.22 der latente Verdacht das du ggf. doch irgendwo eine /24 Maske benutzt und es so zu einem Maskenmissmatch innerhalb des Netzes kommt. Das solltest du nochmal wasserdicht prüfen.
Bis auf das falsche Client Setup also alles richtig gemacht. 👍 Die nft Firewall braucht natürlich noch etwas "Tuning" um den Server sicherer zu machen.
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
How can I mark a post as solved?
How can I mark a post as solved?