Soo ... nun noch einmal in Ruhe und mit System.
Das Problem bei einer LAN-LAN-Kopplung zwischen einer FRITZ!Box und einer Installation auf Basis von PiVPN über WireGuard®-Verbindungen ist es im Grunde genommen, daß jeder der beiden Peers sich für "tonangebend" hält und das, obwohl beide unterschiedliche Konzepte hinsichtlich der Konfiguration der Interfaces verfolgen.
PiVPN konfiguriert sich ein Interface
wg0 mit einem eigenen Transportnetz und benutzt dann
iptables, um eingehende Datenpakete so zu transformieren (NAT/Masquerading), daß die Antwortpakete, die nach der Weiterleitung ins LAN auf dieser Seite der Verbindung von den "angeschriebenen" Host kommen, auch auf dem Rückweg wieder die PiVPN-Installation passieren müssen, wo die Zieladressen der Antworten dann wieder in die des ursprünglichen Absenders eines Pakets (bzw. "Requests") umgewandelt werden.
Rich (BBCode):
pi@pi4:~ $ sudo pivpn clients
[2023-02-07T14:08:28+0100]: ::: There are no clients to list
pi@pi4:~ $ sudo cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = GDkmK14hVhQ9LoG6NwF1prUTOYj6M7ddfYSXwPwZYlc=
Address = 10.28.248.1/24
MTU = 1420
ListenPort = 51820
pi@pi4:~ $ sudo sed -n -e "s|^PrivateKey = \([A-Za-z0-9/+=]*\).*|\1|p" /etc/wireguard/wg0.conf | tee /proc/self/fd/2 | wg pubkey
GDkmK14hVhQ9LoG6NwF1prUTOYj6M7ddfYSXwPwZYlc=
04OwYGmC6mvyOV7XEaldxmx17xdwe1RhZXRXfCAdPlo=
pi@pi4:~ $
Bisher sind keine Clients in PiVPN definiert, das Interface
wg0 (denn das ist der Name der Konfigurationsdatei -> daraus leitet WireGuard® auch den Interface-Namen ab) hat ein Transportnetz mit dem Segment
10.28.248.0/24 definiert und darin für sich selbst die Adresse vorgesehen, die im letzten Tupel die
1 hat.
Andere Peers, die über dieses Interface mit dem Gerät, auf dem PiVPN läuft (nennen wir es mal "Server"), kommunizieren wollen, müssen den zum verwendeten
PrivateKey (blau markiert) passenden
PublicKey (rot markiert) in einem separaten
Peer-Abschnitt ihrer Konfiguration haben. Den Rest (die MTU und auch den Port) ignorieren wir erst einmal, das hat nichts mit den unterschiedlichen Ansichten des FRITZ!OS und von PiVPN zu tun.
Fügt man jetzt im PiVPN einen "Client" hinzu, sieht das zunächst mal so aus:
Rich (BBCode):
pi@pi4:~ $ sudo pivpn add -n FB7590
::: Client Keys generated
::: Client config generated
::: Updated server config
::: WireGuard reloaded
======================================================================
::: Done! FB7590.conf successfully created!
::: FB7590.conf was copied to /home/pi/configs for easytransfer.
::: Please use this profile only on one device and create additional
::: profiles for other devices. You can also use pivpn -qr
::: to generate a QR Code you can scan with the mobile app.
======================================================================
pi@pi4:~ $
So weit, so gut ... nur was hat(te) das jetzt für Auswirkungen auf die Konfiguration und welche Dateien wurden hier für den "Client" erzeugt?
Rich (BBCode):
pi@pi4:~ $ sudo pivpn clients
::: Connected Clients List :::
Name Remote IP Virtual IP Bytes Received Bytes Sent Last Seen
FB7590 (none) 10.28.248.2 0B 0B (not yet)
::: Disabled clients :::
pi@pi4:~ $ sudo cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = GDkmK14hVhQ9LoG6NwF1prUTOYj6M7ddfYSXwPwZYlc=
Address = 10.28.248.1/24
MTU = 1420
ListenPort = 51820
### begin FB7590 ###
[Peer]
PublicKey = irSyJSohlhUafs9hN2+5DnJC/1GVDs/VAxx08Mj7yEA=
PresharedKey = A0wgzF2cdnyI3sFL+ip+Io4aI1lycnRByce9AUkDnxw=
AllowedIPs = 10.28.248.2/32
### end FB7590 ###
pi@pi4:~ $ sudo cat /etc/wireguard/configs/FB7590.conf
[Interface]
PrivateKey = YNfxPLXftIWDvl/PLth0rDY0W4iDWJHr65Mj42c7AGA=
Address = 10.28.248.2/24
DNS = 192.168.168.254
[Peer]
PublicKey = 04OwYGmC6mvyOV7XEaldxmx17xdwe1RhZXRXfCAdPlo=
PresharedKey = A0wgzF2cdnyI3sFL+ip+Io4aI1lycnRByce9AUkDnxw=
Endpoint = pivpn.home.domain.de:51820
AllowedIPs = 0.0.0.0/0, ::0/0
pi@pi4:~ $ sudo ip route show
default via 192.168.168.254 dev eth0
default via 192.168.168.254 dev eth0 proto dhcp src 192.168.168.236 metric 202
10.28.248.0/24 dev wg0 proto kernel scope link src 10.28.248.1
192.168.128.254 via 192.168.168.254 dev eth0
192.168.168.0/24 dev eth0 proto dhcp scope link src 192.168.168.236 metric 202
192.168.168.254 dev eth0 scope link
pi@pi4:~ $ sudo iptables-save
# Generated by iptables-save v1.8.7 on Tue Feb 7 15:51:32 2023
*nat
:PREROUTING ACCEPT [405:76532]
:INPUT ACCEPT [173:23875]
:OUTPUT ACCEPT [137:10628]
:POSTROUTING ACCEPT [137:10628]
-A POSTROUTING -s 10.28.248.0/24 -o eth0 -m comment --comment wireguard-nat-rule -j MASQUERADE
COMMIT
# Completed on Tue Feb 7 15:51:32 2023
# Warning: iptables-legacy tables present, use iptables-legacy-save to see them
pi@pi4:~ $ sudo wg show
interface: wg0
public key: 04OwYGmC6mvyOV7XEaldxmx17xdwe1RhZXRXfCAdPlo=
private key: (hidden)
listening port: 51820
peer: irSyJSohlhUafs9hN2+5DnJC/1GVDs/VAxx08Mj7yEA=
preshared key: (hidden)
allowed ips: 10.28.248.2/32
pi@pi4:~ $
Es wurde also ein neuer Peer (als "Client") mit Namen
FB7590 eingerichtet, der als Host im Transportnetz die Adresse 10.28.248.2 verwenden soll und im Übrigen dann per Masquerading die Adressen aus dem entfernten Netzwerk "verstecken" und durch die eigene IP als Absender ersetzen soll.
In der Konfigurationsdatei FÜR diesen Peer wird aber mit dem
AllowedIPs-Eintrag festgelegt, daß JEDER Traffic über das dort einzurichtende WireGuard®-Interface an den Peer (also die PiVPN-Installation) zu übertragen ist. DAS ist vermutlich auch der Punkt, an dem das FRITZ!OS so nicht mitspielen will.
Denn schaut man sich das jetzt auf der Seite des FRITZ!OS an (ich benutze dazu meine 7590, die ich ohnehin nur für Software-Entwicklung und -Tests brauche - für das unten Kommende braucht man schon einen Shell-Zugang), sieht das deutlich anders aus.
Rich (BBCode):
# cat /var/media/ftp/YourFritz/getsect
#! /bin/sh
[ -z "$2" ] && printf "Usage: $0 <section> <file>\n" && exit 1
file="$2"
section="$1"
fl="$(sed -n -e "/^[[:space:]]*$section[[:space:]]{\$/=" <"$file")"
[ -z "$fl" ] && printf "'%s' not found.\n\a" "$section" 1>&2 && exit 1
sp="$(sed -n -e "${fl}s|^\([[:space:]]*\)$section.*|\1|p" <"$file")"
pl=$(( fl - 1 ))
ll="$(sed -e "1,${pl}d" <"$file" | sed -n -e "/^${sp}}/=" | sed -n -e 1p)"
[ -z "$ll" ] && printf "Format error in '%s'.\n\a" "$file" 1>&2 && exit 1
ll=$(( ll + pl ))
sed -n -e "${fl},${ll}p" <"$file"
# sh /var/media/ftp/YourFritz/getsect global /var/flash/vpn.cfg
global {
wg_listen_port = 0;
}
#
Das verwendete getsect ist also nur ein kleines Skript zur Anzeige von Teilen einer Konfigurationsdatei - damit muß man nicht immer erst davor oder dahinter löschen und sogar beim Namen (der eigentlich für get section stehen soll) habe ich "gespart".
Wie man sieht, hat die FRITZ!Box noch gar keine Konfiguration für ihr eigenes WireGuard®-Interface - und sie löscht diese Einstellungen auch immer wieder, wenn die letzte konfigurierte Verbindung entfernt wurde. Man kann also nicht einfach in der FRITZ!Box die letzte Verbindung entfernen und danach dennoch weiterhin den bisher funktionierenden PublicKey der FRITZ!Box in irgendwelchen Konfigurationen auf Peers verwenden.
Mit der ersten Konfiguration einer WireGuard®-Verbindung richtet die FRITZ!Box neue Einstellungen für ihr eigenes
wg0-Interface ein.
Rich (BBCode):
[Interface]
PrivateKey = 6Fw1lHvxGCplChfRSyq+olEkPYEOwMUCfx4lggvxSGc=
ListenPort = 54388
Address = 192.168.132.1/24
DNS = 192.168.132.1,192.168.134.1
DNS = fritz.box
[Peer]
PublicKey = zppDEzKqVwnxpduTPBh/QB76snxRSrZ9RYP9xgmIdjU=
PresharedKey = keEbf+3sn16mPw46a3IB/oElzw3eq+rnbp1epqXQgJo=
AllowedIPs = 192.168.134.0/24
und die dazugehörige Konfiguration für den Peer ist:
Rich (BBCode):
[Interface]
PrivateKey = MPbXQ0pG2MauvgIaEjwfyVfM5bjkGPhZOWniVUd8g2U=
Address = 192.168.134.1/24
DNS = 192.168.132.2,192.168.132.1
DNS = fritz.box
[Peer]
PublicKey = Zywu+Vs2SGsN3yXqOWMGQY4vzCSyARjza2g1zW3vumw=
PresharedKey = keEbf+3sn16mPw46a3IB/oElzw3eq+rnbp1epqXQgJo=
AllowedIPs = 192.168.132.0/24
Endpoint = <masked>.myfritz.net:54388
PersistentKeepalive = 25
Löscht man jetzt diese (einzige) Verbindung wieder und legt dann eine neue an, ändern sich auch die eigenen Einstellungen der FRITZ!Box:
Rich (BBCode):
[Interface]
PrivateKey = UO4kioijzC7tWv/XTHYhsdTAJzb/KvBW3kx7revEB1E=
ListenPort = 57620
Address = 192.168.132.1/24
DNS = 192.168.132.1,192.168.134.1
DNS = fritz.box
[Peer]
PublicKey = XuvYh2yE6wZqFA6r0YpBTbFnlqiRJY/JWMcjyg6ZgEc=
PresharedKey = NVLnIqjHCHY5s8zHmuFm6sst6jPfpp38HopgGKgJZzs=
AllowedIPs = 192.168.134.0/24
PersistentKeepalive = 25
und die Konfiguration für
Peer2:
Rich (BBCode):
[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 = <masked>.myfritz.net:57620
PersistentKeepalive = 25
Das ist also auch ein Punkt, den man beim WireGuard® in der FRITZ!Box berücksichtigen muß: Löscht man die letzte konfigurierte Verbindung, generiert das FRITZ!OS beim Anlegen der nächsten Verbindung neue Einstellungen für das Interface. Will man das also vermeiden, muß man sich ggf. irgendeine Dummy-Verbindung einrichten, so daß die Einstellungen für das Interface ERHALTEN bleiben.
Intern sieht das dann so aus:
Rich (BBCode):
# sh /var/media/ftp/YourFritz/getsect global /var/flash/vpn.cfg
global {
wg_private_key = "$$$$LTMPJBBTB4AENMSI6ZN2242Z563IUDR21VZVMCZMOZF5VEDEGXJPI3CFJACSB1WRSP666YBLWEYN2GKUB43YWWZAAJ5CJ1J6RDMISTRKLIPTPSJLIVOWNCXID32VFSRM";
wg_public_key = "8mWDL0lqjHzGf8ThVp+8JoOKdB/FCq/08eqk7qZ5kSY=";
wg_listen_port = 57620;
}
# aicmd vpnd wireguard extended
Extended wireguard device:
Public-Key: 8mWDL0lqjHzGf8ThVp+8JoOKdB/FCq/08eqk7qZ5kSY=
Listen-Port: 57620
Domain-Name: fritz.box:
-------------------------------------------------------------------------------------------------------------------------------------------
Peer Meta
-------------------------------------------------------------------------------------------------------------------------------------------
Nr. Public-Key Allowed-IPs TX RX Hand Keep Name Imp State RT DNS Our
shake alive ort [s] Server DynDNS
-------------------------------------------------------------------------------------------------------------------------------------------
0 XuvYh2yE6wZqFA6 192.168.134.0/24 0.00 0.00 0 s 25 Peer2 (R) not 0 192.168.134.1 <masked>.
r0YpBTbFnlqiRJY KB KB active 0 myfritz.net
/JWMcjyg6ZgEc=
-------------------------------------------------------------------------------------------------------------------------------------------
(R) = Repaired, (A) = Added, (RA) = Re-added
# ip address show dev wg0
79: wg0: <POINTOPOINT,NOARP,PROMISC,UP,LOWER_UP> mtu 1392 qdisc noqueue state UNKNOWN group default qlen 1
link/none
inet 192.168.132.1/24 scope global wg0
valid_lft forever preferred_lft forever
# ip address show dev lan
13: lan: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 2c:91:ab:f7:ca:fe brd ff:ff:ff:ff:ff:ff
inet 192.168.132.1/24 brd 192.168.132.255 scope global lan
valid_lft forever preferred_lft forever
inet 169.254.1.1/16 brd 169.254.255.255 scope global lan:0
valid_lft forever preferred_lft forever
inet6 fd00::2e91:abff:fef7:cafe/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::2e91:abff:fef7:cafe/64 scope link
valid_lft forever preferred_lft forever
#
Hier wird also ein zusätzliches Interface (
wg0) mit derselben Adresse wie das LAN-Interface konfiguriert und es findet kein Masquerading der Pakete beim Peer statt (zumindest ist das die Ansicht der FRITZ!Box).
Mit diesen Erkenntnissen ausgerüstet, wäre es jetzt sogar schlauer, wenn man dafür sorgt, daß sich die beiden Philosophien nicht ins Gehege kommen können ... eine Option dafür wäre es, auf dem Gerät, wo auch die PiVPN-Installation erfolgte, einfach ein zweites Interface für die Verbindung zur FRITZ!Box zu verwenden. Dazu braucht man nur die von der FRITZ!Box erzeugte Konfigurationsdatei für den Peer auf der anderen Seite in das Verzeichnis
/etc/wireguard zu kopieren - der Name, den man der Datei dabei gibt, ist gleichzeitig der Name des Interfaces, was erzeugt wird, wenn man diese Verbindung dann aktivieren läßt (wie man die Konfigurationsdatei in das richtige Verzeichnis kriegt, sollte jeder wissen - und wenn nicht, sich "erarbeiten"):
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 = <masked>.myfritz.net:57620
Endpoint = 192.168.168.73:57620 # die WAN-Adresse der dev7590
PersistentKeepalive = 25
pi@pi4:~ $ wg-quick up fritzbox
[#] ip link add fritzbox type wireguard
[#] wg setconf fritzbox /dev/fd/63
[#] ip -4 address add 192.168.134.1/24 dev fritzbox
[#] ip link set mtu 1420 up dev fritzbox
[#] resolvconf -a fritzbox -m 0 -x
[#] ip -4 route add 192.168.132.0/24 dev fritzbox
pi@pi4:~ $ sudo wg show
interface: wg0
public key: 04OwYGmC6mvyOV7XEaldxmx17xdwe1RhZXRXfCAdPlo=
private key: (hidden)
listening port: 51820
peer: irSyJSohlhUafs9hN2+5DnJC/1GVDs/VAxx08Mj7yEA=
preshared key: (hidden)
allowed ips: 10.28.248.2/32
interface: fritzbox
public key: XuvYh2yE6wZqFA6r0YpBTbFnlqiRJY/JWMcjyg6ZgEc=
private key: (hidden)
listening port: 42689
peer: 8mWDL0lqjHzGf8ThVp+8JoOKdB/FCq/08eqk7qZ5kSY=
preshared key: (hidden)
endpoint: 192.168.168.73:57620
allowed ips: 192.168.132.0/24
latest handshake: 7 seconds ago
transfer: 124 B received, 180 B sent
persistent keepalive: every 25 seconds
pi@pi4:~ $ ip route show
default via 192.168.168.254 dev eth0
default via 192.168.168.254 dev eth0 proto dhcp src 192.168.168.236 metric 202
10.28.248.0/24 dev wg0 proto kernel scope link src 10.28.248.1
192.168.128.254 via 192.168.168.254 dev eth0
192.168.132.0/24 dev fritzbox scope link
192.168.134.0/24 dev fritzbox proto kernel scope link src 192.168.134.1
192.168.168.0/24 dev eth0 proto dhcp scope link src 192.168.168.236 metric 202
192.168.168.254 dev eth0 scope link
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.31 ms
64 bytes from 192.168.132.1: icmp_seq=2 ttl=64 time=2.26 ms
--- 192.168.132.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 2.258/2.282/2.307/0.024 ms
pi@pi4:~ $
Damit gibt es also ein weiteres Interface auf dem Gerät und wie man oben auch sehen kann, fließen tatsächlich Daten zwischen der FRITZ!Box und dem PiVPN. Die notwendigen Einträge in der Routing-Table wurden beim Start der Verbindung auch erzeugt. Ein
ping-Kommando ist auch erfolgreich (damit stimmt auch die Datenübertragung in BEIDE Richtungen) und auch zu anderen Hosts im Netz der FRITZ!Box sollte es keine Verbindungsprobleme geben (auch wenn das hier nur die Box selbst zeigt - es gibt keine Clients im LAN dieser Box, die ich zeigen könnte).
Das wäre also der simpelste Weg - aber er skaliert zugegebermaßen nicht sehr gut, wenn man noch weitere FRITZ!Boxen an das Gerät mit PiVPN anbinden will.
Ich mache hier erst einmal Schluß - vermutlich kriege ich nicht mal das bisher Geschriebene als einzelnen Beitrag ins Board und scheitere wieder am Zeichenlimit.
EDIT:
Nein ... hat doch geklappt. Fortsetzung folgt (irgendwann), bei der dann auch der Weg, wie die PiVPN-Installation tonangebend sein kann, thematisiert werden soll.
