WireGuard

An dieser Stelle sollen einige Beschreibungen zu Linux und Router-Betriebssystemen erfolgen, da die Implementierungen recht unterschiedlich realisiert worden sind.

Die Entwickler schreiben:
Alle Fragen der Schlüsselverteilung und der gepushten Konfigurationen gehören nicht in den Aufgabenbereich von WireGuard; das sind Themen, die besser anderen Schichten überlassen werden, damit wir nicht mit der Aufblähung von IKE oder OpenVPN enden.

Dadurch haben sich verschiedene Formen der Schlüsselverteilung entwickelt, was die Angelegenheit sehr komplex machen kann. Es haben sich zwei verschiedene Vorgehensweisen entwickelt, die vom Vorgehen entgegengesetzt sind.

Bedauerlicher Weise habe ich bisher nirgends einen Hinweis darauf gefunden. Kompliziert kann es werden, wenn man WireGuard® auf Rechnern mit unterschiedlichen Konzepten der Schlüsselverteilung realisieren möchte.

Eine Übersicht zu WireGuard® erhalten Sie auf der folgenden Seite:

WireGuard® im Detail

Das ist eine Übersetzung der ersten Seite des Projekts.

Eine sehr gute Beschreibung finden Sie auf ADMINISTRATOR:

Merkzettel: VPN Installation mit Wireguard

Wenn Sie sich mit WireGuard® befassen wollen, sollten Sie sich das in jedem Fall ansehen.

Die Schlüsselverteilung

Variante 1 (WireGuard-Entwickler, Linux, OpenWRT)

Bei der ersten Variante geht man vor, so wie man es bei SSH macht.

Die eigenen Schlüssel werden auf jedem Rechner selbst erzeugt.

  1. Die Public Keys werden jeweils auf den anderen Rechner exportiert.
  2. Damit bleiben die Privat Keys nur auf dem eigenen Rechner.

Diese Variante zeigen auch die WireGuard-Entwickler:

Dieses Vorgehen findet man bei diversen Linux Distributionen und ist auch in den Beschreibungen von OpenWRT zu finden.

Ich bin auch von dieser meinen Meinung korrekten Verteilung der Schlüssel ausgegangen, musste aber nach längerer Fehlersuche feststellen, dass es auch anders gehandhabt wird.

Variante 2 (Server: DD-WRT — Client: DD-WRT, Android, GL.iNet)

Bei dieser Variante wird das Konzept auf den Kopf gestellt:

  1. Die Schlüssel werden auf dem WireGuard® Server erzeugt.
  2. Der Public Key des Servers wird auf den Client exportiert.
  3. Der Privat Key des Clients wird auf dem Server erzeugt und auf den Client exportiert.
  4. Der Privat Key des Clients wird nur für den Export erzeugt aber nicht auf dem Server gespeichert.
  5. Der Server besitzt zum Schluss nur den Public Key des Clients.
  6. Damit bleibt der Privat Key jeweils nur auf dem eigenen Rechner.

DD-WRT

Bei DD-WRT gibt es einige Fallen, in die man leicht hereintreten kann. Man hat viele Möglichkeiten bei der Konfiguration, jedoch verhält es sich manchmal unerwartet.

Bei der Einrichtung des WireGuard® Clients gibt es eine Schaltfläche QR-Code.

Dazu steht im DD-WRT Wiki → VPN → Wiregard
(Übersetzung):

Peers hinzufügen:
Für einfache Konfigurationen geben Sie einfach die Peer Tunnel IP innerhalb des oet1 interface ip Bereichs (z.B. 10.10.0.2) und Peer Tunnel DNS (8.8.8.8) ein. Die MTU des Peer-Tunnels wird automatisch berechnet (WAN mtu-40), kann aber anschließend geändert werden. Klicken Sie auf Speichern und dann auf die Schaltfläche QR-Code, um ihn zu generieren.

Diese Aussage ist so definitiv falsch:

  1. Wenn man die Schaltfläche QR-Code drückt, erwartet man den QR-Code und die Konfiguration angezeigt zu bekommen.
  2. Statt dessen werden neue Schlüssel generiert und dann der QR-Code angezeigt.
  3. Gleichzeitig bricht die Verbindung zum Client ab, falls diese schon eingerichtet war, da die neuen Schlüssel offenbar sofort wirksam werden.
  4. Die einzige Möglichkeit, um seine alte Konfiguration zu behalten besteht darin, den DD-WRT Router ohne sichern neu zu booten.
  5. Der Knopf Einstellungen zurücknehmen funktioniert hier nicht.
  6. Der Knopf QR-Code müsste z. B. Generate Keys oder ähnlich heißen, was seine Funktion eher beschreiben würde.

WARNUNG
GL.iNet GL-X750 (SPITZ)

Die LTE-Verbindung funktioniert gut, aber der WireGuard Client nicht.

Hier ist es besonders unübersichtlich, da in den GL.iNet-Masken die Version 2 umgesetzt ist.
Wechselt man aber mit LuCI auf die OpenWRT-Oberfläche gilt das das OpenWRT-Konzept mit Version 1.

Der WireGuard Client funktioniert nicht!

Wenn ich mich in den Foren, auch bei GL.iNet, umsehe stelle ich fest, dass es schon seit mehreren Jahren Probleme mit dem WireGuard Client gibt.

Die Implementierung ist mehr als mangelhaft.

  • Wenn der WireGuard aktiviert ist und keine Verbindung hat, ist keine Kommunikation ins Internet mehr möglich.
  • Die meiste Zeit funktioniert die Verbindung nicht oder ist instabil.
  • Oft wird nur der IP-Tunnel aufgebaut, aber eine Verbindung geht gar nicht oder nur in eine Richtung.

Eine Lösung, die gut funktioniert ist es, einen Raspberry Pi 3 hinter den Router zu setzen, auf dem der WireGuard Client läuft.

Hier finden Sie es auf YouTube:
WireGuard Site to Site VPN einrichten – Netzwerke sicher verbinden !!
https://www.youtube.com/watch?v=uV2NRmdCR0k

Variante 3 (Server: DD-WRT – Client: Linux Mint)

  1. Die Schlüssel werden auf dem WireGuard® Server erzeugt.
  2. Der Public Key des Servers wird auf den Client exportiert.
  3. Der Privat Key und der Public Key des Clients werden auf dem Server erzeugt und auf den Client exportiert.
  4. Der Privat Key des Clients wird nur für den Export erzeugt aber nicht auf dem Server gespeichert.
  5. Der Server besitzt zum Schluss nur den Public Key des Clients.
  6. Damit bleibt der Privat Key jeweils nur auf dem eigenen Rechner.

Alternativ können die Keys aber auch manuell, wie in Variante 1 beschrieben, übertragen werden.

  1. Dazu werden der Privat Key und Public Key auf dem WireGuard® Server erzeugt auf der Privat Key auf den Client exportiert.
  2. Der Public Key des Client wird auf dem Client erzeugt und auf den Server exportiert.
  3. Dann die Tasten Speichern und Anwenden drücken, ggf. den Router neu booten.
  4. Die Schaltfläche QR-Code darf auf keinen Fall gedrückt werden, da man sich sonst die Konfiguration sofort wieder zerschießt.
Weiter: WireGuard® im DetailUpdate: 09.11.2021