So nach gefühlt 10 Tagen, hat es endlich geklappt.
Nett wäre es nun, wenn Du auch noch dazu schreibst, WIE GENAU Du vorgegangen bist und auch noch die (geänderten) Konfigurationen zeigst - dann haben spätere Leser auch noch etwas von Deinem Erfolg und obendrein sieht man vielleicht auch noch, wo Deine (fortbestehenden?) Probleme ihre Ursache haben.
Denn je mehr ich mich in das Thema "PiVPN" vertiefe, desto weniger kann ich glauben, daß die von
@erik gezeigten Konfigurationsausschnitte auch wirklich mittels PiVPN (in einer AKTUELLEN Version) erzeugt wurden (bzw. weiterhin verwaltet werden können) - zumindest nicht in einer stinknormalen (manuellen, dialoggeführten) Installation, sondern VIELLEICHT noch mit einer Installation unter Benutzung einer Datei für "unbeaufsichtigtes Setup" (Parameter
--unattended -> siehe hier:
https://docs.pivpn.io/install/ unter "Non-interactive installation").
Denn wie ich es auch drehe und wende ... überläßt man bei der Installation die Auswahl eines Transitnetzes dem Code, der PiVPN installiert, dann KANN das nur ein Transportnetz
10.x.y.0/24 werden (mit zufälligen Werten für
x und
y), wenn man folgende Stellen aus dem
install.sh-Skript betrachtet:
The Simplest VPN installer, designed for Raspberry Pi - pivpn/pivpn
github.com
The Simplest VPN installer, designed for Raspberry Pi - pivpn/pivpn
github.com
Wenn da also bei
@erik im
Interface-Abschnitt der Konfiguration für
wg0 auf dem Gerät, was (immer noch?) durch PiVPN verwaltet werden soll, ein Eintrag
Address mit dem Wert
192.168.20.2/24 steht, dann ist diese Installation entweder noch mit einer alten Version (vor diesem Commit:
https://github.com/pivpn/pivpn/commit/85b3e822745fc88bb58a514614d18fb2c4add19e - wobei die vorhergehende Version da wohl auch eher ein FESTES Transitnetz benutzen wollte:
https://github.com/pivpn/pivpn/blob...1a43ee818b9ea9b/auto_install/install.sh#L1097) erzeugt worden oder eben doch mit einer (woher auch immer stammenden) Konfigurationsdatei, in der andere Werte, als sie eine normale Installation vorsehen würde, verwendet wurden.
Dann paßt das alles aber nicht mehr zu aktuellen Installationen von PiVPN - oder man verwendet vom eigentlichen PiVPN-Projekt praktisch keine Funktionen mehr ... dann ist/war PiVPN aber auch nichts anderes mehr, als ein (vielleicht bequemer, aber auch überflüssiger) Weg, die notwendigen Pakete zu installieren auf seinem Raspbian oder auf welchem OS auch immer.
Ich würde sogar stark in Zweifel ziehen, daß die PiVPN-Skripte (konkret dieses:
https://github.com/pivpn/pivpn/blob/master/scripts/pivpn und die von diesem dann wiederum aufgerufenen) weiterhin mit einer Konfiguration mit dem gezeigten Aufbau funktionieren und solange man nicht auch noch die passenden Einträge für eigene Modifikationen an der
/etc/wireguard/wg0.conf in der PiVPN-Installtion ebenso in die
/etc/wireguard/configs/clients.txt einträgt, dürfte nicht einmal die Anzeige der Clients mit
pivpn list funktionieren und ein Aufruf von
pivpn clients (der geht dann wieder durch die Ausgaben der
wireguard-tools und die Konfigurationsdatei für das Interface) liefert ein abweichendes Ergebnis.
Alles nichts, was ich unter der Verwendung von PiVPN für die Konfiguration und Verwaltung von WireGuard®-Verbindungen verstehen würde ... das ist dann letztlich dasselbe, was ich oben für den Weg mit einem zweiten Interface gezeigt habe - nur wird hier dann halt schon das erste Interface "mißbraucht" (in dem Sinne, daß es nicht wirklich weiterhin mit PiVPN zu verwalten ist). Wofür braucht man hier dann überhaupt noch PiVPN?
Alles andere, was für die Verwendung von WireGuard® auf einem Raspberry Pi mit Raspbian erforderlich ist, erhält man üblicherweise schon über die Installation (mit dem Paket-Manager) des
wireguard-Pakets - inkl. der notwendigen Dateien für den Start aller Konfigurationen über den
systemd:
Rich (BBCode):
pi@pi4:~ $ sudo ls -l /lib/systemd/system/wg-quick*
ls: cannot access '/lib/systemd/system/wg-quick*': No such file or directory
pi@pi4:~ $ sudo apt-get install wireguard
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
wireguard-tools
The following NEW packages will be installed:
wireguard wireguard-tools
0 upgraded, 2 newly installed, 0 to remove and 3 not upgraded.
Need to get 8,164 B/86.3 kB of archives.
After this operation, 294 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://deb.debian.org/debian bullseye/main armhf wireguard all 1.0.20210223-1 [8,164 B]
Fetched 8,164 B in 1s (8,142 B/s)
Selecting previously unselected package wireguard-tools.
(Reading database ... 166780 files and directories currently installed.)
Preparing to unpack .../wireguard-tools_1.0.20210223-1_armhf.deb ...
Unpacking wireguard-tools (1.0.20210223-1) ...
Selecting previously unselected package wireguard.
Preparing to unpack .../wireguard_1.0.20210223-1_all.deb ...
Unpacking wireguard (1.0.20210223-1) ...
Setting up wireguard-tools (1.0.20210223-1) ...
wg-quick.target is a disabled or a static unit not running, not starting it.
Setting up wireguard (1.0.20210223-1) ...
Processing triggers for man-db (2.9.4-2) ...
pi@pi4:~ $ sudo ls -l /lib/systemd/system/wg-quick*
-rw-r--r-- 1 root root 755 Feb 25 2021 /lib/systemd/system/[email protected]
-rw-r--r-- 1 root root 53 Feb 25 2021 /lib/systemd/system/wg-quick.target
pi@pi4:~ $ sudo cat /lib/systemd/system/[email protected]
[Unit]
Description=WireGuard via wg-quick(8) for %I
After=network-online.target nss-lookup.target
Wants=network-online.target nss-lookup.target
PartOf=wg-quick.target
Documentation=man:wg-quick(8)
Documentation=man:wg(8)
Documentation=https://www.wireguard.com/
Documentation=https://www.wireguard.com/quickstart/
Documentation=https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
Documentation=https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/wg-quick up %i
ExecStop=/usr/bin/wg-quick down %i
ExecReload=/bin/bash -c 'exec /usr/bin/wg syncconf %i <(exec /usr/bin/wg-quick strip %i)'
Environment=WG_ENDPOINT_RESOLUTION_RETRIES=infinity
[Install]
WantedBy=multi-user.target
pi@pi4:~ $ sudo cat /lib/systemd/system/wg-quick.target
[Unit]
Description=WireGuard Tunnels via wg-quick(8)
pi@pi4:~ $
Der einfachere Weg (wenn man das OHNE PiVPN machen will - und ich sehe nicht, wie das Projekt bei
@erik noch in die VPN-Konfigurationen involviert sein soll) ist es dann also, auch hier einfach nur die von der FRITZ!Box erzeugte Konfigurationsdatei zu nehmen und (unter dem Namen, den man dem Interface geben will) in das Verzeichnis
/etc/wireguard zu kopieren.
Bei mir sieht diese Datei (weiter vorne stand sie schon einmal) jetzt so aus (nur die Einstellungen für
Endpoint wurden von mir angepaßt, weil ich hier KEINE Auflösung über den (vorher eingetragenen) DynDNS-Server des MyFRITZ!-Services will - ansonsten sind es 1:1 die Angaben, die von der FRITZ!Box in die Datei geschrieben wurden):
Rich (BBCode):
pi@pi4:~ $ sudo cat /etc/wireguard/fritzbox.conf
[Interface]
PrivateKey = sDsgHY4vqNggT4fNxpB8Nt3UqovsPtn3kdWRB0owSX8=
Address = 192.168.134.1/24
DNS = 192.168.132.2,192.168.132.1
DNS = fritz.box
[Peer]
PublicKey = 8mWDL0lqjHzGf8ThVp+8JoOKdB/FCq/08eqk7qZ5kSY=
PresharedKey = NVLnIqjHCHY5s8zHmuFm6sst6jPfpp38HopgGKgJZzs=
AllowedIPs = 192.168.132.0/24
#
# Endpoint ist der DynDNS-Name der Gegenstelle, also der FRITZ!Box, die diese Konfiguration erzeugt hat.
#
# Da das nur eine Demonstration innerhalb meines eigenen LAN ist (die Kommunikation erfolgt aber sowohl
# für den Pi als auch die 7590 über ein "externes Interface", also auf deren "WAN"-Seite), steht hier
# direkt die IP-Adresse der 7590 (auf deren WAN-Seite, denn intern verwendet die 7590 192.168.132.1/24
# und der Pi ist eigentlich gar kein Router, sondern hängt mit seinem Ethernet-Port in demselben Netz,
# wie die 7590 mit dem WAN-Port.
#
Endpoint = 192.168.168.73:57620
PersistentKeepalive = 25
pi@pi4:~ $
Jetzt noch den Service für das neue Interface aktivieren und starten und dann schauen wir nach, was nach dem Start passiert ist:
Rich (BBCode):
pi@pi4:~ $ sudo systemctl enable [email protected]
Created symlink /etc/systemd/system/multi-user.target.wants/[email protected] → /lib/systemd/system/[email protected].
pi@pi4:~ $ sudo systemctl start [email protected]
pi@pi4:~ $ sudo systemctl status [email protected]
● [email protected] - WireGuard via wg-quick(8) for fritzbox
Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2023-02-09 15:15:01 CET; 6s ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 3162 ExecStart=/usr/bin/wg-quick up fritzbox (code=exited, status=0/SUCCESS)
Main PID: 3162 (code=exited, status=0/SUCCESS)
CPU: 337ms
Feb 09 15:15:01 pi4 systemd[1]: Starting WireGuard via wg-quick(8) for fritzbox...
Feb 09 15:15:01 pi4 wg-quick[3162]: [#] ip link add fritzbox type wireguard
Feb 09 15:15:01 pi4 wg-quick[3162]: [#] wg setconf fritzbox /dev/fd/63
Feb 09 15:15:01 pi4 wg-quick[3162]: [#] ip -4 address add 192.168.134.1/24 dev fritzbox
Feb 09 15:15:01 pi4 wg-quick[3162]: [#] ip link set mtu 1420 up dev fritzbox
Feb 09 15:15:01 pi4 wg-quick[3189]: [#] resolvconf -a fritzbox -m 0 -x
Feb 09 15:15:01 pi4 wg-quick[3162]: [#] ip -4 route add 192.168.132.0/24 dev fritzbox
Feb 09 15:15:01 pi4 systemd[1]: Finished WireGuard via wg-quick(8) for fritzbox.
pi@pi4:~ $ sudo wg show
interface: fritzbox
public key: XuvYh2yE6wZqFA6r0YpBTbFnlqiRJY/JWMcjyg6ZgEc=
private key: (hidden)
listening port: 44861
peer: 8mWDL0lqjHzGf8ThVp+8JoOKdB/FCq/08eqk7qZ5kSY=
preshared key: (hidden)
endpoint: 192.168.168.73:57620
allowed ips: 192.168.132.0/24
latest handshake: 33 seconds ago
transfer: 156 B received, 180 B sent
persistent keepalive: every 25 seconds
pi@pi4:~ $ ping -c 2 192.168.132.1
PING 192.168.132.1 (192.168.132.1) 56(84) bytes of data.
64 bytes from 192.168.132.1: icmp_seq=1 ttl=64 time=2.51 ms
64 bytes from 192.168.132.1: icmp_seq=2 ttl=64 time=1.49 ms
--- 192.168.132.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.486/1.996/2.507/0.510 ms
pi@pi4:~ $
Mehr als diese vier Aktionen (der Übersichtlichkeit halber noch einmal gesondert aufgelistet):
sudo apt-get install wireguard- Kopieren der vom FRITZ!OS erzeugten Konfigurationsdatei nach
/etc/wireguard/fritzbox.conf
sudo systemctl enable [email protected]sudo systemctl start [email protected]
braucht es also gar nicht, um eine auf der FRITZ!Box konfigurierte LAN-LAN-Verbindung - über WireGuard® zu einem anderen Netzwerk - auf einem Raspberry Pi mit Raspbian (in meinem Fall:
Rich (BBCode):
pi@pi4:~ $ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
pi@pi4:~ $
) in Betrieb zu nehmen.
Alles andere, was einem PiVPN noch an "Drumherum" anbietet - vom NAT vom Transitnetz ins lokale bis zum Update für die Software-Pakete über den Paket-Manager - braucht es hier NICHT - erst wenn die Netzwerk-Konfigurationen dann etwas komplizierter werden, können solche Lösungen vielleicht wieder helfen. Wobei man auch da immer davon ausgehen sollte, daß nur die "Standardfälle" damit abgedeckt werden sollen und etwas ausgefeiltere Konfigurationen dennoch der Handarbeit bedürfen.
In der jeweiligen "Standardkonfiguration" beißen sich jedenfalls die Einstellungen des FRITZ!OS und einer PiVPN-Installation durchaus - solange die FRITZ!Box jetzt nicht (nach Änderung der Standardangabe bei
AllowedIPs in der von PiVPN erzeugten Konfiguration) eine solche Konfiguration doch noch beim Import akzeptiert, sieht es eben finster aus; vor allem auch deshalb, weil man beim FRITZ!OS eben KEINE Möglichkeit der nachträglichen Korrektur hat und immer mit Löschen und Neuanlegen arbeiten muß, wenn es um "trial & error" bei einer Fehlersuche geht.
Intern ist bei AVM da ohnehin einiges "verrutscht" - aber das ist ein anderes Thema und gehört mehr zu den "Innereien".
EDIT: Und das oben beschriebene Vorgehen funktioniert natürlich auch mit jedem anderen "jungfräulichen" (im Hinblick auf bereits vorhandene WireGuard®-Konfigurationen) Linux-System - solange das über den
systemd gestartet wird. Aber auch wenn da noch ein Systemstart über
init und Skripte in
/etc/init.d erfolgen sollte, ändert sich damit nur der Start der Verbindung(en). Selbst wenn ein System schon WireGuard®-Verbindungen verwenden sollte, bleibt immer noch die Option übrig, die Verbindung zu einer FRITZ!Box über ein eigens dafür gestartetes Interface herzustellen.
