Verlauf der Änderungen der Seite WireGuard
Hinzugefügt:
//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.
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.
Gelöscht:
Hinzugefügt:
((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:
DNS = <lokaler Server>
AllowedIPs = 192.168.1.0/24 => privates Zielnetzwerk
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:
DNS = <lokaler Server>
AllowedIPs = 192.168.1.0/24 => privates Zielnetzwerk
Keine Unterschiede
Hinzugefügt:
((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##
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##
Hinzugefügt:
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:
((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)) 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.
Gelöscht:
Hinzugefügt:
PublicKey = <hier public key **des 1. peers**>
PrivateKey = <hier private key **des 1. peers**>
PrivateKey = <hier private key **des 1. peers**>
Gelöscht:
PrivateKey = <hier private key des 1. peers>
Hinzugefügt:
((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:
PrivateKey = <hier private key des **Ubuntu-Servers**>
((2)) Konfiguration auf jedem Peer
Die oben in den jeweiligen [Peer] - Sektionen vorgesehenen Clients, die sich verbinden sollen müssen auch einzeln konfiguriert werden. Dies geht - **am Beispiel des ersten [Peer]** oben - so:
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>
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)
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:
PrivateKey = <hier private key des **Ubuntu-Servers**>
((2)) Konfiguration auf jedem Peer
Die oben in den jeweiligen [Peer] - Sektionen vorgesehenen Clients, die sich verbinden sollen müssen auch einzeln konfiguriert werden. Dies geht - **am Beispiel des ersten [Peer]** oben - so:
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>
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)
Gelöscht:
Datei ##/etc/wireguard/wgX.conf## erstellen und bearbeiten:
PrivateKey = <hier private key des Servers>
((2)) Router konfigurieren
Am Beispiel eines LANCOM-Routers mit LCOS 10.42:
((3)) IP ermitteln
Sicherstellen, dass Wireguard-Peer immer die gleiche IP bekommt. Entweder feste einstellen oder vom Router immer die gleiche per DHCP zuweisen lassen.
((3)) Routing => //port forwarding//
## IP-Router => Maskierung => Port Forwarding Tabelle##
((3)) Firewall => Regel "accept"
für das Forwarding auf die IP
Hinzugefügt:
Sicherstellen, dass Wireguard-Peer immer die gleiche IP bekommt. Entweder feste einstellen oder vom Router immer die gleiche per DHCP zuweisen lassen.
Gelöscht:
Hinzugefügt:
Am Beispiel eines LANCOM-Routers mit LCOS 10.42:
Hinzugefügt:
((3)) Routing => //port forwarding//
## IP-Router => Maskierung => Port Forwarding Tabelle##
((3)) Firewall => Regel "accept"
für das Forwarding auf die IP
## IP-Router => Maskierung => Port Forwarding Tabelle##
((3)) Firewall => Regel "accept"
für das Forwarding auf die IP
Hinzugefügt:
Datei ##/etc/wireguard/wgX.conf## erstellen und bearbeiten:
Gelöscht:
Hinzugefügt:
((2)) Router konfigurieren
((3)) IP ermitteln
Sicherstellen, dass Wireguard-Peer immer die gleiche bekommt. Entweder feste einstellen oder vom Router immer die gleiche per DHCP zuweisen lassen.
((3)) IP ermitteln
Sicherstellen, dass Wireguard-Peer immer die gleiche bekommt. Entweder feste einstellen oder vom Router immer die gleiche per DHCP zuweisen lassen.
Hinzugefügt:
PublicKey = <hier public key des 2. peers>
AllowedIPs = 10.11.10.3/32
AllowedIPs = 10.11.10.3/32
Gelöscht:
Keine Unterschiede
Hinzugefügt:
((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 ersten Peers (Server?) erstellen
Datei ##/etc/wireguard/wg.conf## erstellen und bearbeiten:
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 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
PublicKey = <hier public key des 1. peers>
AllowedIPs = 10.11.10.2/32
PublicKey = <hier public key des 1. peers>
AllowedIPs = 10.11.10.11/32
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 ersten Peers (Server?) erstellen
Datei ##/etc/wireguard/wg.conf## erstellen und bearbeiten:
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 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
PublicKey = <hier public key des 1. peers>
AllowedIPs = 10.11.10.2/32
PublicKey = <hier public key des 1. peers>
AllowedIPs = 10.11.10.11/32
Keine Unterschiede
Hinzugefügt:
((1)) Wireguard mit Ubuntu 20.04
In Ubuntu 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
In Ubuntu 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
Hinzugefügt:
=> 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...
Hier sind wir noch am rätseln, wie genau der kniff ist...
Hinzugefügt:
>>**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]]
>>
- [[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]]
>>
Hinzugefügt:
**//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...
=> 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...
Hinzugefügt:
- ++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.
Gelöscht:
Hinzugefügt:
- ++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 auf das Internet. Scheint am Ende also nur ein DNS-Zugriffsproblem zu sein.
