Alle Kategorien:
  E V T Z Allgemein
 EVTZ-Datenbank
  E V T Z Dokumente
 Kommentare
 Literaturdatenbank
  E V T Z Praxis
 Rechtsprechungsdatenbank
 Rechtsvorschriften
  Kooperationsinstrumente
 Startseite

Verlauf der Änderungen der Seite WireGuard


Version [4466]

Zuletzt bearbeitet am 2023-05-05 08:58:43 durch ErdaxoAdmin
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.

Gelöscht:
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.


Version [3773]

Bearbeitet am 2022-02-28 22:53:09 durch WojciechLisiewicz
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


Version [3623]

Bearbeitet am 2021-05-22 17:13:21 durch WojciechLisiewicz

Keine Unterschiede

Version [3622]

Bearbeitet am 2021-05-22 17:13:09 durch WojciechLisiewicz
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##


Version [3218]

Bearbeitet am 2021-04-08 18:02:47 durch ErdaxoAdmin
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.

Gelöscht:
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:


Version [3217]

Bearbeitet am 2021-04-08 17:56:19 durch ErdaxoAdmin
Hinzugefügt:
PublicKey = <hier public key **des 1. peers**>
PrivateKey = <hier private key **des 1. peers**>

Gelöscht:
PublicKey = <hier public key des 1. peers>
PrivateKey = <hier private key des 1. peers>


Version [3216]

Bearbeitet am 2021-04-08 17:52:40 durch ErdaxoAdmin
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)

Gelöscht:
((2)) Konfiguration des ersten Peers (Server?) erstellen
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


Version [3215]

Bearbeitet am 2021-04-08 00:33:55 durch WojciechLisiewicz
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:
Sicherstellen, dass Wireguard-Peer immer die gleiche bekommt. Entweder feste einstellen oder vom Router immer die gleiche per DHCP zuweisen lassen.


Version [3212]

Bearbeitet am 2021-04-08 00:32:30 durch WojciechLisiewicz
Hinzugefügt:
Am Beispiel eines LANCOM-Routers mit LCOS 10.42:


Version [3170]

Bearbeitet am 2021-04-07 23:22:43 durch WojciechLisiewicz
Hinzugefügt:
((3)) Routing => //port forwarding//
## IP-Router => Maskierung => Port Forwarding Tabelle##
((3)) Firewall => Regel "accept"
für das Forwarding auf die IP


Version [3166]

Bearbeitet am 2021-04-07 22:51:43 durch WojciechLisiewicz
Hinzugefügt:
Datei ##/etc/wireguard/wgX.conf## erstellen und bearbeiten:

Gelöscht:
Datei ##/etc/wireguard/wg.conf## erstellen und bearbeiten:


Version [3165]

Bearbeitet am 2021-04-07 22:50:30 durch WojciechLisiewicz
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.


Version [3145]

Bearbeitet am 2021-04-06 23:19:03 durch ErdaxoAdmin
Hinzugefügt:
PublicKey = <hier public key des 2. peers>
AllowedIPs = 10.11.10.3/32

Gelöscht:
AllowedIPs = 10.11.10.11/32


Version [3143]

Bearbeitet am 2021-04-06 23:17:23 durch ErdaxoAdmin

Keine Unterschiede

Version [3142]

Bearbeitet am 2021-04-06 23:17:07 durch ErdaxoAdmin
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


Version [3140]

Bearbeitet am 2021-04-06 23:05:40 durch ErdaxoAdmin

Keine Unterschiede

Version [3139]

Bearbeitet am 2021-04-06 23:05:26 durch ErdaxoAdmin
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


Version [3096]

Bearbeitet am 2021-03-28 12:31:14 durch WojciechLisiewicz
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...


Version [3073]

Bearbeitet am 2021-03-26 16:57:44 durch WojciechLisiewicz
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]]
>>


Version [3072]

Bearbeitet am 2021-03-26 16:48:05 durch WojciechLisiewicz
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...


Version [3070]

Bearbeitet am 2021-03-26 16:29:29 durch WojciechLisiewicz
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:
- ++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.


Version [3069]

Bearbeitet am 2021-03-26 16:28:30 durch WojciechLisiewicz
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.

Gelöscht:
- Internet-Zugriff scheint gar nicht über den Tunnel zu laufen (weniger Datendurchsatz, als vorher)


Version [3068]

Die älteste bekannte Version dieser Seite wurde am 2021-03-26 15:41:48 von WojciechLisiewicz bearbeitet.