Zugriff auf Heimnetzwerk mit wg-easy

Hat FritzBox derweil nicht ein eigenes Feature veröffentlicht, was dir erlaubt WireGuard zu konfigurieren?

Ich habe das mal bei Dennis Schröder (Raspberry Pi Cloud) auf Youtube aufgeschnappt ...

Guck doch mal bei ihm vorbei, ich meinte er hätte auch was wegen CGNAT mal gezeigt.

Wenn du schonmal in die weite Welt rauskommst, gehe ich stark davon aus das deine FritzBox irgendwo abblockt.

Kann dir aber bei FritzBox leider nicht helfen, da es die hier bei uns ausserhalb von DE standardmässig nicht gibt.

Ich hab da auch lange gefummelt mit Wireguard Installation auf den VPS.

Ich löse das Problem CGNAT inzwischen ohne eine Installation (bis auf socat) auf dem VPS, indem ich den gesamten Wireguard Verkehr mittels eines simplen Ssocat Aufrufs quasi von Public VPS IPv4/6 auf die Public IPv6 auf die Fritzbox weiterleiten.

Vorteil: Kaum Konfiguration auf dem VPS nötig (ich richte dazu nur einen simplen systemd Dienst ein, der socat startet), dann noch die Einrichtung der Wireguard Zugänge auf der Fritzbox vornehmen.

Als Wireguard Serveradresse tauscht man in der von der Fritzbox erzeugten Config die Fritzbox-Adresse gegen die des VPS, fertig.

Zitat von NehCoy

Das ist echt ein cooler Ansatz! Die Public-IPv6 Adresse holst du dir dann vom My!Fritz-Service?

Genau. Der Vorteil dabei ist, dass weder IP-Routing noch Forwarding oder sonstige Netzwerkkonfigurationen auf dem VPS benötigt werden und auch kein WireGuard erforderlich ist. Die beiden Socat-Prozesse leiten die Daten einfach transparent weiter.

Hier mein Beispiel:

Angenommen die Fritzbox ist unter za3nsxxxxxxxxxxx.myfritz.net per IPv6 und der VPS Server unter vpn.example.com per IPv4 und IPv6 erreichbar, dann erstelle ich in der Fritzbox einen WG-Zugang und lade die wg_config.conf herunter, weil wir dort den Endpoint vor der Verwendung auf einem Client anpassen müssen (einfaches scannen des QR-Codes geht leider hierbei nicht mehr):

Beispiel aus einer wg_config.conf, wie sie die Fritzbox für einen Client erstellt:

[Peer]
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
PresharedKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
AllowedIPs = 172.xx.xx.0/23,0.0.0.0/0,fd00:xxxx:xxxx::/64,::/0
Endpoint = za3nsxxxxxxxxxxx.myfritz.net:52455

Dort ändern wir vor der Nutzung auf dem Client den Endpoint zu Endpoint = vpn.example.com:52455.

Das muss man für jede wg_config.conf machen, die die Fritzbox erzeugt. Die Datei importiert man dann auf dem Client (Mobile, Tablet, Notebook etc.)

Dann starte ich einmalig für alle Clients zwei socat Prozesse auf dem VPS - einen für IPv4/IPv6 und einen für IPv6/IPv6:

socat -d -d UDP4-LISTEN:52455,reuseaddr,fork UDP6:za3nsxxxxxxxxxxx.myfritz.net:52455
socat -d -d UDP6-LISTEN:52455,reuseaddr,fork UDP6:za3nsxxxxxxxxxxx.myfritz.net:52455

Ich hab das über ein quick&dirty systemd Service realisiert (geht bestimmt auch eleganter, mir genügt das hier), das startet die Basis-Prozesse beim booten selbst:

/etc/systemd/system/socatwg@.service

[Unit]
Description=Fritzbox WireGuard Port forwarding
After=local-fs.target network.target

[Service]
TimeoutStopSec=2
Type=simple
Restart=always
RestartSec=10
ExecStart=/usr/bin/socat -d -d %i-LISTEN:52455,reuseaddr,fork UDP6:za3nsxxxxxxxxxxx.myfritz.net:52455

[Install]
WantedBy=multi-user.target

Dann noch aktivieren und starten

systemctl daemon-reload 
systemctl enable socatwg@UDP4.service socatwg@UDP6.service
systemctl start socatwg@UDP4.service socatwg@UDP6.service

Für jeden Client, der sich verbindet, wird dann automatisch ein eigener socat-Prozess geforked, das können dann auch mehrere gleichzeitig sein.

Anmerkung zum WG Port der Fritzbox:
Den Port 52455 hier im Beispiel muss man an die eigene Fritzbox anpassen. Den entnimmt man der ersten wg_config.conf, ist aber für weitere Clients, die man einrichtet, immer derselbe.
Der Port, den die Fritzbox für WG vergibt (hier im Beispiel die 52455), wird zwar aus dem Bereich 49152 bis 65535 zufällig gewählt, die Fritzbox nutzt beim Erstellen von WG Zugängen aber immer wieder den gleichen Port - irgendwo merkt sich die Box das wohl einmalig.

Um noch kurz auf die ursprüngliche Frage zu antworten, falls du doch Wireguard auf dem VPS betreiben willst (das könnte spätestens dann interessant werden, wenn es ein zweites Heimnetz gibt, dass integriert werden soll, oder wenn du mehrere Roadwarrior Clients einbinden willst):

Du hast die Hinweise in der AVM Doku nicht beachtet. AVM nutzt kein Transfernetz und routet dann auf die Heimnetz Clients. D.h., die die Fritzbox hat keine 10.8.x.y Adresse, sondern die Wireguard-Konfiguration muss um die Heimnetz-Adresse der Fritzbox herumgestrickt werden. Siehe in dieser Anleitung den Hinweis mit dem blauen Dreieck in Kapitel 2:

https://fritz.com/apps/service/vpn-mit-fritz-box/3687_WireGuard-VPN-zwischen-FRITZ-Box-und-anderem-Router-einrichten

Generell ist das die Anleitung, der du beim Einrichten deines Setups folgen solltest. Dann klappt’s auch mit dem Zugriff aufs Heimnetz.

Hier gerne nen Beitrag wie das bei mir Läuft:

https://forum.netcup.de/administration…fen/#post224980

Mittlerweile habe ich auch 2 Verschiedene Fritz Box verknüpft.

Deswegen hier mal meine Aktuelle Konfiguration:

[Interface]
Address    = 10.100.0.1/24
#PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = <PORT>
PrivateKey = <PRIVKEY>

[Peer]
#FritzBox <1>
PublicKey  = <PUBKEY>
AllowedIPs = 192.168.10.0/24
PersistentKeepalive = 25

[Peer]
#FritzBox <2>
PublicKey  = <PUBKEY>
AllowedIPs = 192.168.190.0/24
PersistentKeepalive = 25

[Interface]
PrivateKey = <PRIVKEY>
Address = 192.168.10.1/24

[Peer]
PublicKey = <PUBKEY>
AllowedIPs = 10.100.0.0/24, 192.168.190.0/24
Endpoint = <IP-SERVER>:<PORT>
PersistentKeepalive = 25

[Interface]
PrivateKey = <PRIVKEY>
Address = 192.168.190.1/24

[Peer]
PublicKey = <PUBKEY>
AllowedIPs = 10.100.0.0/24, 192.168.10.0/24
Endpoint = <IP-SERVER>:<PORT>
PersistentKeepalive = 25

Nutze halt Direkt Wireguard ohne das wg-easy. Deswegen keine Ahnung wie du da die Address Ändern Kannst.

PostUp & PostDown sind auskommentiert da ich dies in NFTables schon setzte. Habe sie hier nur hinzugefügt Vollständigkeitshalber.

edit: Habe FritzBox 1 & 2 Umgestellt auf eigene Netzte damit das Alles Funktioniert. Also 1 Nutzt: 192.168.10.0/24 & 2 Nutzt: 192.168.190.0/24

wenn du nur 1 FritzBox nutzt kannst du das Standart Netzt: 192.168.178.0/24 Lassen.

Zitat von NehCoy

Edit: Die Fritz!Box verweigert das Laden des Konfigfiles wenn in der Interface Section irgendeine IP-Adresse aus ihrem Adressbereich angegeben ist.

Die Konfig mit der IP der Fritzbox muss ja auch nicht in die Fritzbox, sondern in den anderen Router (also den VPS).

Zitat von NehCoy

Naja, es kommt darauf an wer den Verbindungsaufbau initialisieren soll.

Zum einen: Bei wireguard initiiert niemand den Verbindungsaufbau. Es gibt in dem Sinne keinen Client und keinen Server, sondern eine Punkt-zu-Punkt-Verbindung zweier gleichberechtigter Partner, die sich zustandslos UDP Pakete zuschicken.

Zum Anderen: Für die IP Einstellung ist es vollkommen egal, wer die Verbindung initiiert. Damit das Routing arbeitet, müssen die in jedem Fall stimmen, sonst fließen gar keine Pakete, weder in die eine, noch in die andere Richtung.

Zitat von frank_m

Bei wireguard initiiert niemand den Verbindungsaufbau. Es gibt in dem Sinne keinen Client und keinen Server, sondern eine Punkt-zu-Punkt-Verbindung zweier gleichberechtigter Partner

Das stimmt so nicht ganz: Es gibt zwar nicht den klassischen Server und Client, aber einen Initiator. Irgendeiner der beiden muss doch schließlich die Verbindung aktiv aufbauen. Die eine Seite hat i.d.R. auch gar keine IP/Host der Gegenseite, oder sehe ich das falsch?

Zitat von SN7404

Das stimmt so nicht ganz: Es gibt zwar nicht den klassischen Server und Client, aber einen Initiator.

Nein. Wenn eine Seite ein Paket für die andere Seite hat, schickt sie es rüber. Dabei ist egal, was vorher war, wann das letzte Paket geschickt wurde, usw. Ggf. muss dann noch ein Schlüsselaustausch gemacht werden, wenn die letzten Schlüssen abgelaufen sind.

Wenn aufgrund von NAT oder ähnlichen Mechanismen eine Seite der Verbindung nicht erreichbar ist, dann hat man das Problem, dass die Gegenseite kein Paket schicken kann, bevor sie nicht vom NAT-Partner ein Paket empfangen hat. Dafür gibt es dann auch die Keep-Alive Pakete. Aber das ist unabhängig vom Verbindungsstatus, Server oder Client Rollen.

Ein weiteres Problem sind sich ändernde IP-Adressen während einer laufenden Verbindung. Wireguard aktualisiert nämlich keine Adressen von Kommunikationspartnern zur Laufzeit. Da muss man mit externen Scripten nachhelfen, wenn man das Problem hat.

Ich glaube so allgemein kann man das mit Wireguard nicht beschreiben.

Ich habe in meinem Szenario einen VPS, der als zentraler Server für die Clients dient.

Bedeutet, die Konfiguration des Servers besitzt ein Interface und die entsprechenden Peers der Clients (Handy z.B.).

Diese Peers haben aber auf dem VPS keine Angabe eines Endpoints.

Bedeutet, der VPS kann von sich aus keine Verbindung zu einem Client aufbauen.

Bei den Clients ist in der Konfiguration wiederum als Endpoint der VPS eingetragen und auch das KeepAlive ist auf der Seite des Clients konfiguriert.

Dieser Aufbau bereitet auch keine Probleme bei einem IP Wechsel der Clients, der Tunnel bleibt trotzdem bestehen.

Lediglich die IP Adresse des VPS darf sich nicht ändern.

Du scheinst da ein anderes Szenario aufgebaut zu haben, da es sich bei dir anders verhält.

Man kann Wireguard aber effektiv auch in einem Client Server Setup aufsetzen.

Ich denke, wir reden von unterschiedlichen Dingen. Um es kurz zu erklären was ich meine: Mein Fritzbox WG kann mein Handy mit WG nicht aktiv erreichen, die Initiale Verbindung muss ich mit dem Handy initiieren.

Es gibt also immer mind. einen Initiator. Das ist das Gerät, welches das erste Paket sendet. Die Gegenseite ist der Responder.

Ich denke, das ist das, was viele (fälschlicherweise) als Server (Responder) und Client (Initiator) meinen.

Wireguard selbst beschreibt die beiden Stellen als Initiator und Responder.

Die Funktionalität ist bei mir genau so wie von dir beschrieben, gerne kann man auch Server und Client durch Responder und Initiator ersetzen.

Zitat von EndoMorph

Die Funktionalität ist bei mir genau so wie von dir beschrieben, gerne kann man auch Server und Client durch Responder und Initiator ersetzen.

Ja, meine Antwort bezog sich auf die letzte Nachricht von frank_m, nicht auf deine, da kam nur deine dazischen

Um es noch einmal sehr deutlich zu sagen: Technisch gibt es bei Wireguard weder Server noch Client, weder Initiator noch Responder. Die Rollen sind NICHT fest verteilt, jede Seite kann bei Bedarf jede Rolle übernehmen. Natürlich könnt ihr durch euer Setup Konstellationen erzeugen, dass es einen zentralen Knoten gibt, der alle Clients (Netze und Road-Warrior) miteinander verbindet. Es ist auch denkbar, dass es eine Seite das erste Paket senden MUSS, weil die Gegenseite die Adresse nicht kennt.

Das ist aber eher ein Problem, als ein Feature, denn bedenkt: Das betrifft nicht nur den initialen Verbindungs-Aufbau, sondern auch laufende Verbindungen. Der zustandslose Charakter der Wireguard Verbindung kann nach verhältnismäßig kurzer Zeit dazu führen, dass ein mobiles Endgerät den Tunnel zum "Server" verliert, besonders, wenn das mobile Endgerät wirklich mobil ist (spätestens, wenn sich die abgehende IP-Adresse im NAT ändert). Solche Dinge muss man beim Design eines Wireguard Netzes auf dem Schirm haben. Und da macht es wenig Sinn, in den althergebrachten Rollen von Server zu Client zu denken, wenn die reale Technologie diese Rollen so nicht abbildet.

Zitat von frank_m

Um es noch einmal sehr deutlich zu sagen:

Der Ton gefällt mir nicht, ich bin deshalb hier raus.

Ich bin überzeugt, es liest sich ggf. anders als es tatsächlich gemeint war .