[Frage] FB Wireguard - PIVPN

Code:
#in die Fritzbox zu importieren, IP der Fritzbox 192.168.22.1:
#--------------------------------------------------------------------------------------------------------
#wg_config.conf
[Interface]
PrivateKey = Privatekeyderfritzbox
ListenPort = 56714
Address = 192.168.22.1/24
DNS = 192.168.22.1,192.168.11.1
DNS = fritz.box

#Pivpn
[Peer]
PublicKey = Publickeyvomraspberry
PresharedKey = vonderfritzboxerstellterkey
AllowedIPs = 192.168.11.0/24
Endpoint = xxx.dynv6.net:51902
PersistentKeepalive = 25
#-------------------------------------------------------------------------------------------------------

#Konfigdatei Pivpn, IP des Raspberry 192.168.11.66, Wireguard-Netz 192.168.20.0/24:
#-------------------------------------------------------------------------------------------------------
#wg0.conf
[Interface]
PrivateKey = Privatekeydesraspberry
Address = 192.168.20.2/24
MTU = 1300
ListenPort = 51902

# 7520
[Peer]
PublicKey = Publickeyderfritzbox
PresharedKey = vonderfritzboxerstellterkey
AllowedIPs = 192.168.22.0/24
#------------------------------------------------------------------------------------------------------
#zusätzlich habe ich im Router an dem Pivpn hängt die statischen Routen gesetzt:
#
#192.168.20.0  255.255.255.0  192.168.11.66 (könnte hier nicht nötig sein, brauche ich aber für die anderen Peers)
#
#192.168.22.0  255.255.255.0  192.168.11.66
Man muß nach dem Import in die Fritzbox die Konfig wieder anzeigen, weil der Listen Port nicht übernommen wird und man ggf. diesen in der Pivpn-Konfig anpassen muß. Bei mir ist nur einseitig die Einwahl möglich, weil die 7520 über Mobilfunk eingewählt ist und selber von außen nicht erreicht werden kann.
Folgende Daten sind vielleicht wichtig: Router vorm Pivpn 192.168.11.1, Raspberry 192.168.11.66, einwählende 7520 192.168.22.1, Pivpn-Wireguard 192.168.20.2
 
Zuletzt bearbeitet:
So nach gefühlt 10 Tagen, hat es endlich geklappt. Vielen Dank an alle. Ich war echt schon kurz vor dem verzweifeln. :)

Edit: zu früh gefreut. Die Verbindung und die Routen stehen, aber ich kann das entfernte Netzwerk nicht anpingen, oder die FB Seite öffnen. Muss ich irgendwo noch was einstellen?
 
Zuletzt bearbeitet:
Welche Seite welcher Fritzbox? Welches ist das entfernte Netz?

Wie ich die Einstellungen bei der Pivpn-Installation gesetzt hatte, weiß ich momentan gerade nicht mehr. Dort ist aber kein Routing konfiguriert, was Du ja ggf. bei vorherigen Tests eingerichtet hast.
 
Also ich Pinge 10.0.2.x (in diesem Fall 10.0.2.1 (Fritzbox)) und bekomme keine Antwort. Ich musste aber nichts großartig bei PiVPN konfigurieren, bis auf die IP Adresse, DNS und Dyndns.
 
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:


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):
  1. sudo apt-get install wireguard
  2. Kopieren der vom FRITZ!OS erzeugten Konfigurationsdatei nach /etc/wireguard/fritzbox.conf
  3. sudo systemctl enable [email protected]
  4. 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.
 
Zuletzt bearbeitet:
So sieht die Config der FB aus:
Code:
[Interface]
PrivateKey = Privatkeyderfritzbox
Address = 10.0.2.1/24
ListenPort = 53729
DNS = 10.0.2.1
DNS = fritz.box

[Peer]
PublicKey = PublickeydesPivpn
PresharedKey = rY6DFVcVIIsJ0Ew3Vj9cgOyVqMHYebWvnOmQ2CfH/1Q=
AllowedIPs = 10.0.4.1/24
Endpoint = pivpn.dyn.dns:51902
PersistentKeepalive = 25

Und so die vom PIVPN
Code:
[Interface]
PrivateKey = PrivatkeyvomPIVPN
Address = 10.0.10.1/24
MTU = 1420
ListenPort = 51902

[Peer]
PublicKey = PublickeyderFritzbox
PresharedKey = rY6DFVcVIIsJ0Ew3Vj9cgOyVqMHYebWvnOmQ2CfH/1Q=
AllowedIPs = 10.0.2.0/24
Endpoint = fb.dyn.dns:56481

Sonst habe ich nichts umgeändert.
 
Nach meiner Ansicht (und nach meinem Verständnis) passen die Kombinationen der IP-Adressen aus den Interface- (hier im Parameter Address) und den Peer-Abschnitten (hier der jeweilige Eintrag bei AllowedIPs) der Konfigurationsdateien gar nicht zusammen und wenn da tatsächlich Daten über den Tunnel übertragen werden können, dürfte das zu einem guten Teil reines Glück sein (das kann man nicht wirklich wissen, ohne die übertragenen Daten zu kennen).

EDIT: Und ein Verbindungsaufbau durch die PiVPN-Installation dürfte ebenfalls daran scheitern, daß die Portnummer bei der Endpoint-Angabe (56481) nicht zum Port bei ListenPort in der FRITZ!Box paßt.
 
Zuletzt bearbeitet:
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.
Richtig. Ich habe Pivpn nur für die Installation verwendet, weil ich den Raspi in ein bestehendes Netzwerk einbinden wollte, genauer gesagt einen openWRT-Clienten durch den Raspi ersetzen wollte. Deshalb habe ich auch die Konfigurationsschritte nicht mit Pivpn durchgeführt, sondern die wg0.conf auf dem Raspberry meinen Erfordernissen entsprechend bearbeitet. Dasselbe habe ich auch mit der Fritzbox versucht, die aber beim Import etwas eigensinnig ist. Man kann aber die Konfiguration der Fritzbox exportieren, dann die Verbindung in der Fritzbox löschen, die wg_config.conf bearbeiten und die angepasste Fritzbox-Konfiguration wieder importieren. Danach einen Neustart nicht vergessen.

Dass der Raspberry bei mir selber keine Verbindung aufbauen kann, weil die Fritzbox mit ihrem Mobilfunkstick keine öffentliche Adresse hat, habe ich oben schon beschrieben. Die Fritzbox aber findet den Raspberry und hält die Verbindung offen.

@lil-ac: Die Ports (auf die die Fritzbox hört und die der Pi sucht) passen in Deiner Konfiguration nicht. Beachte, dass Du den von der Fritzbox verwendeten Port dort nach dem Import noch raussuchen mußt, weil die den nicht aus der Importdatei übernimmt. Die IP-Adressen stimmen auch nicht, aber weil wir Deine IP-Bereiche nicht kennen kann ich das nicht korrigieren. 10.0.4.1/24 ist auf jeden Fall falsch, da könnte höchstens 10.0.4.0/24 hingehören, falls der Raspi eine IP aus diesem Netz hat.

Ok, aber die FB hat die 10.0.2.x und das PiVPN Netzwerk hat die 10.0.1.x.
Wenn das noch stimmt, müßtest Du es so schreiben:
Code:
#Fritzbox
[Interface]
PrivateKey = Privatkeyderfritzbox
Address = 10.0.2.1/24
ListenPort = 53729
DNS = 10.0.2.1,10.0.1.1
DNS = fritz.box

[Peer]
PublicKey = PublickeydesPivpn
PresharedKey = rY6DFVcVIIsJ0Ew3Vj9cgOyVqMHYebWvnOmQ2CfH/1Q=
AllowedIPs = 10.0.1.0/24
Endpoint = pivpn.dyn.dns:51902
PersistentKeepalive = 25

#PIVPN
[Interface]
PrivateKey = PrivatkeyvomPIVPN
Address = 10.0.10.1/24
MTU = 1420
ListenPort = 51902

[Peer]
PublicKey = PublickeyderFritzbox
PresharedKey = rY6DFVcVIIsJ0Ew3Vj9cgOyVqMHYebWvnOmQ2CfH/1Q=
AllowedIPs = 10.0.2.0/24
Endpoint = fb.dyn.dns:53729
 
Zuletzt bearbeitet:
sondern die wg0.conf auf dem Raspberry meinen Erfordernissen entsprechend bearbeitet.
Das war/ist ja Dein gutes Recht ... nur hat das eben für ordentlich Verwirrung in diesem Thread gesorgt - zumindest bei mir selbst.

Wenn man sich die Konfiguration von @lil-ac aus #6 ansieht, ist das dort ja EINDEUTIG eine Konfiguration (die zweite aus der PiVPN-Installation), die mit ebendiesem Projekt erzeugt wurde und ausgehend vom Titel des gesamten Threads "FB Wireguard - PIVPN" würde man jetzt sicherlich auch eher erwarten, daß hier PiVPN eben nicht nur zur Installation verwendet wurde (außer der von mir oben gezeigten (Nach-)Installation des wireguard-Pakets ist alles weitere ohnehin nur noch für die eigene Verwendung durch die Skript-Dateien von PiVPN erforderlich - und wenn man diese Skripte gar nicht nutzt, braucht man auch diese ganze Software nicht auf dem Pi), sondern auch für die Konfiguration von Verbindungen, was man ja auch schon in #6 sehen konnte.

Der ganze andere Schnickschnack, der da von PiVPN noch angeboten wird (eben bis hin zum Einrichten von iptables für das Masquerading beim Start einer Verbindung für einen "Client"), macht erst dann wieder (etwas) Sinn, wenn man da eine Sterntopologie o.ä. (mit der PiVPN-Installation als "Einwahlserver" für mehrere Clients, die auch noch jeweils wechselseitig in die LAN-Segmente zugreifen sollen) aufbauen will. Schon dann, wenn der Pi eigentlich nur als "access server" dienen soll und als Gateway ins Internet, braucht es diese Features nur noch, wenn da noch irgendwo eine Firewall kommt, die ihrerseits viel zu tief in Pakete hineinschaut und sich dann wundert, wieso da Absender-Adressen auftauchen, die doch gar nicht "lokal" sind.



Ich bin zwar nur "versehentlich" überhaupt in diesem Thread gelandet - aber ich kann die Verwirrung, die wohl auch bei @lil-ac entstanden ist, schon irgendwo nachvollziehen, wenn mit keinem Wort erwähnt wird, daß auch dabei dann schon alles OHNE die Nutzung des pivpn-Kommandos konfiguriert wurde und danach dann - zumindest mit der gezeigten Konfiguration in #5 - JEDE weitere Verwendung der Skript-Files aus dem PiVPN-Projekt nur noch Probleme bringen wird.

Ich habe zwar auch Deine Eingangsbemerkung:
Und bei PIVPN nicht die Peers einrichten, sondern manuell in die wg.conf schreiben.
gelesen, aber SO dann eben doch nicht verstanden, denn zwischen "bei PiVPN nicht die Peers einrichten" und "nicht MIT PiVPN die Peers einrichten" (und zwar NIE WIEDER) bestünde auch für mich noch ein Unterschied und die (einzige eingerichtete) Datei für ein WireGuard®-Interface heißt meines Wissens auch wg0.conf bei PiVPN.

Die vom FRITZ!OS exportierte Datei hat dann als "Angebot" beim Download auch den Namen wg_config.conf (also auch nicht wg.conf - so daß darüber keine eindeutige Zuordnung möglich war, was nun von wo nach wo zu übertragen wäre) und genau deshalb sollte man sie auch gleich umbenennen, wenn man die Konfigurationsdatei der FRITZ!Box auf seinem RaspberryPi speichert (und mit einem zusätzlichen WireGuard®-Interface arbeiten möchte).



Ich werde als Nächstes dann mal testen, ob man tatsächlich die Konfigurationsdatei aus der FRITZ!Box (für den Peer) nehmen und in dieser nachträglich eine weitere (LAN-LAN-)Verbindung eintragen lassen kann - dann wäre DAS auch wieder ein Weg, den man bei eigener WireGuard®-Konfiguration auf dem Pi (oder auf jedem anderen Linux-Host) gehen könnte, um sich durch das FRITZ!OS eine neue Verbindung zu einer (weiteren) Box zur existierenden Konfiguration auf dem Pi hinzufügen zu lassen (dann muß man natürlich die von der FRITZ!Box geänderte Konfiguration auch wieder auf den Pi bringen). Wie weit das dann bei den AllowedIPs noch paßt und ob sich das FRITZ!OS dafür die Angaben zu bereits vorhandenen Peers aus der Konfiguration heraussucht, dürfte auch spannend sein, wenn man davon ausgeht, daß weitere Netze hinter dieser einen (neuen) WireGuard®-Verbindung existieren und ggf. auch "erschlossen" werden sollen.

Nun ist das bei AVM ja noch ziemlich neu mit der Konfiguration von WireGuard®-Verbindungen - warten wir mal ab, was da von AVM-Seite noch an praktischen Tipps und/oder Anleitungen kommt.
 
Genau AVM ist dabei ein Problem. Deren abgespeckte Wireguard-Implementierung ist so richtig nur mit einer anderen Fritzbox kompatibel. So fehlt z.B. ein eigenes Wireguard-Netz. Eine anderswo erstellte Konfiguration läßt sich nicht einfach für eine Fritzbox übernehmen. Auch kann man die Konfiguration der Fritzbox nur auf Umwegen bearbeiten, und welche Parameter dabei übernommen werden, muß man jedesmal austesten. Deshalb ist es einfacher, die Konfiguration der Fritzbox nicht erneut anzufassen und lieber die Raspberry-Konfiguration anzupassen.

Mein Versehen, mit wg.conf war natürlich die wg0.conf gemeint. Das habe ich beim ersten Beispiel dann gemerkt. Zitat:
hier mal meine wg0.conf
 
Deren abgespeckte Wireguard-Implementierung ist so richtig nur mit einer anderen Fritzbox kompatibel.
Das sehe ich nicht ganz so - die Konfigurationen für "Einzelgeräte" sind sogar so simpel (und zielführend), daß die allermeisten Benutzer direkt nach dem Scannen des QR-Codes mit diesen Geräten dann auch sofort loslegen können.

Und wenn sich AVM beim Konfigurieren von LAN-LAN-Verbindungen zunächst mal auf die Verbindung zwischen den eigenen Geräten konzentriert, ist das in meinen Augen ebenfalls mehr als verständlich - mit einer erfolgreich eingerichteten Verbindung hat man nämlich (auf einen Schlag) gleich ZWEI Kunden mit AVM-Gerätschaften zufrieden gestellt.

Wenn dann andere WireGuard®-Installationen vielleicht etwas schlechter unterstützt werden, dann ist das auch der gesamten Architektur des FRITZ!OS geschuldet ... denn anders als im "normalen" Linux hängt eben auch HIER der gesamte VPN-Kram wieder hinter dem dev dsl und wird erst von dort im Bedarfsfall wieder auf dev wg0 geroutet, wie Du Dir anhand der Routing-Table problemlos ansehen kannst (auch ohne Shell-Zugriff steht die in den Support-Daten):
Rich (BBCode):
# ip route show
default dev dsl scope link metric 2
169.254.0.0/16 dev lan proto kernel scope link src 169.254.1.1
192.168.128.254 dev dsl proto 105 metric 2
192.168.132.0/24 dev lan proto kernel scope link src 192.168.132.1
192.168.132.1 dev dsl proto 103 metric 4
192.168.134.0/24 dev dsl proto 106 metric 2
192.168.168.0/24 dev dsl proto 103 metric 2
192.168.180.1 dev dsl scope link metric 2
192.168.180.2 dev dsl scope link metric 2
192.168.189.0/24 dev guest proto kernel scope link src 192.168.189.1 linkdown
#
Das Segment 192.168.134.0/24 ist das aus meinen Beispielen weiter oben - wie man sieht, geht die Route hier nach dev dsl und das war bei AVM auch bei IPSec-VPN schon immer so. Nur auf diesem Weg sind auch die ganzen anderen Features einer FRITZ!Box, wie die Internet-Filter oder die (AVM-)Firewall, ebenfalls für WireGuard®-Verbindungen verfügbar.

Ich würde das also eher als "anders" ansehen, aber nicht als "abgespeckt" und daß es im FRITZ!OS keine iptables gibt, sondern nur die Internet-Filterung auf dem AVM-(WAN-)Stack, ist auch keine wirkliche Neuigkeit. Daß auch andere "Paketlösungen" nicht wirklich ALLE Fälle berücksichtigen können, hast Du selbst offenbar schon vor längerer Zeit bemerkt, wenn Du gar nicht mehr auf die Dienste von pivpn zurückgreifen willst.

Wenn man WIRKLICH will, kann man auch im FRITZ!OS noch nachträgliche Änderungen an VPN-Verbindungen vornehmen - nur welcher "normale Kunde" würde das machen wollen und vor allem, wie groß sind dabei wieder die Möglichkeiten, falsche Einstellungen zu erzeugen, die dann am Ende - wenn's ganz schlecht läuft - sogar die Sicherheit des gesamten Routers gefährden. Da verstehe ich auch AVM wieder, wenn man beim Import "fremder" Konfigurationen gerne etwas genauer prüfen möchte, ob die tatsächlich korrekt sind oder nicht und sie im Zweifel dann auch ablehnt, anstatt sie kommentarlos zu schlucken.

Diejenigen, die dann doch den steinigen Weg über den Export, das Ändern in der vpn.cfg und (nach dem Neuberechnen der Prüfsumme am Ende der Datei) den anschließenden Import der Konfiguration gehen wollen (vermutlich kann man sich dabei sogar auf die selektive Übernahme von Einstellungen verlegen), KÖNNEN das ja immer noch machen - nur eben nicht mehr auf einem Weg, wo dann AVM irgendwie in der Pflicht wäre, das "benutzerfreundlich" zu gestalten und nur noch sichere Konfigurationen möglich zu machen.

Und nicht zuletzt habe ich (denke ich jedenfalls) oben auch gezeigt, daß von der AVM-Seite DURCHAUS auch brauchbare Konfigurationen erzeugt werden, die man - sofern man eine "leere" WireGuard®-Installation hat auf dem Peer, ansonsten ist der "Nein/Nein/WireGuard®-fähiger Router"-Weg auch der falsche bei der Konfiguration im FRITZ!OS - PROBLEMLOS für ein Linux-System übernehmen kann. Das muß ja noch nicht heißen, daß dabei alles bereits perfekt konfiguriert wurde - aber es ist in jedem Falle erst einmal funktionsfähig und das auch OHNE ein Transitnetz (was AVM bei IPSec ja auch nicht braucht und die meisten wohl ohnehin nur von OpenVPN kennen dürften - wenn überhaupt).
 
Ok, Du hast natürlich Recht. AVMs Wireguard ist für deren Anwendungen gut und, wie man es von AVM kennt, einfach einzurichten. Probleme hat man, wenn man ohne tiefere Kenntnisse Verbindungen zu anderen Lösungen, die auch wieder Assistenten oder Routinen mitbringen, einrichten will.

Deshalb mein Vorschlag, auf fremde Assistenten zu verzichten und die Fritzbox machen zu lassen. Die dort für den Peer (normalerweise eine andere Fritzbox) erzeugte xxx.conf enthält alle Angaben, die man braucht, um die wg0.conf einer Pivpn-Installation zu erstellen bzw. passend zu ändern. Will man eine Fritzbox aber in ein schon bestehendes Netz einbinden, bleibt nur der Export der erstellten Konfiguration (Nicht die .export, sondern die wg_config.conf) um dort die Keys anzupassen und dann erneut zu importieren. Dabei ändert die Fritz willkürlich den genutzten Port, was die Sache etwas erschwert, aber nicht unmöglich macht.

Edit: @lil-ac hast Du etwa aufgegeben?
 
Hey, gerade ja. Muss aus privat gesundheitlichen Gründen, dass Projekt zurückstellen.
Aber danke trotzdem für eure Hilfe erstmal.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.