Konfiguration¶
Wie im Hauptartikel:
Ubuntu 20.04 Focal Fossa
Du möchtest den Artikel für eine weitere Ubuntu-Version testen? Mitarbeit im Wiki ist immer willkommen! Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Neben der im Hauptartikel beschriebenen Peer-To-Peer-Architektur sind noch die hier beschriebenen Client-Server-Architekturen wichtig:
Sternnetz mit Vermittlung zwischen den Außenstellung
Gateway zwischen WireGuard-Netz und herkömmlichem Netz
Das im Hauptartikel beschriebene Sternnetz ohne Vermittlung zwischen den Außenstellen wird als Grundlage in diesem Artikel vorausgesetzt; hier werden nur die erforderlichen Änderungen zur Überführung in eine andere Architektur diskutiert.
Zur Installation der Software siehe Hauptartikel.
Wie im Hauptartikel:
Bei diesem Anwendungsfall entspricht:
Server = Mittelpunkt des WireGuard Sternnetzes (Adele im Beispiel)
Client = Außenstelle des WireGuard Sternnetzes (Bobby, Carol, … im Beispiel)
Adele soll die von Bobby empfangenen, aber für Carol bestimmten Nachrichten weiterleiten (und natürlich auch umgekehrt). Da Bobby nur den öffentlichen Schlüssel von Adele, nicht aber den von Carol kennt, sind die empfangenen Nachrichten mit dem öffentlichen Schlüssel von Adele kodiert. Adele entschlüsselt jede Nachricht von Bobby und soll die für Carol bestimmte Nachrichten wieder mit dem hier bekannten öffentlichen Schlüssel von Carol verschlüsseln.
Die Weiterleitung von Bobby an Carol muss Adele erlaubt werden; hierzu setzt man für das Protokoll IPv6 diese Kernelvariable:
sudo sysctl -w net.ipv6.conf.all.forwarding=1
Das Setzen dieser Variablen für die WireGuard-Schnittstelle VPN kann z.B. wg-quick erledigen, wenn man es in der Konfigurationsdatei /etc/wireguard/VPN.conf vermerkt:
[Interface] PostUp = sysctl -w net.ipv6.conf.all.forwarding=1 # Hier folgen weitere Einstellungen für Interface und die Peers
Beim Protokoll IPv4 ist für die IP-Weiterleitung die Variable net.ipv4.ip_forward zuständig.
Für eine alternative Methode zur Konfiguration der Weiterleitung siehe Gateway Gateway WireGuard/LAN.
Außerdem müssen parallel zum Crypto-Routing auch für das IP-Routing die Leitwege eingerichtet werden. wg-quick erledigt das automatisch durch Ableitung der Leitwege aus den Angaben bei AllowedIPs.
Bei dieser Betriebsart besteht keine Ende-zu-Ende-Verschlüsselung zwischen jeweils 2 Außenstellen! Der Server im Mittelpunkt kann und muss sogar alles mitlesen.
Auf jedem Client muss das Crypto-Routing und das IP-Routing angepasst werden.
Das geht am einfachsten, indem man auf dem Mittelpunkt die Datei $HOSTNAME.peer modifiziert. Statt des individuellen IP-Bereiches des Mittelpunktes wird ein größerer IP-Bereich, welche die Bereiche des Mittelpunktes und aller Außenstellen überdeckt, an die Außenstellen verteilt:
[Peer] # Adele mit Vermittlung zwischen den Außenstellen PublicKey = Z/fkUwCqxYCzgEaOU/Y8X9a0je82oT7gKO86skxaaAY= Endpoint = adele.example.net:48637 # AllowedIPs = fd00:5747:7767:1000::/64 # Diese Zeile durch die folgende ersetzen! AllowedIPs = fd00:5747:7767::48
Mit dieser Datei als Grundstock konfiguriert man jede Außenstelle wie im Hauptartikel beschrieben.
Die hier ebenfalls erforderliche Einrichtung des Leitwegs für das IP-Routing erledigt wieder wg-quick automatisch durch Ableitung der Leitwege aus den Angaben bei AllowedIPs.
Ein Rechner, der selbst kein direkter Teilnehmer am WireGuard-VPN ist, kann einen WireGuard-Teilmehmer als Zugangspunkt (Gateway) benutzen, indem er eine der zulässigen internen IP-Adressen dieses Teilnehmers verwendet.
Bei diesem Anwendungsfall entspricht:
Server = Teilnehmer im WireGuard-Netz mit zusätzlicher Schnittstelle LAN (Carol im Beispiel)
Client = Weiterer Rechner (ohne WireGuard) an LAN-Schnittstelle des Servers
Der WireGuard-Teilnehmer, welcher als Zugangspunkt arbeiten soll, muss als Router konfiguriert werden.
Zur Konfiguration der Weiterleitung zwischen den Schnittstellen VPN und LAN kann die oben beschriebene Methode verwendet werden oder man modifiziert die Systemdatei /etc/sysctl.d/99-sysctl.conf, indem man diese Zeilen anfügt bzw. deren Kommentarstatus aufhebt:
net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1
Der Teilnehmer darf nicht alle ihm zugewiesenen internen IP-Adressen für sich selbst reservieren, sondern muss eine oder einige für sich auswählen und andere an einer anderen Netzwerkschnittstelle (also nicht seiner WireGuard-Schnittstelle) den anderen Rechnern weitergeben. Diese Weitergabe erfolgt nicht über WireGuard, sondern beispielsweise per DHCP oder radvd 🇬🇧 oder durch manuelle Konfiguration.
Das Routing wird geändert: Auf den Rechner Carol verwendet man statt:
ip -6 addr add fd00:5747:7767:3000::/56 dev VPN
beispielsweise:
ip -6 addr add fd00:5747:7767:3000::/128 dev VPN ip -6 route add fd00:5747:7767:3000::/64 dev LAN
Hierbei steht LAN für die Schnittstelle, über welche die Clients des Zugangspunktes Carol diesen erreichen.
NAT wird, auch bei Verwendung von internen IPv4-Adressen, bei der Nutzung von WireGuard nicht benötigt.
Die Ausführung der Konfiguration kann man wieder wg-quick übertragen. Für das Beispiel ergibt sich auf Carol diese Konfigurationsdatei /etc/wireguard/VPN-conf:
[Interface] Address = fd00:5747:7767:3000::/128 PostUp = ip -6 route add fd00:5747:7767:3000::/64 dev LAN ListenPort = 35784 PrivateKey = MCXpBixLEiT/axVpBY52KzH0TQkOCo7WQxt105FZwVE= [Peer] # Adele PublicKey = Z/fkUwCqxYCzgEaOU/Y8X9a0je82oT7gKO86skxaaAY= Endpoint = adele.example.net:48637 AllowedIPs = fd00:5747:7767:1000::/64
Auf den Clients eines WireGuard-Zugangspunktes ist diese Konfiguration erforderlich:
ip -6 addr add fd00:5747:7767:3000:1:2:3:4/64 dev LAN ip -6 route add fd00:5747:7767::/48 dev LAN
Der Adressteil ::1:2:3:4/64 ist hier beispielhaft und natürlich für jeden Client individuell festzulegen.
An Stelle individueller manueller Konfiguration auf jedem Client kann man auch auf dem Zugangspunkt als Router den Prefix fd00:5747:7767:3000::/64 und die Route fd00:5747:7767::/48 ankündigen, dies leistet aber nicht WireGuard selbst. Die Konfiguration auf jedem Client erfolgt dann automatisch per SLAAC.
Die hier besprochene Anforderung des Internet-Zugangs über einen VPN-Server wird oft aus einem Bedürfnis nach Anonymität und „Sicherheit“ nachgefragt. WireGuard kann diese Bedürfnisse genau so schlecht wie andere VPN-Methoden befriedigen:
Anonym wird wird nicht. Man ersetzt lediglich seine eigene Identität, soweit diese auf der IP-Adresse beruht, durch die Identität des Betreibers des VPN-Servers und täuscht damit seinen Vertragspartner. Dieser Effekt hat nichts mit der Verschlüsselung zu tun, sondern beruht nur auf der Verwendung einer IP-Adresse des VPN-Server-Betreibers.
Man ist auch nicht sicher vor Abhörangriffen, sondern verschiebt nur die Angriffspunkte. Der Einsatz eines VPN …
ändert nichts an den Abhörmöglichkeiten auf dem eigenen Rechner (Quellen-TKÜ),
verheimlicht einem Überwacher auf der Strecke zwischen eigenem Rechner und dem VPN-Server zwar die Inhalte der Kommunikation, jedoch nicht den Kommunikationsvorgang selber (Meta-Daten),
erschafft eine zusätzliche und trivial benutzbare Abhörmöglichkeit durch den Betreiber des VPN-Servers,
ändert nichts an den Abhörmöglichkeiten zwischen VPN- und Ziel-Server sowie auf dem Ziel-Server.
Technisch ist dies ein Spezialfall des oben besprochenen Anwendungsfalls Gateway WireGuard/LAN, jedoch werden Innen- und Außenseite miteinander vertauscht:
Server = Teilnehmer im WireGuard-Netz mit zusätzlicher Schnittstelle Welt (Adele im Beispiel)
externer Client = beliebiger Rechner (ohne WireGuard) an Schnittstelle Welt des Servers (Diese Rolle entspricht der Rolle "Client" im Beispiel „Gateway WireGuard/LAN“.)
interner Client = weiterer Teilnehmer an Schnittstelle VPN (z.B. Bobby)
Bei diesem Anwendungsfall muss man innerhalb des WireGuard-Netzes global routingfähige IP-Adressen verwenden. Man hat diese Möglichkeiten:
Man verwendet keine privaten Adressen, weder aus dem Bereich fd00::/8 noch solche aus RFC1918, sondern lässt sich offiziell Adressen zuweisen. In diesem Artikel wird angenommen, dass der IP-Bereich 2000:0db8:1000::/62 zur Verfügung steht und auf die Teilnehmer des WireGuard-VPN aufgeteilt wird. An Stelle der bisher in den Beispielen genannten Adressen aus dem Bereich fd00::/8 sind beispielsweise diese einzusetzen:
Adele: 2000:0db8:1000:0::/64
Bobby: 2000:0db8:1000:2::/64
Carol: 2000:0db8:1000:3::/64
Man verwendet doch private Adressen, muss dann aber auf dem Gateway zum Internet zusätzlich NAT oder sogar NAT/PT einrichten.
Der Server muss als Router arbeiten. Hierzu setzt man die Kernel-Variable(n) wie oben beschrieben.
Er benötigt außerdem eine normale Vorgabe-Route (default) ins Internet über die Schnittstelle Welt. Da er aber als Voraussetzung ohnehin als Teilnehmer im Internet arbeiten muss, ist dies bereits gegeben.
Optional, aber empfehlenswert ist die Einrichtung einer Firewall, um die Initiierung von Verbindungen aus dem Internet zu Rechnern im VPN-Netz zu verhindern oder einzuschränken.
Der Server sollte auch den Teilnehmern im WireGuard-VPN einen über WireGuard erreichbaren DNS-Server anbieten, den die internen Clients zur DNS-Namensauflösung ohne Datenlecks verwenden können.
Hier ist nichts zu konfigurieren. Ein externer Client muss lediglich die Adresse des Teilnehmers im WireGuard-VPN kennen, um diesen zu erreichen.
Es sind nur die üblichen Änderungen der Leitwege bei Nutzung eines VPNs vorzunehmen:
Dedizierte Route zum VPN-Server (im Beispiel Adele):
ip route add 192.0.2.128/32 dev Welt
Vorgabe-Route in den VPN-Tunnel:
ip -6 route del default dev Welt ip -6 route add default dev VPN ip -4 route del default dev Welt ip -4 route add default dev VPN
Man sollte diese Änderungen nicht wie hier gezeigt direkt vornehmen, sondern sein Netzwerk-Konfigurationsprogramm dementsprechend konfigurieren.
Außerdem müssen bei paralleler Nutzung der beiden Protokolle IPv4 und IPv6 mögliche Datenlecks verhindert werden. Dies kann verhindert werden, indem man für beide Protokolle die Vorgabe-Route auf die Schnittstelle VPN legt.
Auch DNS-Namensabfragen können bei schlecht konfigurierten DNS-Forwardern zu Datenlecks führen:
Man darf DNS-Server im Internet nur durch den VPN-Tunnel ansprechen.
DNS-Server im lokalen Netz, inkl. des DNS-Cache auf dem eigenen Rechner, dürfen ebenfalls DNS-Server als Forwarder im Internet nicht direkt kontaktieren.