Wireguard über vServer ins Heimnetz will nicht
Moin,
ich verzweifle seit Tagen an einer Wireguard Verbindung ins Heimnetz.
Verzeiht Fehler auch wenn er noch so doof ist, ich bin was Wireguard und iptables angeht Anfänger.
Zur Situation:
Wie es mittlerweile vielen geht habe ich einen Anschluss mit CGNAT (Deutsche Glasfaser). Nun hatte ich den Plan mit einem meiner vServer (öffentliche ipv4) ein Wireguard Server zu bauen um so auf mein Homelab per VPN zugreifen zu können. Ich habe bereits viele der hier und woanders zur Verfügung stehenden Anleitungen gelesen aber komme trotzdem nicht weiter.
Hier mal eine Skizze meines Plans:
Mit einem Client (Laptop) möchte ich auf mein Heimnetz zugreifen. Der vServer ist der Wireguard Server zu dem sich der Laptop und ein Proxmox LXC verbindet. Die Verbindung klappt soweit. Der LXC und mein Laptop verbinden sich zum vServer und bekommen ihre wg0 ip. Die Geräte können sich auch untereinander anpingen (mit den wg0-Adressen). Nur komme ich vom Laptop nicht in mein Heimnetz. Muss ich hier bestimmte iptables rules erstellen, dass Anfragen auf dem LXC vom wg0 Interface auf das eth0 Interface weitergeleitet werden? Wenn ja welche? Bei AllowedIps habe ich 0.0.0.0/0 eingetragen und bei der Serverkonfiguration schon viel rumprobiert.
vServer-config (die PostUp/PostDown Routen wurden von dem wireguard-script erstellt):
Client (LXC):
Client (Laptop):
ich verzweifle seit Tagen an einer Wireguard Verbindung ins Heimnetz.
Verzeiht Fehler auch wenn er noch so doof ist, ich bin was Wireguard und iptables angeht Anfänger.
Zur Situation:
Wie es mittlerweile vielen geht habe ich einen Anschluss mit CGNAT (Deutsche Glasfaser). Nun hatte ich den Plan mit einem meiner vServer (öffentliche ipv4) ein Wireguard Server zu bauen um so auf mein Homelab per VPN zugreifen zu können. Ich habe bereits viele der hier und woanders zur Verfügung stehenden Anleitungen gelesen aber komme trotzdem nicht weiter.
Hier mal eine Skizze meines Plans:
Mit einem Client (Laptop) möchte ich auf mein Heimnetz zugreifen. Der vServer ist der Wireguard Server zu dem sich der Laptop und ein Proxmox LXC verbindet. Die Verbindung klappt soweit. Der LXC und mein Laptop verbinden sich zum vServer und bekommen ihre wg0 ip. Die Geräte können sich auch untereinander anpingen (mit den wg0-Adressen). Nur komme ich vom Laptop nicht in mein Heimnetz. Muss ich hier bestimmte iptables rules erstellen, dass Anfragen auf dem LXC vom wg0 Interface auf das eth0 Interface weitergeleitet werden? Wenn ja welche? Bei AllowedIps habe ich 0.0.0.0/0 eingetragen und bei der Serverkonfiguration schon viel rumprobiert.
vServer-config (die PostUp/PostDown Routen wurden von dem wireguard-script erstellt):
[Interface]
Address = 10.1.1.1/24,fd42:42:42::1/64
ListenPort = 51820
PrivateKey = QP46Y8Q2uqS8fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
PostUp = iptables -I INPUT -p udp --dport 51820 -j ACCEPT
PostUp = iptables -I FORWARD -i ens3 -o wg0 -j ACCEPT
PostUp = iptables -I FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostUp = ip6tables -I FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D INPUT -p udp --dport 51820 -j ACCEPT
PostDown = iptables -D FORWARD -i ens3 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
### Client homelab
[Peer]
PublicKey = EzUOCtkaUxJd5PASwMKxxxxxxxxxxxxxxxxxxxx
PresharedKey = GH6Mp7uFF7QtyEOgQxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.1.1.2/32,fd42:42:42::2/128,192.168.1.0/24
### Client laptop-test
[Peer]
PublicKey = +lqJHvzEv3FrTKYxCQAYUxxxxxxxxxxxxxxxxxxxxxxxx
PresharedKey = WOzyqFWhcwBADBWxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.1.1.3/32,fd42:42:42::3/128
Client (LXC):
[Interface]
PrivateKey = 8BbifMX2rdovhQER2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address = 10.1.1.2/32,fd42:42:42::2/128
DNS = 8.8.8.8,1.1.1.1
[Peer]
PublicKey = FrbmW5zOarWkLaxxxxxxxxxxxxxxxxxxxxxxxx
PresharedKey = GH6Mp7uFFxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Endpoint = vserver.example.com:51820
AllowedIPs = 0.0.0.0/0,::/0
Client (Laptop):
[Interface]
PrivateKey = gHk5c8s+6xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address = 10.1.1.3/32,fd42:42:42::3/128
DNS = 8.8.8.8,1.1.1.1
[Peer]
PublicKey = FrbmW5zOarWkLaBxxxxxxxxxxxxxxxxxxxxxx
PresharedKey = WOzyqFWhcwBADBxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Endpoint = vserver.example.com:51820
AllowedIPs = 0.0.0.0/0,::/0
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 43440658944
Url: https://administrator.de/forum/wireguard-ueber-vserver-ins-heimnetz-will-nicht-43440658944.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
21 Kommentare
Neuester Kommentar
Das Wireguard Tutorial hast du gelesen und deine Konfig entsprechend angepasst?! 🤔
Merkzettel: VPN Installation mit Wireguard
Statt der in dieJahre gekommenen iptables solltest du besser nftables verwenden auf dem vServer und das idealerweise in einer statischen Firewall Konfig über /etc/nftables.conf und niemals über die Wireguard Konfig Datei selber.
Ein Preshred Key ist sinnfrei bei der Verwendung von Keys denn man benötigt zum Gürtel nicht noch einen überflüssigen Hosenträger. Siehe Tutorial…
0.0.0.0\0 ist ein Gateway Redirect und nur dann sinnvoll wenn man es wirklich benötigt. Split Tunneling ist in den meisten Fällen immer die intelligentere Wahl.
Bei dir wie üblich leider auch der Kardinalsfehler NAT im Tunnel zu machen was kein transparentes Routing erlaubt.
Eine Beispielkonfig für nftables findest du in einem identischen Jumphost Tutorial was statt Wireguard die bordeigenen VPN Clients benutzt anstatt mit externen VPN Clients zu frickeln:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Die nftables Konfig ist aber identisch zu Wireguard.
Ob es besonders intelligent ist Google DNS Server zu verwenden die dein Internetverhalten ausspäht und an Dritte vermarktet musst du selber entscheiden. Intelligent und Datensicherheit geht bekanntlich anders…
Die interne VPN IP Adressierung ist ebenso nicht gut gewählt und kann dir früher oder später auf die Füße fallen. Siehe dazu auch hier.
Merkzettel: VPN Installation mit Wireguard
Statt der in dieJahre gekommenen iptables solltest du besser nftables verwenden auf dem vServer und das idealerweise in einer statischen Firewall Konfig über /etc/nftables.conf und niemals über die Wireguard Konfig Datei selber.
Ein Preshred Key ist sinnfrei bei der Verwendung von Keys denn man benötigt zum Gürtel nicht noch einen überflüssigen Hosenträger. Siehe Tutorial…
0.0.0.0\0 ist ein Gateway Redirect und nur dann sinnvoll wenn man es wirklich benötigt. Split Tunneling ist in den meisten Fällen immer die intelligentere Wahl.
Bei dir wie üblich leider auch der Kardinalsfehler NAT im Tunnel zu machen was kein transparentes Routing erlaubt.
Eine Beispielkonfig für nftables findest du in einem identischen Jumphost Tutorial was statt Wireguard die bordeigenen VPN Clients benutzt anstatt mit externen VPN Clients zu frickeln:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Die nftables Konfig ist aber identisch zu Wireguard.
Ob es besonders intelligent ist Google DNS Server zu verwenden die dein Internetverhalten ausspäht und an Dritte vermarktet musst du selber entscheiden. Intelligent und Datensicherheit geht bekanntlich anders…
Die interne VPN IP Adressierung ist ebenso nicht gut gewählt und kann dir früher oder später auf die Füße fallen. Siehe dazu auch hier.
Ich hänge moch mal da ran, weil auch mein Heimnetz mit CGNAT im Internet steht ...
Ich eerde aber noch nicht ganz klar, wo dein VServer steht - die öffentliche IP.
Weil du dem zugleich 2 Schnittstellen ...
- eth0
- wg0
zuordnest.
Wenn der an deinem Glasfaseranschluss hängt, ist er CGNAT-betroffen mit seiner "öffentlichen IP" und somit aus dem Internet nicht erreichbar ...
Mein VServer, der dafür geplant ist steht bei strato (1€/Monat)
Geplant ist netmaker.io (Community) als Wireguard-Vermittler ...
Bin da aber aus privaten Gründen noch nicht weiter gekommen als im
FritzBox als VPN-Client (Wireguard)
Der VServer ist gebucht, geplant ist Ubuntu aps Server mit netmaker.io als Verbindungsmanager ...
Ich eerde aber noch nicht ganz klar, wo dein VServer steht - die öffentliche IP.
Weil du dem zugleich 2 Schnittstellen ...
- eth0
- wg0
zuordnest.
Wenn der an deinem Glasfaseranschluss hängt, ist er CGNAT-betroffen mit seiner "öffentlichen IP" und somit aus dem Internet nicht erreichbar ...
Mein VServer, der dafür geplant ist steht bei strato (1€/Monat)
Geplant ist netmaker.io (Community) als Wireguard-Vermittler ...
Bin da aber aus privaten Gründen noch nicht weiter gekommen als im
FritzBox als VPN-Client (Wireguard)
Der VServer ist gebucht, geplant ist Ubuntu aps Server mit netmaker.io als Verbindungsmanager ...
Just for Info… Für die FRITZ!box gelten wegen ihrer nicht Standard konformen WG Konfig auch ein paar besondere Bedingungen wenn man sie mit klassischen Wireguard Endgeräten koppeln möchte.
Beachtet man diese klappt es auf mit der FB fehlerlos auf Anhieb:
S2S-Wireguard: AVM zu Mikrotik
Nur das du das auf dem Radar hast?! 😉
Und… ein vServer ist in Regel ja bei einem Hoster positioniert und niemals in einem heimischen Netzwerk. Dann wäre es ein simpler Server ohne „v“. 😉
Beachtet man diese klappt es auf mit der FB fehlerlos auf Anhieb:
S2S-Wireguard: AVM zu Mikrotik
Nur das du das auf dem Radar hast?! 😉
Und… ein vServer ist in Regel ja bei einem Hoster positioniert und niemals in einem heimischen Netzwerk. Dann wäre es ein simpler Server ohne „v“. 😉
Richtig.
Die Idee, die FritzBox mit dem Verbindungsserver (netmaker.io auf Ubuntu auf VServer bei strato)...
... ist ja eine Idee um keine zusätzliche Hardware einzusetzen ...
Ob ich die FB dann überzeugen kann mit dem netmaker.io zusammen zu arbeiten, steht noch auf einem anderen Blatt ...
Und wenn der WG-Server hinter einem CGNAT hängt, dürfte das m.W genauso wenig mit einer Direktanwahl funktionieren wie andere VPN ...🤔
Der TO irritiert mich eben bei "VServer" und den genannten Schnittstellen ...
... ein VServer hat ja in der Basis nur eine nutzbare öffentliche IP (es sei denn man gibt mehr Geld für mehrere aus) - daher meine Vermutung, das der VServer, eine VM im Intranet ist - hinter CGNAT
Meine Recherche brachte mich zu netmaker.io als Verbindungsserver, der z.B. mehrere auch CGNAT-betroffene Clients mit dem WG-Server - meine Idee: die FritzBox - vermittelt ...
Ich zab aber noch'n PI3 als Alternative für einen WG-Server im Heimnetz ...
... aber auch der bräuchte m.W. einen Broker um aus dem Internet hinter CGNAT erreichbar zu sein ... 🤔
Ob ich die FB dann überzeugen kann mit dem netmaker.io zusammen zu arbeiten, steht noch auf einem anderen Blatt ...
Funktioniert fehlerlos wie du am o.a. Tutorial ja sehen kannst. 😉Und wenn der WG-Server hinter einem CGNAT hängt, dürfte das m.W genauso wenig mit einer Direktanwahl funktionieren wie andere VPN
Zweifelsohne richtig, nur das du dann von einem privaten Server im Heimnetz redest und nicht von einem vServer der in der Regel mit öffentlichen IPs beim Hoster arbeitet. Äpfel und Birnen…😉ein VServer hat ja in der Basis nur eine nutzbare öffentliche IP
Auch das ist absolut richtig. Nur…was hat das mit einer Wireguard Jumphost Konfig zu tun? Die VPN Kommunikation geschieht ja ausnahmslos nur über das interne, virtuelle wg0 Interface und das hat ja jeder Server egal ob vServer oder privater Server im Heimnetz. Wo ist hier also der Punkt? 🤔CGNAT kannst du nur mit einem vServer beim Hoster bedienen oder einem kostenpflichtigen v4 Tunnelbroker sofern du über IPv4 redest.
Wireguard bietet dir aber auch immer die IPv6 Option mit einer IPv4 Adressierung im Tunnel welche ja auch bei einem DS-Lite Anschluss rennt.
Wir wollen aber jetzt den Thread des TOs hier nicht mit fremden Themen kapern… 🏴☠️ 😉
Danke, @aqui.
Hatte das bisher nicht realisiert, das das Tutorial auch diese Konstellation berücksichtigt.
Werde mir das nochmal zu Gemüte führen.
Hatte das bisher nicht realisiert, das das Tutorial auch diese Konstellation berücksichtigt.
Werde mir das nochmal zu Gemüte führen.
Der vServer bei Oracle hat quasi ein einen virtuellen Router.
Aber NUR dann, wenn man auf dem Server auch IPv4 Forwarding (Routing) in der Datei /etc/sysctl.conf aktiviert!! Im Default ist das deaktiviert und es wird NICHT geroutet! 🧐Merkzettel: VPN Installation mit Wireguard
Dieser hat die öffentliche ip an eth0 und hat den wireguard Port wg0
...eine Binsenweisheit die seit Jahrhunderten jedem Netzwerker bekannt ist! Die automatisch erstellten Regeln habe ich rausgenommen. NAT ist weg und die benötigten iptables Regeln fest eingetragen.
Grundsätzlich erstmal alles richtig gemacht! 👍Die 192.168.1.17 (LXC) lässt sich vom Server anpingen; alles andere nicht.
Das sieht verdächtig danach aus das du das Tutorial nicht richtig gelesen oder verstanden hast! ☹️Fehler ist sehr wahschreinlich eine fehlende statische Route auf das interne Wireguard IP Netz.
Sie dazu auch den Routing Abschnitt im Tutorial!
Nur so viel zum erwartbaren Verhalten:
Die "alles andere" Endgeräte haben sehr wahrscheinlich den lokalen Internet Router als Default Gateway. Pingst du also nun vom WG Server, kommst du an den "alles andere" Endgeräten logischerweise mit einer 10.1.1.x /24 Absender IP Adresse aus dem internen Wireguard Netz an.
Das "alles andere" Endgerät erkennt das dies ein externes IP Netz ist und nicht das lokale und forwardet die Antwort wie zu erwarten an den Internet Router der ja sein Default Gateway ist.
Ohne statische Route ins Wireguard Netz die ihm explizit sagt wo dieser Traffic hin muss, forwardet der Router die Antwort dann an den Internet Provider der ja seinerseits sein Default Gateway ist.
Was dieser dann mit privaten RFC1918 IP Netzen macht weisst du als Netzwerk Profi sicher auch selber ohne extra Erklärung!
Andernfalls hilft es sicher diese simplen Basics noch einmal genau im Routing Grundlagentutorial nachzulesen. 😉
Fazit:
Statische Route nachtragen dann klappt das auch alles sofort und beim nächsten Mal das Tutorial bitte gewissenhaft durchlesen und umsetzen! 🧐
OK, statische Route war wie erwartet das Problem.
Wie erwartet. Tutorials lesen hilft! als auch das Heimnetz ist nicht erreichbar.
Wenn der Laptop eine Winblows Maschine ist, ist das auch klar und erwartbar. Grund ist die lokale Winblows Firewall weil...- diese generell das ICMP Protokoll blockt. Siehe dazu auch hier.
- diese generell Traffic von fremden IP Adressen blockt und nur Traffic aus dem eigenen Netz zulässt. Siehe zu der Thematik hier.
Konfig des Telefons und das Pendant auf dem Server wären hilfreich. Beispiel zum Vergleich u.a. hier
Deine WG Konfiguration sieht erstmal gut aus. Homelab Konfig muss auch die iPhone IP haben.
Pingst du vom iPhone aus?? Hier ist es hilfreich mit den bekannten HE.NET Tools zu arbeiten!
https://apps.apple.com/de/app/he-net-network-tools/id858241710
Was auffällig ist, ist die Tatsache das in deiner Client Konfig ein PersistentKeepalive = 25 fehlt! (Siehe dazu auch den Client Konfig Abschnitt im Tutorial)
Die Clients (VPN Initiators, und nur die) sollten immer einen Keepalive senden weil es sonst passieren kann das eine NAT Firewall im Pfad den UDP Port per Timeout schliesst was dann zu einem Tunnelabbruch führt.
Das du den Server 10.1.1.1 selber nicht pingen kannst zeigt eigentlich das da vermutlich etwas mit den Keys nicht stimmt und das iPhone erst gar keinen Tunnel aufbaut.
Was sagt ein wg show auf dem Server wenn das iPhone einen (vermeintlich) aktiven Tunnel hat? Da sollte dann sowas wie das hier zu sehen sein:
Das zeigt dir ob der Tunnel überhaupt "established" ist oder nicht.
Hast du daran gedacht den Wireguard Prozess nach Einrichten des iPhone Peers mit
systemctl enable wg-quick@wg0.service
neu zu starten damit dieser die Peer Konfig neu einlesen kann??
Alternativ geht das auch indem man erst ein wg-quick down wg0 und danach ein wg-quick up wg0 ausführt.
Pingst du vom iPhone aus?? Hier ist es hilfreich mit den bekannten HE.NET Tools zu arbeiten!
https://apps.apple.com/de/app/he-net-network-tools/id858241710
Was auffällig ist, ist die Tatsache das in deiner Client Konfig ein PersistentKeepalive = 25 fehlt! (Siehe dazu auch den Client Konfig Abschnitt im Tutorial)
Die Clients (VPN Initiators, und nur die) sollten immer einen Keepalive senden weil es sonst passieren kann das eine NAT Firewall im Pfad den UDP Port per Timeout schliesst was dann zu einem Tunnelabbruch führt.
Das du den Server 10.1.1.1 selber nicht pingen kannst zeigt eigentlich das da vermutlich etwas mit den Keys nicht stimmt und das iPhone erst gar keinen Tunnel aufbaut.
Was sagt ein wg show auf dem Server wenn das iPhone einen (vermeintlich) aktiven Tunnel hat? Da sollte dann sowas wie das hier zu sehen sein:
Das zeigt dir ob der Tunnel überhaupt "established" ist oder nicht.
Hast du daran gedacht den Wireguard Prozess nach Einrichten des iPhone Peers mit
systemctl enable wg-quick@wg0.service
neu zu starten damit dieser die Peer Konfig neu einlesen kann??
Alternativ geht das auch indem man erst ein wg-quick down wg0 und danach ein wg-quick up wg0 ausführt.
Zitat von @mrsna5:
Beim Homelab Client habe ich auch die config angepasst. (ipv4 forwarding ist bereits aktiviert)
Verbindung baut auch auf. Beide Geräte erreichen sich gegenseitig. Die 192.168.1.17 (LXC) lässt sich vom Server anpingen; alles andere nicht. Hier müsste ja ein forwarding passieren, was die Anfrage aus dem Wireguard-netz an mein Heimnetz weiterleitet. Das funktioniert aber nicht. Beim Versuch meinen Router (192.168.1.1) vom Server zu erreichen schlägt der Ping fehl. Wo ist hier mein Denkfehler?
Beim Homelab Client habe ich auch die config angepasst. (ipv4 forwarding ist bereits aktiviert)
[Interface]
PrivateKey = 8BbifMX2rdovhQERxxxxxxxxxxxxxxxxxxxx
Address = 10.1.1.2/24
[Peer]
PublicKey = FrbmW5zOarWkLaBhQ6xxxxxxxxxxxxxxxxxxxxxxxx
Endpoint = 130.162.xxx.xxx:51820
AllowedIPs = 10.1.1.1/32
PersistentkeepAlive = 25
Verbindung baut auch auf. Beide Geräte erreichen sich gegenseitig. Die 192.168.1.17 (LXC) lässt sich vom Server anpingen; alles andere nicht. Hier müsste ja ein forwarding passieren, was die Anfrage aus dem Wireguard-netz an mein Heimnetz weiterleitet. Das funktioniert aber nicht. Beim Versuch meinen Router (192.168.1.1) vom Server zu erreichen schlägt der Ping fehl. Wo ist hier mein Denkfehler?
Die AllowedIPs am Homelab Client sind unvollständig, diese sollten so lauten damit auch der iPhone Client durch kommt!!
AllowedIPs = 10.1.1.0/24
AllowedIPs = 10.1.1.1/32,10.1.1.3/32
Mit deiner aktuellen Config (10.1.1.1/32) erlaubst du ja nur dem Server selbst in dein Heimnetz zu kommen, ergo kann so nix vom Eierfön mit der IP 10.1.1.3 durch kommen 😉
AllowedIPs und das Kryptokey Routing auf Client wie auf Server-Seite verstehen lernen lautet die Devise, dann klappt's auch mit dem Nachbarn. 🖖👍
PJ.
Die statische Route auf dem Default GW des
Heimnetzes für das WG Netz auch nicht vergessen sonst erreichst du nur den WG Container und sonst nix im Heimnetz.
Heimnetzes für das WG Netz auch nicht vergessen sonst erreichst du nur den WG Container und sonst nix im Heimnetz.
Netz 10.1.1.0/24 Gateway = <IP des WG-Containers im Heimnetz>
👍 Na dann fehlt ja nur noch der Haken am Beirag.
Die Lösung orientiert sich natürlich sehr an....
Eigentlich hilft da eher seine Seite die diese Einrichting mit einem vServer Jumphost beschreibt! 😉IKEv2 VPN Server und Jumphost Lösung für DS-Lite/CGNAT Anschlüsse
Diese hat nämlich zudem den praktischen Vorteil das man nicht umständlich mit überflüssigen VPN Clients auf allen Endgeräten rumfrickeln muss sondern bequem überall die so oder so vorhandenen Onboard VPN Clients sinnvoll nutzen kann! 😉