Erfahrungen mit Wireguard

Gemeinsam ins Internet mit Firewall und Proxy.
Antworten
Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Erfahrungen mit Wireguard

Beitrag von heisenberg » 30.04.2021 16:34:19

Hallo zusammen,

weil ich gerade etwas Probleme mit OpenVPN hatte, wollte ich interessehalber mal wireguard ausprobieren. Ist ja jetzt eigentlich auch nix mehr besonders Neues. Meine Ausgangssituation war, das ich OpenVPN zur Verbindung in die Firma hatte. Ein paar Routen in private Netze. Der Rest geht normal ins Internet. Blöd war nur, dass das OpenVPN regelmässig abgeschmiert ist. D. h. keine Verbindung ins Internet mehr möglich, obwohl die Default-Route eigentlich davon nicht betroffen sein sollte. Nachdem hochgestelltes Debugging auch keine zusätzlichen Einsichten gebracht hat und auch ein automatisches openvpn-restart-script auch (noch) keine Abhilfe geschafft hat, habe ich dann mal einen kurzes Ausflug zu Wireguard gemacht.

Wireguard

Einrichtung

Wireguard lässt sich ganz einfach einrichten. Es ist in Buster-Backports vorhanden und es ist nur wenig Konfiguration nötig. Es gibt auch eine gute Anleitung für Debian.[1] Bis auf die Tatsache, dass ich vergessen hatte, die Firewall auf dem VPN-Server noch zu konfigurieren ging das alles ganz schnell von der Hand.

Unterschiede zu OpenVPN

Was es im Vergleich zu OpenVPN nicht so kann ist die zentralisierte Verwaltung. Wenn man einen VPN-Server betreibt mit vielen Nutzern, dann man möchte man das eigentlich schon zentral steuern und nicht am Client nachpflegen müssen - evtl. von Leuten die keine Ahnung von Administration haben. Das betrifft
z. B. das pushen von Routen vom Server. Das muss am Client geschehen durch diese Einträge in der Konfiguration:

Code: Alles auswählen

[Peer]
AllowedIPs = 1.2.3.0/24, 192.168.100.0/24
Das Allowed IPS die Netze bezeichnet, für die (am Client) ein Routing eingerichtet ist seltsam aber verschmerzbar.

Was auch nicht funktioniert ist, dass am Server Routen für IP-Adressen auf das vormalige GW gesetzt werden können, so dass diese nicht über das VPN geroutet werden. Das ist ganz nützlich für Ausschlüsse aus den Routen, die ansonsten über das VPN-Gateway laufen. Hier habe ich mir ein Script [2] gebastelt, dass ich auf der Client-Seite via Script ausführen lasse:

Code: Alles auswählen

[Interface]
...
        PreUp                   = /usr/local/bin/route_preserve preserve        200.1.4.7 180.20.40.10
        PostDown                = /usr/local/bin/route_preserve remove          200.1.4.7 180.20.40.10

Weiterhin müssen die privaten IP-Adressen der VPN-Konfiguration auch statisch gesetzt werden. Keine dynamische Zuteilung vom Server.

Aber so insgesamt läuft das super stabil und das ganze in einer 10 Zeilen Konfiguration(client/server) und ich bin sehr begeistert. Insgesamt ist das ganze aber wohl noch sehr frisch, auch wenn's mittlerweile mit einer Version 1.0 in den Kernel aufgenommen wurde.

Das hier sind mal die anonymisierten Beispielconfigs:

Client

Code: Alles auswählen

[Interface]
        Address                 = 192.168.250.10/24
        PrivateKey              = generierter_private_key_client
        PreUp                   = /usr/local/bin/route_preserve preserve        200.1.4.7 180.20.40.10
        PostDown                = /usr/local/bin/route_preserve remove          200.1.4.7 180.20.40.10

[Peer]
        PublicKey               = generierter_public_key_server
        Endpoint                = vpnserver.dns.name:51820
        AllowedIPs              = 200.1.4.0/24, 180.20.0.0/16
        PersistentKeepalive     = 20
Server

Code: Alles auswählen

[Interface]
Address = 192.168.250.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = generierter_private_key_server

[Peer]
PublicKey = generierter_public_key_client
AllowedIPs = 192.168.250.10/32

[1] https://www.cyberciti.biz/faq/debian-10 ... pn-server/
[2] https://codeberg.org/megabert/script-pa ... e_preserve
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
ingo2
Beiträge: 1124
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

Re: Erfahrungen mit Wireguard

Beitrag von ingo2 » 02.05.2021 18:52:54

Erst mal Danke für den Beitrag.
Auch ich liebäugele mit Wireguard, was mir bisher jedoch fehlt (oder ich nicht verstanden habe) ist die Authentication. Da würde ich auf Client-Seite gerne meinen 4094-bit RSA-Key von einem Yubikey verwenden, den nutze ich außer zum verschlüsseln bereits zum SSH-Login - bequem und sicher.

Läßt sich das auch auf Wireguard übertragen?

Gruß,
Ingo

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Erfahrungen mit Wireguard

Beitrag von heisenberg » 03.05.2021 02:12:27

Sieht weder so aus als ob es das gibt, noch dass das irgendwann in naher Zukunft umgesetzt werden würde.

Hier ist so eine Liste möglicher Todos des Projektes:

https://www.wireguard.com/todo/
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
McAldo
Moderator
Beiträge: 2064
Registriert: 26.11.2003 11:43:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Terra / Sol-System / Milchstraße

Re: Erfahrungen mit Wireguard

Beitrag von McAldo » 11.05.2021 09:31:49

Vielleicht mal noch als Ergänzung meine configs:

Server
Dateiname: wg0.conf

Code: Alles auswählen

[Interface]
   PrivateKey = generierter_Key_des_Server
   Address = 192.168.10.1/24
   ListenPort = 4242
   Table = off

[Peer]
   PublicKey = generierter_public_key_des clients
   AllowedIPs = 192.168.10.42/32
   PresharedKey = generierter_key_fuer_Server_und_Client
Client
Dateiname: wg0.conf

Code: Alles auswählen

[Interface]
   Address = 192.168.10.42
   PrivateKey = generierter_privat_key_des_client
   DNS = 192.168.10.200

[Peer]
   PublicKey = generierter_public_key_des_server
   PresharedKey = generierter_key_fuer_Server_und_Client
   Endpoint = my.endpoint.foo:4242
   AllowedIPs = 192.168.10.0/24,192.168.11.0/24
   # Send periodic keepalives to ensure connection stays up behind NAT.
   PersistentKeepalive = 30
Keys erstellen
Server: wg genkey | tee server_private.key | wg pubkey > server_public.key
^^ Privat-Key auf Server, Public-Key auf Client

Client: wg genkey | tee client1_private.key | wg pubkey > client1_public.key
^^ Privat-Key auf Client, Public-Key auf Server

PreSharedKey: wg genpsk > client1_preshared.key
^^ dieser Key muss auf Server und Client bei PresharedKey eingetragen werden.

Wenn alles läuft, startet man das VPN auf dem Client mit:

Code: Alles auswählen

sudo wg-quick up /pfad/zur/wg0.conf
Und stoppen geht mit:

Code: Alles auswählen

sudo wg-quick down /pfad/zur/wg0.conf
Achte auf deine Gedanken, denn sie werden Worte.
Achte auf deine Worte, denn sie werden Handlungen.
Achte auf deine Handlungen, denn sie werden Gewohnheiten.
Achte auf deine Gewohnheiten, denn sie werden dein Charakter.
Achte auf deinen Charakter, denn er wird dein Schicksal.
(Talmud)

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Erfahrungen mit Wireguard

Beitrag von heisenberg » 13.05.2021 12:26:22

Als erklärende Ergänzung zu McAldos Config:

Er hat noch ein zusätzliches Sicherheitsmerkmal konfiguriert: Den Pre-Shared-Key. Ein zusätzliches Passwort zur Erhöhung der Sicherheit neben den asymmetrischen Schlüsseln.

---

Ich selbst habe noch 2 Schwierigkeiten gehabt, die ich lösen musste:

a) Zeroconf

Zeroconf hat bei mir eine default-route auf das Ethernet-Interface gesetzt. Ich bin aber üblicherweise via WLAN an dem Gerät unterwegs. Deswegen habe ich versucht das zu deaktivieren. Nachdem use-ipv4=no in /etc/avahi/avahi-daemon.conf nicht half und auch das beenden + deaktivieren von avahi-daemon.service und avahi-daemon.socket ebenso nicht, habe ich das Paket Debianavahi-autoipd gelöscht.

b) route_preserve script bringt Fehler

Mein route_preserve script bringt beim starten des Rechners Fehler. Der Grund ist wohl, dass die Default-Route zum Zeitpunkt der Ausführung noch nicht gesetzt ist. Deswegen habe ich das Script erweitert, so dass es nun so lange wartet bis ein Default-GW gesetzt ist und dann erst mit der Ausführung beginnt. Falls nach 30 Sekunden immer noch kein Default-GW gesetzt ist, bricht es ab. Das ist die Änderung:

Code: Alles auswählen

export readonly self=$(basename $0)
mylog()         { echo "$self: $*" >&2;         }
err_exit()      { mylog "$1"; exit $2;          }
get_defgw() {

        local i
        local defgw
        local maxwait=30
        for((i=1;i<maxwait;i++));do
                if [ -z "$defgw" ] ; then
                        defgw=$(/sbin/ip route show | awk '/^default/ {print $3;exit}')
                        if [ -n "$defgw" ] ; then
                                mylog "Default GW has been detected"
                                echo "$defgw"
                                return 0
                        fi
                fi
                sleep 1
                mylog "still waiting $(( $maxwait - $i )) seconds for Default-GW to show up"
        done
        mylog "No Default GW could be determined"
        return 1
}

defgw=$(get_defgw) || err_exit "Aborting because no Default-GW could be detected" 1
Hier ist das aktuelle Script: https://codeberg.org/megabert/script-pa ... e_preserve

Das Default-GW ist bei mir am Notebook ca. nach 6 Sekunden nach network-online.target gesetzt.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Antworten