Wiki source for WireGuard
===== VPNs mit WireGuard =====
== die schnelle Alternative zu alten VPN-Technologien ==
>>**gute Quellen**
- [[https://homenetworkguy.com/how-to/configure-wireguard-opnsense/ WG auf OPNsense step-by-step + sehr nützliche Hinweise]]
- [[https://docs.opnsense.org/index.html einwandfreie offizielle Dokumentation]]
>>
Eine Diskussion über Vor- und Nachteile dieses (auf jeden Fall spannenden) Projektes wird hier nicht geführt. Es hat auf jeden Fall einige Vorteile, die wir gern nutzen. Selbstverständlich muss man alles richtig einstellen, damit WireGuard
a) überhaupt funktioniert
a) keine Sicherheitslücken entstehen
((1)) WireGuard mit OPNsense
Die Beschreibung unter https://docs.opnsense.org/manual/how-tos/wireguard-client.html und auf den anderen OPNsense-Seiten zu WireGuard ist alles sehr gut beschrieben. Wenn man die Schritte befolgt, funktioniert alles in der Regel gut.
Einige Probleme mit DNS gab es dennoch:
((2)) Einwahl ins lokale LAN hinter OPNsense
Der Zugriff auf die Geräte hinter OPNsense funktioniert bereits, nachdem man die Beschreibung bis einschließlich "Step 2b" umgesetzt hat. Man kann dann problemlos auf Geräte im lokalen Netzwerk zugreifen. Bei eingeschalteter WG-verbindung ist aber kein Zugriff (vom Client aus - getestet mit einem Macbook) auf Internet möglich.
Die Einstellungen im WG-Client haben dann keinen Einfluss darauf - was im unten markierten Bereich eingegeben wird, ist egal:
##
#client config macbook
[Interface]
PrivateKey = <xxx>
ListenPort = 52011
Address = 10.10.10.11/32
**DNS = <x.x.x.x>**
[Peer]
PublicKey = <xxx>
AllowedIPs = 0.0.0.0/0
Endpoint = my domain.com:51821
PersistentKeepalive = 25##
((2)) Schritt 2c nicht vergessen
Ohne die unter [[https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-2c-assignments-and-routing Schritt 2c]] beschriebene Zuordnung zum WG-Interface **funktionierte nicht mal das Routing nach außen**. Kann eventuell an der Multi-WAN-Konfiguration liegen, die hier vorlag.
Befolgt man "Step 2c" (in unserem Fall bis einschließlich Festlegung des dynamischen Gateways), wird bei bestehender Verbindung ein Zugriff auf das Internet möglich - zumindest unabhängig von der Einstellung zum DNS-Server.
Verweist der DNS-Eintrag im Client (siehe oben) aber auf den lokalen OPNsense-DNS (Beispiel: 10.1.0.1), funktioniert DNS beim Client nicht. Nimmt man im Client den eigenen DNS, ist alles kein Problem:
- Zugriff auf LAN einer OPN funktioniert,
- Zugriff auf das Internet beim eingeschalteten Tunnel funktioniert,
- ++Internet-Zugriff scheint gar nicht über den Tunnel zu laufen (weniger Datendurchsatz, als vorher)++ die Daten werden doch über den Tunnel transportiert => Geschwindigkeit geringer als direkt, WG-Monitor zeigt Bewegung bei Zugriff des Clients auf das Internet. Scheint am Ende also nur ein DNS-Zugriffsproblem zu sein.
Für unseren Bedarf ist das OK, weil WG eher für sicheren Zugriff auf LAN-Geräte gedacht ist - aber sich auch für den Internet-Zugriff hinter der OPNsense zu verstecken müssen wir noch feilen...
Insofern führte die Beschreibung bei uns (multi-WAN?) zu keinem vollen Erfolg im Hinblick auf DNS.
**//Problem scheinbar gelöst//**:
=> mit der herausragenden Beschreibung in [[https://homenetworkguy.com/how-to/configure-wireguard-opnsense/ diesem Artikel]] konnte das Problem eingegrenzt werden. Der Unbound-DNS von OPNsense funktioniert nun einwandfrei, nachdem
- unter ##System => Settings => General## bei
"Allow DNS server list to be overridden by DHCP/PPP on WAN" (die wohl wegen multi-AN an war (oder auch nicht)
unter "exclude interfaces" das WG-Interface ausgeschlossen wurde
- selbstverständlich dann unter ##VPN => WireGuard## neu starten...
=> und als nach dem Neustart der OPNsense-Kiste das Internet per wireguard wieder nicht ging, musste diese Einstellung wieder rückgängig gemacht werden (nachdem die Ergänzung der firewall-rules auf dem Interface WGUARD keine Besserung brachte...);
Hier sind wir noch am rätseln, wie genau der kniff ist...
**Wichtig: jegliche Änderungen der Einstellungen - auch Routen und Firewall-Regeln etc. - wirken erst dann, nachdem unter ##VPN => WireGuard => General## die Funktionalität aus- und wieder eingeschaltet wurde...**
((1)) Wireguard mit Ubuntu 20.04
//nachstehende Beschreibung funktioniert mit Ubuntu ab V. 20.04 (also auch mit 22.04) und mit Debian ab v. 11.//
Es muss nur das Paket ##wireguard## installiert werden - wobei dieser //wireguard// nicht enthält, sondern lediglich Hilfsprogramme (wenn ich das richtig verstanden habe) => wireguard selbst ist im Linux-Kernel bereits enthalten.
Folgende Konfigurationsschritte sind insgesamt notwendig:
((2)) Tools installieren
## apt install wireguard##
((2)) Schlüssel generieren - am besten mit folgendem Skript:
//generatekeys.sh//
##
#!/bin/bash
PRIVATE_KEY=`wg genkey`
PUBLIC_KEY=`echo $PRIVATE_KEY | wg pubkey`
echo Private Key: $PRIVATE_KEY
echo Public Key: $PUBLIC_KEY
##
((2)) Routing aktivieren
Wenn der Zugriff nicht nur auf die Maschine selbst, sondern auch auf das mit der Maschine verbundene, lokale Netzwerk erwünscht ist, muss das Routing funktionieren. Geht wie folgt:
##
# sudo sysctl -w net.ipv4.ip_forward=1
# vim /etc/sysctl.conf
=> net.ipv4.ip_forward=1 # (uncomment the line)
##
((2)) Konfiguration des "Servers"
D. h. in Terminologie von WireGuard => des ersten Peers unter Ubuntu erstellen - zu diesem werden Verbindungen initiiert.
Datei ##/etc/wireguard/wg.conf## erstellen und bearbeiten:
##
[Interface]
Address = 10.11.10.1/24 => Adresse im WG-Netz (keines der verbundenen Netze)
# SaveConfig = true
ListenPort = 518XX => Port, mit dem der Server arbeitet
PrivateKey = <hier private key des **Ubuntu-Servers**>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens160 -j MASQUERADE
[Peer]
PublicKey = <hier public key **des 1. peers**>
AllowedIPs = 10.11.10.2/32
[Peer]
PublicKey = <hier public key des 2. peers>
AllowedIPs = 10.11.10.3/32
##
((2)) Konfiguration auf jedem Peer
Die oben in den jeweiligen [Peer] - Sektionen vorgesehenen Clients, die sich verbinden sollen, müssen auch für sich konfiguriert werden. Dies geht - **am Beispiel des ersten [Peer]** oben - so:
##
[Interface]
PrivateKey = <hier private key **des 1. peers**>
ListenPort = 51<irgendwas>
Address = 10.11.10.2/32
DNS = <wenn auch DNS-Server hinter wireguard genutzt werden soll, dann Adresse des DNS für dieses Subnetz>
[Peer]
PublicKey = <public key des **Ubuntu-Servers** von oben, zu dem Verbindung aufgebaut wird>
AllowedIPs = ::/0, 0.0.0.0/0
Endpoint = ip.oder.domain.com:518XX
PersistentKeepalive = 25 (wenn client hinter NAT)
##
((2)) Router vor dem Wireguard-Peer
Falls der Wireguard-Server sich hinter einem Router "versteckt", dann muss ein passender Port geöffnet werden. Also muss
- das Forwarding zum Peer (hier: der Ubuntu-Server von oben) aktiviert werden,
- die entsprechenden Firewall-Regeln bei Bedarf angepasst werden (bei einer Fritzbox reicht zum Beispiel die Freigabe, bei Lancom-Routern müssen auch Firewall-Regeln angepasst werden)
- die Weiterleitung / Zulassung muss den Port als UDP betreffen, der **oben als 518XX** genannt wurde.
((2)) Optionen für Umleitung von Daten
Die oben geschilderte Konfiguration (vgl. insbesondere die Einstellungen bei den Peers, die auf den "Server" zugreifen) führt dazu, das jeglicher Datenverkehr am Client ins / vom Internet über WG-Tunnel geleitet wird. Um zu unterscheiden und nur den Traffic für das Zielnetzwerk (hinter dem WG-Gateway) über den Tunnel zu schicken, muss man:
1) aus ##AllowedIPs = 0.0.0.0/0## auf das Netzwerk beschränken: ##AllowedIPs = ::/0, 192.168.1.0/24##
wobei "192.168.1.0/24" das Netzwerk hinter dem WG-Gateway ist
1) am besten sollte man auch nicht den DNS-Server des Zielnetzwerkes benutzen, sondern den lokalen
Insgesamt wäre also die Peer-Konfiguration eher so:
##
[Interface]
PrivateKey = <hier private key **des 1. peers**>
ListenPort = 51<irgendwas>
Address = 10.11.10.2/32
DNS = <lokaler Server>
[Peer]
PublicKey = <public key des **Ubuntu-Servers** von oben, zu dem Verbindung aufgebaut wird>
AllowedIPs = 192.168.1.0/24 => privates Zielnetzwerk
Endpoint = ip.oder.domain.com:518XX
PersistentKeepalive = 25 (wenn client hinter NAT)
##
((1)) Autostart bei Systemen mit //systemd//
Siehe [[https://www.ivpn.net/knowledgebase/linux/linux-autostart-wireguard-in-systemd/ auch hier]].
Die meisten Befehle sind mit ROOT-Rechten auszuführen.
((2)) Konfiguration der Verbindungen
siehe oben
((2)) WireGuard service zu //systemd// hinzufügen
Mit dem richtigen Tunnel:
##systemctl enable wg-quick@wg0.service
systemctl daemon-reload##
((2)) Das neu eingerichtete Service starten
##systemctl start wg-quick@wg0##
((2)) Jetzt kann das System neu gestartet werden
(um zu schauen, ob es funktioniert)
((2)) Status überprüfen
##systemctl status wg-quick@wg0##
((2)) Alles wieder löschen
##systemctl stop wg-quick@wg0
systemctl disable wg-quick@wg0.service
rm -i /etc/systemd/system/wg-quick@wg0*
systemctl daemon-reload
systemctl reset-failed##
//to be continued//
== die schnelle Alternative zu alten VPN-Technologien ==
>>**gute Quellen**
- [[https://homenetworkguy.com/how-to/configure-wireguard-opnsense/ WG auf OPNsense step-by-step + sehr nützliche Hinweise]]
- [[https://docs.opnsense.org/index.html einwandfreie offizielle Dokumentation]]
>>
Eine Diskussion über Vor- und Nachteile dieses (auf jeden Fall spannenden) Projektes wird hier nicht geführt. Es hat auf jeden Fall einige Vorteile, die wir gern nutzen. Selbstverständlich muss man alles richtig einstellen, damit WireGuard
a) überhaupt funktioniert
a) keine Sicherheitslücken entstehen
((1)) WireGuard mit OPNsense
Die Beschreibung unter https://docs.opnsense.org/manual/how-tos/wireguard-client.html und auf den anderen OPNsense-Seiten zu WireGuard ist alles sehr gut beschrieben. Wenn man die Schritte befolgt, funktioniert alles in der Regel gut.
Einige Probleme mit DNS gab es dennoch:
((2)) Einwahl ins lokale LAN hinter OPNsense
Der Zugriff auf die Geräte hinter OPNsense funktioniert bereits, nachdem man die Beschreibung bis einschließlich "Step 2b" umgesetzt hat. Man kann dann problemlos auf Geräte im lokalen Netzwerk zugreifen. Bei eingeschalteter WG-verbindung ist aber kein Zugriff (vom Client aus - getestet mit einem Macbook) auf Internet möglich.
Die Einstellungen im WG-Client haben dann keinen Einfluss darauf - was im unten markierten Bereich eingegeben wird, ist egal:
##
#client config macbook
[Interface]
PrivateKey = <xxx>
ListenPort = 52011
Address = 10.10.10.11/32
**DNS = <x.x.x.x>**
[Peer]
PublicKey = <xxx>
AllowedIPs = 0.0.0.0/0
Endpoint = my domain.com:51821
PersistentKeepalive = 25##
((2)) Schritt 2c nicht vergessen
Ohne die unter [[https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-2c-assignments-and-routing Schritt 2c]] beschriebene Zuordnung zum WG-Interface **funktionierte nicht mal das Routing nach außen**. Kann eventuell an der Multi-WAN-Konfiguration liegen, die hier vorlag.
Befolgt man "Step 2c" (in unserem Fall bis einschließlich Festlegung des dynamischen Gateways), wird bei bestehender Verbindung ein Zugriff auf das Internet möglich - zumindest unabhängig von der Einstellung zum DNS-Server.
Verweist der DNS-Eintrag im Client (siehe oben) aber auf den lokalen OPNsense-DNS (Beispiel: 10.1.0.1), funktioniert DNS beim Client nicht. Nimmt man im Client den eigenen DNS, ist alles kein Problem:
- Zugriff auf LAN einer OPN funktioniert,
- Zugriff auf das Internet beim eingeschalteten Tunnel funktioniert,
- ++Internet-Zugriff scheint gar nicht über den Tunnel zu laufen (weniger Datendurchsatz, als vorher)++ die Daten werden doch über den Tunnel transportiert => Geschwindigkeit geringer als direkt, WG-Monitor zeigt Bewegung bei Zugriff des Clients auf das Internet. Scheint am Ende also nur ein DNS-Zugriffsproblem zu sein.
Für unseren Bedarf ist das OK, weil WG eher für sicheren Zugriff auf LAN-Geräte gedacht ist - aber sich auch für den Internet-Zugriff hinter der OPNsense zu verstecken müssen wir noch feilen...
Insofern führte die Beschreibung bei uns (multi-WAN?) zu keinem vollen Erfolg im Hinblick auf DNS.
**//Problem scheinbar gelöst//**:
=> mit der herausragenden Beschreibung in [[https://homenetworkguy.com/how-to/configure-wireguard-opnsense/ diesem Artikel]] konnte das Problem eingegrenzt werden. Der Unbound-DNS von OPNsense funktioniert nun einwandfrei, nachdem
- unter ##System => Settings => General## bei
"Allow DNS server list to be overridden by DHCP/PPP on WAN" (die wohl wegen multi-AN an war (oder auch nicht)
unter "exclude interfaces" das WG-Interface ausgeschlossen wurde
- selbstverständlich dann unter ##VPN => WireGuard## neu starten...
=> und als nach dem Neustart der OPNsense-Kiste das Internet per wireguard wieder nicht ging, musste diese Einstellung wieder rückgängig gemacht werden (nachdem die Ergänzung der firewall-rules auf dem Interface WGUARD keine Besserung brachte...);
Hier sind wir noch am rätseln, wie genau der kniff ist...
**Wichtig: jegliche Änderungen der Einstellungen - auch Routen und Firewall-Regeln etc. - wirken erst dann, nachdem unter ##VPN => WireGuard => General## die Funktionalität aus- und wieder eingeschaltet wurde...**
((1)) Wireguard mit Ubuntu 20.04
//nachstehende Beschreibung funktioniert mit Ubuntu ab V. 20.04 (also auch mit 22.04) und mit Debian ab v. 11.//
Es muss nur das Paket ##wireguard## installiert werden - wobei dieser //wireguard// nicht enthält, sondern lediglich Hilfsprogramme (wenn ich das richtig verstanden habe) => wireguard selbst ist im Linux-Kernel bereits enthalten.
Folgende Konfigurationsschritte sind insgesamt notwendig:
((2)) Tools installieren
## apt install wireguard##
((2)) Schlüssel generieren - am besten mit folgendem Skript:
//generatekeys.sh//
##
#!/bin/bash
PRIVATE_KEY=`wg genkey`
PUBLIC_KEY=`echo $PRIVATE_KEY | wg pubkey`
echo Private Key: $PRIVATE_KEY
echo Public Key: $PUBLIC_KEY
##
((2)) Routing aktivieren
Wenn der Zugriff nicht nur auf die Maschine selbst, sondern auch auf das mit der Maschine verbundene, lokale Netzwerk erwünscht ist, muss das Routing funktionieren. Geht wie folgt:
##
# sudo sysctl -w net.ipv4.ip_forward=1
# vim /etc/sysctl.conf
=> net.ipv4.ip_forward=1 # (uncomment the line)
##
((2)) Konfiguration des "Servers"
D. h. in Terminologie von WireGuard => des ersten Peers unter Ubuntu erstellen - zu diesem werden Verbindungen initiiert.
Datei ##/etc/wireguard/wg.conf## erstellen und bearbeiten:
##
[Interface]
Address = 10.11.10.1/24 => Adresse im WG-Netz (keines der verbundenen Netze)
# SaveConfig = true
ListenPort = 518XX => Port, mit dem der Server arbeitet
PrivateKey = <hier private key des **Ubuntu-Servers**>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens160 -j MASQUERADE
[Peer]
PublicKey = <hier public key **des 1. peers**>
AllowedIPs = 10.11.10.2/32
[Peer]
PublicKey = <hier public key des 2. peers>
AllowedIPs = 10.11.10.3/32
##
((2)) Konfiguration auf jedem Peer
Die oben in den jeweiligen [Peer] - Sektionen vorgesehenen Clients, die sich verbinden sollen, müssen auch für sich konfiguriert werden. Dies geht - **am Beispiel des ersten [Peer]** oben - so:
##
[Interface]
PrivateKey = <hier private key **des 1. peers**>
ListenPort = 51<irgendwas>
Address = 10.11.10.2/32
DNS = <wenn auch DNS-Server hinter wireguard genutzt werden soll, dann Adresse des DNS für dieses Subnetz>
[Peer]
PublicKey = <public key des **Ubuntu-Servers** von oben, zu dem Verbindung aufgebaut wird>
AllowedIPs = ::/0, 0.0.0.0/0
Endpoint = ip.oder.domain.com:518XX
PersistentKeepalive = 25 (wenn client hinter NAT)
##
((2)) Router vor dem Wireguard-Peer
Falls der Wireguard-Server sich hinter einem Router "versteckt", dann muss ein passender Port geöffnet werden. Also muss
- das Forwarding zum Peer (hier: der Ubuntu-Server von oben) aktiviert werden,
- die entsprechenden Firewall-Regeln bei Bedarf angepasst werden (bei einer Fritzbox reicht zum Beispiel die Freigabe, bei Lancom-Routern müssen auch Firewall-Regeln angepasst werden)
- die Weiterleitung / Zulassung muss den Port als UDP betreffen, der **oben als 518XX** genannt wurde.
((2)) Optionen für Umleitung von Daten
Die oben geschilderte Konfiguration (vgl. insbesondere die Einstellungen bei den Peers, die auf den "Server" zugreifen) führt dazu, das jeglicher Datenverkehr am Client ins / vom Internet über WG-Tunnel geleitet wird. Um zu unterscheiden und nur den Traffic für das Zielnetzwerk (hinter dem WG-Gateway) über den Tunnel zu schicken, muss man:
1) aus ##AllowedIPs = 0.0.0.0/0## auf das Netzwerk beschränken: ##AllowedIPs = ::/0, 192.168.1.0/24##
wobei "192.168.1.0/24" das Netzwerk hinter dem WG-Gateway ist
1) am besten sollte man auch nicht den DNS-Server des Zielnetzwerkes benutzen, sondern den lokalen
Insgesamt wäre also die Peer-Konfiguration eher so:
##
[Interface]
PrivateKey = <hier private key **des 1. peers**>
ListenPort = 51<irgendwas>
Address = 10.11.10.2/32
DNS = <lokaler Server>
[Peer]
PublicKey = <public key des **Ubuntu-Servers** von oben, zu dem Verbindung aufgebaut wird>
AllowedIPs = 192.168.1.0/24 => privates Zielnetzwerk
Endpoint = ip.oder.domain.com:518XX
PersistentKeepalive = 25 (wenn client hinter NAT)
##
((1)) Autostart bei Systemen mit //systemd//
Siehe [[https://www.ivpn.net/knowledgebase/linux/linux-autostart-wireguard-in-systemd/ auch hier]].
Die meisten Befehle sind mit ROOT-Rechten auszuführen.
((2)) Konfiguration der Verbindungen
siehe oben
((2)) WireGuard service zu //systemd// hinzufügen
Mit dem richtigen Tunnel:
##systemctl enable wg-quick@wg0.service
systemctl daemon-reload##
((2)) Das neu eingerichtete Service starten
##systemctl start wg-quick@wg0##
((2)) Jetzt kann das System neu gestartet werden
(um zu schauen, ob es funktioniert)
((2)) Status überprüfen
##systemctl status wg-quick@wg0##
((2)) Alles wieder löschen
##systemctl stop wg-quick@wg0
systemctl disable wg-quick@wg0.service
rm -i /etc/systemd/system/wg-quick@wg0*
systemctl daemon-reload
systemctl reset-failed##
//to be continued//
