[[Vorlage(Getestet, bionic, focal)]] {{{#!vorlage Wissen [:Terminal: Ein Terminal öffnen] [:Editor: Einen Editor öffnen] [:Rechte: Rechte für Dateien und Ordner ändern] [:sudo:Root-Rechte] }}} [[Inhaltsverzeichnis()]] Neben der im [:WireGuard#Konfiguration: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. = Installation = Zur Installation der Software siehe [:WireGuard#Installation:Hauptartikel]. = Konfiguration = Wie im Hauptartikel: [[Bild(WireGuard/WireGuard-VPN-im-Internet.png, 900, align=center) ]] = Sternnetz mit Vermittlung = Bei diesem Anwendungsfall entspricht: * Server = Mittelpunkt des WireGuard Sternnetzes (Adele im Beispiel) * Client = Außenstelle des WireGuard Sternnetzes (Bobby, Carol, … im Beispiel) == Server == 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: {{{#!vorlage Befehl 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 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`. {{{#!vorlage Hinweis 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. }}} == Client == 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`. = Gateway WireGuard/LAN = 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 == Server == 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 [https://wiki.ubuntuusers.de/wiki/tags/dhcp/ DHCP] oder [https://en.wikipedia.org/wiki/Radvd radvd] {en} oder durch manuelle Konfiguration. Das Routing wird geändert: Auf den Rechner Carol verwendet man statt: {{{#!vorlage Befehl ip -6 addr add fd00:5747:7767:3000::/56 dev VPN }}} beispielsweise: {{{#!vorlage Befehl 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 }}} == Client == Auf den Clients eines WireGuard-Zugangspunktes ist diese Konfiguration erforderlich: {{{#!vorlage Befehl 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 [https://de.wikipedia.org/wiki/IPv6 SLAAC]. = Gateway WireGuard/Internet = {{{#!vorlage Hinweis 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: 1. 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. 1. 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 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: 1. 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` 1. Man verwendet doch private Adressen, muss dann aber auf dem Gateway zum Internet zusätzlich NAT oder sogar NAT/PT einrichten. == Server == 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. == Externer Client == Hier ist nichts zu konfigurieren. Ein externer Client muss lediglich die Adresse des Teilnehmers im WireGuard-VPN kennen, um diesen zu erreichen. == Interner Client == 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. #tag: Netzwerk, VPN, Client-Server, WireGuard, Sicherheit