[ARTIKEL] Quick Guide - Wireguard Server auf QNAP einrichten

tiermutter

Well-known member
[PROLOG]
Seit QTS 5.0 wird das Wireguard VPN Protokoll unterstützt, da kam schnell die Frage auf, wie man dies einrichtet. Die Oberfläche in der QVPN App habe ich mir beim Test von QTS 5 bereits angeschaut und bin daher der Meinung, dass die Einrichtung kein Hexenwerk sein kann. Ob ich richtig liege will ich in dieser Schnellanleitung herausfinden.

[VORBEREITUNGEN]
Voraussetzung ist, dass der QVPN Service im App Center unter QTS 5.0 oder höher installiert ist, in diesem Fall ist es die Version 3.0.739.
Außerdem muss eine Portweiterleitung/ -Freigabe in der Firewall eingerichtet sein, der Standardport ist 51820.

[SERVER ERSTELLEN]
Zunächst muss der Server durch Setzen des Häkchens aktiviert werden. Anschließend erstellt man ein Schlüsselpaar durch Klick auf den entsprechenden Button und gibt dem Server einen Namen. Dann wählt man den gewünschten DNS Server, entweder mit Hilfe des Wizards oder man trägt ihn manuell ein. Ich verwende hier meine Firewall als DNS Server, wie ich es für alle Geräte tue.

WG_Server.PNG

Die Änderungen werden durch einen Klick auf „Apply / Übernehmen“ angewendet und der Server steht schonmal.

[CLIENTS/ PEERING]
Anschließend muss das Peering für die Clients erstellt werden, hier werden sozusagen die User angelegt. Ich mache das unter Windows 10 mit der Wireguard App.
Mit einem Klick auf „neuen leeren Tunnel erstellen“ wird der Tunnel erstellt, dabei wird automatisch ein Public Key erstellt, den wir gleich noch benötigen.

WG_Client.PNG

Außerdem müssen noch ein paar Daten ergänzt werden:
Interface
Adress gibt an, welche IP Adresse aus dem Wireguard-Netz der Client erhalten soll, diese muss mit dem Adressbereich des Servers übereinstimmen.
DNS gibt nochmal an, welcher DNS Server verwendet werden soll, ich bin mir nicht sicher ob das hier zwingend sein muss.
Peer
PublicKey hier muss der der PublicKey des WG Servers eingetragen werden.
AllowedIPs gibt an, welche IP Adressen getunnelt/ geroutet werden sollen (und welche somit über den Tunnel erreicht werden können), das sind im Beispiel alle, sollte aber unbedingt angepasst werden, denn es macht natürlich wenig Sinn, alle IP Adressen durch den Tunnel zu routen, da sonst das gesamte Lokale Netzwerk nicht mehr erreichbar ist. Für den Anfang sollte es genügen hier den Adressbereich des VPN Tunnels anzugeben (Zugriff nur auf VPN Teilnehmer) und später des entfernten LANs um auch darauf zugreifen zu können.
Endpoint ist die IP Adresse/ der DNS mit Port unter der der WG Server erreicht wird. Bei mir ist das nur mit IPv6 möglich, daher auch die eckigen Klammern, die bei v4 Adressen nicht benötigt werden.

Jetzt muss nur noch das Peering auf Seiten des Server erstellt werden.
Hierzu klicken wir in den WG Einstellungen vom QNAP auf „Add Peer“, geben dem Kind einen Namen und fügen den Public Key aus dem Client ein.

WG_peer.PNG

Nochmal gespeichert war es das dann schon und der QNAP kann unter der eingestellten IP Adresse erreicht werden, wenn man mit dem VPN verbunden ist.

[EPILOG]
Ich habe mich mit dem Wireguard Protokoll noch nicht richtig auseinandergesetzt, die beschriebene Konfiguration ist daher nur ein Minumum der Möglichkeiten, so fehlt z.B. ein ordentlichen Routing, damit auch andere Geräte (mit ihrer LAN IP) als nur der QNAP angesprochen werden können.
Dennoch muss ich feststellen: Die Einrichtung ist tatsächlich kein Hexenwerk, für die erweiterte Konfiguration muss man sich aber wie bei allem etwas mit der Materie auseinandersetzen, heimnetz.de kann da sicherlich weiterhelfen :)
 
Zuletzt bearbeitet:

tiermutter

Well-known member
So, hier dann der Artikel für die Einrichtung der Clients:
 

Zachi66

New member
Hallo Tiermutter,

ich habe das Ganze von Dir durchgelesen und bei meinem Qnap so umgesetzt, wie von Dir beschrieben. Zudem habe ich auf meinem Router (FB) folgendes eingerichtet:

-QNAP bekommt immer gleiche IP-Adresse (Netzwerkreservierung)
-IP-Routing aus dem eigenen Netz 192.168.x.x auf die IP-Adresse des NAS + IP-Forwarding aus dem VPN-Netz 192.168.y.y. auf IP-Adresse des NAS
-NAT-eintrag für den UDP Port 58120....intern/extern.

Der Verbindungsaufbau kommt vom W10-Client kommt zwar zustande, aber es werden keine RX-Pakete empfangen (0 bytes) TX-Pakete gehen raus. Im Logfile des Windows 10 VPN-WG-Clients steht in regelmäßigen Abständen der folgende Eintrag

"2021-12-dd hh:mm:ss.151: [TUN] [XY_Blub_Full_tunnel] Handshake for peer 1 (WA.N.IP.x:58120) did not complete after 5 seconds, retrying (try 2)

Die W10 Firewall habe ich zwar im Verdacht, habe aber diese testweise deaktiviert -ohne Erfolg... Von einem Android-Handy aus gelingt mir der vollwertige Connect ebenfalls nicht. Die Log-Dateimeldung darin lauten alle 2 sec. Handshake did not complete after 5sec.... und "a resource failed to dispose".....

Auf dem WG-Server in den Verbindungsprotokollen bei bestehender Verbindung nichts protokolliert. Die PINGs auf WG-Server oder Router gehen bei bestehender Verbindung des VPN-CLients ins Leere...Nur der PING auf die eigene VPN-IP bekomme ich TTLs....

Auf dem QNAP kann man im QVPN Service 3 (v3.0.760) unter VPN-Verbindungsprofile "VPN als NAS-Standard-Gateway verwenden"; aber auch das hatte ich schon vergeblich versucht.

Ich habe jedoch keine VPN-Profile definiert sondern, lediglich unter "WireGuard" den Server aktiviert + die entsprechenden Peers mit deren Key & IPs angelegt....

Und ein Routing wie bspw. einem Raspi kann ich m.W. im Qnap via Console nicht einfach so hinterlegen, oder etwa doch...? Und wenn ja wie.....?

Muß ein Preshared-Key zwingend angegeben werden...?

Weiß jemand Rat, wie ich den Android bzw. W10-Konfig anpassen muss, damit ich ich einen sauberen VPN-Connect hinbekomme. Entweder sind es noch Einstellungen auf dem Router, die noch anzupassen sind oder in den VPN-Client-Konfig-Dateien.

Ich bin für jeden Vorschlag dankbar und kann ggfs. auch fehlende Daten nachliefern...

ZachiW
 

tiermutter

Well-known member
Versuche bei den allowed IP clientseitig mal
Code:
0.0.0.0/1, 128.0.0.0/1
. Bei Windows 10 klappt es bei mir nur so, da die default Route (0.0.0.0/0) offensichtlich nicht überschrieben wird. Bei Android war es das nicht erforderlich, allerdings bekomme ich unter Android seit einigen Tagen auch keine Verbindung mehr hin. Nutze aber auch nicht den WG Server auf QNAP... Das Traurige an WG ist ja, dass es keine ordentlichen Logs für die Fehlersuche gibt und nie richtig klar ist, ob die Verbindung korrekt aufgebaut wurde und es ein routing Problem ist oder bereits die Verbindung scheitert. Ist die QuFirewall am QNAP aktiv? An der Fritte muss eigentlich nichts weiter gemacht werden, als die Portfreigabe zum QNAP.
 

MarkusAT

Member
Hi @tiermutter,

ich hab mir mal diese Anleitung, und auch diese des Windows 10 Clients durchgelesen.
So, wie hier eh alle wissen, läuft mein VPN aktuell noch QNAP to QNAP. Ganz selten logge ich mich mal von außen über einen Windows OpenVpn ein.
Also, OpenVPN zum testen mal gekillt, ein Wireguard Server soll her. Für mich der Vorteil wie Du mir beschrieben hast, man kann die Client IP festlegen. Da bei meinen Eltern immer wieder mal das Internet wegen schlechtem Wetter (Schneesturm, LTE) weg ist, wäre das ganz praktisch. OpenVPN wechselt bei mir immer zwischen 2 IP's hin und her (warum auch immer).
Nach 10 Minuten: Die Verbindung steht, soweit, so gut :D (Danke für Deine Anleitung, vor allem welche Schlüssel wo hin muss).
Die Verbindung ist zwar deutlich langsamer (warum auch immer, aber vl ist aktuell auch einfach nur das Internet schlecht, oder mein älterer Herr macht sonst was im Netz ^^). Die Verbindung ist doch (exakt) gleich schnell. ~1,2 MB/s (was ziemlich gut meinen Upload von 10 MBit entspricht).

Auf Serverseite sieht das ganze so aus:
  • Servername suche ich mir aus (Server1)
  • Privaten und öffentlichen Schlüssel generiere ich
  • IP-Adresse ist der VPN-Server-Bereich (Bsp. 10.0.0.1/24)
  • Empfangsport ist der, den ich dann auch im Router freigebe
  • DNS muss einfach eine Verbindung ins Netz sein
  • Neuer Peer
    • Peername suche ich mir aus (Client1)
    • Öffentlicher Schlüssel nehme ich den, der auf Clientseite generiert wurde
Wo ich Serverseitig noch Probleme habe:
  • Ich möchte einen Preshared-Key verwenden (wenn ich das richtig verstehe, macht dass das Ding noch sicherer, weil man neben 2 verschiedenen öffentlichen Schlüssel auch noch einen 3., den Preshared-Key bräuchte. Egal was ich hier eintippe, es ist immer rot. Der will natürlich ein bestimmtes Format (32-Byte im Base64 Format) haben.
    Kann ich mir den auch wo generieren lassen?
  • Was trage ich beim Endpunkt auf Serverseite wirklich ein. Was hab ich für Vor-/Nachteile, wenn ich das leer lasse?

1642200518090.png
1642200586696.png


Auf der Clientseite so:

  • Servername suche ich mir aus (im Optimalfall wieder Server1)
  • Privaten und öffentlichen Schlüssel generiere ich
  • IP-Adresse ist wieder ein Bereich (Bsp. 10.0.0.2/32)
  • Empfangsport habe ich hier leer gelassen, es geht trotzdem
  • DNS muss einfach eine Verbindung ins Netz sein
  • Peer Settings:
    • Öffentlicher Schlüssel nehme ich jetzt den vom Server her
    • Endpunkt ist die öffetnliche IP meines Router auf der Serverseite:port der weitergeleitet wird, Sprich der, der auf dem Server gewählt wurde

Meine Probleme auf Clientseite:
  • Wo wird die genaue IP des Clients festgelegt? Die IP-Adressen sind ja wieder ein Bereich (2/32) oder? Warum hier eigentlich /32 und beim Server /24
  • Was hat es jetzt mit den zulässigen IP's auf sich. aktuell steht 0.0.0.0 drinnen, was ja eher suboptimal zu sein scheint.

1642201884044.png
1642200674402.png

Und noch allgemeine Fragen:
In den Verbindungprotokollen von QVPN sehe ich immer nur die OpenVPN Verbindungnen und auch im Überblick sehe ich beim WireGuard keine Verbundenen Benutzer (wenn OpenVPN läuft, sehe ich, dass der verbunden ist. Ist das ein bekannter Bug? Oder mache ich was falsch? Der Sync über RTRR läuft aber gerade erflogreich ab, also die Verbindung steht definitiv.
1642202244019.png

Wie kann ich also überhaut sehen, dass die Verbindung aktiv ist?
Letzter Handshake ist über 15 Minuten her, obwohl das Keepalive auf 10 Sekunden steht (brauchts das überhaupt)?

So, Danke euch allen wieder mal für eure hilfreichen Tipps und Antworten.

Liebe Grüße,
Markus (der sich wünschen würde, dass ein Netzwerk so einfach wie ein Flugzeug funktionieren würde :D)
 
Zuletzt bearbeitet:

tiermutter

Well-known member
man kann die Client IP festlegen. Da bei meinen Eltern immer wieder mal das Internet wegen schlechtem Wetter (Schneesturm, LTE) weg ist, wäre das ganz praktisch.
Dürfte in diesem Fall eigentlich und nur theoretisch egal sein, da der Server (so meine Erfahrung) den Clients ohnehin immer die gleiche IP zuweist. Ist halt wie DHCP... eigentlich gibt es immer die gleiche Adresse wenn sich der Client verbindet... eigentlich... wer weiß das schon?
Ich möchte einen Preshared-Key verwenden
Damit habe ich keine Erfahrungen, da ich ihn nicht verwende. Auch nutze ich den WG Server auf QNAP nicht... scheint auch gar nicht so einfach zu machen sein, es läuft irgendwie immer auf Folgendes hinaus: https://www.reddit.com/r/WireGuard/comments/pf40bl/wireguard_preshared_key_whats_required/ (endet mit Fragezeichen).
Auch die manpage von WG sagt nichts Relevantes darüber aus. Also: keine Ahnung :)
Was trage ich beim Endpunkt auf Serverseite wirklich ein. Was hab ich für Vor-/Nachteile, wenn ich das leer lasse?
Nuja... keine Ahnung! Das ist ja das Schlimme an WG und seinen mMn völlig verwirrenden oder zumindest nicht aussagekräftigen Konfigurationsmöglichkeiten!
Ich habe meinen WG Server auf der OPNsense, hier gibt es "Endpoint Address" und "Endpoint Port". Keine Ahnung was bei QVPN gemeint ist, bei mir ist die Angabe des Ports obligatorisch, sofern ein anderer als der Default Port verwendet wird. Was die andere Option macht weiß ich nicht, auch erschließt sich mir nicht wozu es überhaupt diese Option mit dem Port gibt (mal abgesehen davon, dass ich es nur durch Foren herausfinden konnte, wo die User es auch nur durch try-and-error herausgefunden haben).
Wo wird die genaue IP des Clients festgelegt? Die IP-Adressen sind ja wieder ein Bereich (2/32) oder? Warum hier eigentlich /32 und beim Server /24
Die wird unter "IP Adresse" festgelegt. Warum das sowohl auf Server- als auch Clientseite erfolgt??? Weiß der Teufel! Die WG Konfig ist halt irgendwie konfus und irreführend.
/32 ist kein Bereich sondern eine Host-IP. 10.8.8.8/32 beinhaltet also genau nur diese eine IP. Und genau diese soll dem Client ja zugewiesen werden, nicht ein ganzer Bereich. WG stellt sich da aber scheinbar auch ein bisschen an, schließlich geht es um eine Host-IP, da sollte eigentlich jede Anwendung wissen was gemeint ist, egal welches Subnet dahinter angegeben ist.
Die /24 am Server hingegen bedarf es, damit der WG Server weiß aus welchem Adressbereich er überhaupt Adressen verteilen soll. Hier ist die Angabe /24 also sogar obligatorisch. Ich verwende für meine VPN (ich habe mehrere) /27 Netze, damit verwendet zB VPN-Server 1 den Bereich 10.13.18.0-31 und Server 2 10.13.18.32-63.
Bei Bedarf bietet sich ein IP Rechner an um das mit den /xx (CIDR Suffix) bzw. Netzmasken mal durchzuspielen: https://www.heise.de/netze/tools/netzwerkrechner/
Was hat es jetzt mit den zulässigen IP's auf sich. aktuell steht 0.0.0.0 drinnen, was ja eher suboptimal zu sein scheint.
0.0.0.0/0 (hier ist der CIDR Suffix wieder megawichtig) bedeutet IP-technisch "alles". Mit dieser mal wieder megamäßig beschissen beschriebenen Einstellung wird (Clientseitig!!!) festgelegt, was alles durch den Tunnel geroutet werden soll (wenn nicht bereits vorhandene "bessere" Routen was anderes festlegen), also welche Netze über das VPN erreichbar sein sollen. Mit "alle" (0.0.0.0/0) werden auch Anfragen ins Internet über das VPN geleitet, das will man zB immer dann wenn man unterwegs ist und sich mit Hotspots in Hotel, Cafe, etc. verbindet, damit niemand mitschneiden kann was Du machst. Für Deinen Fall würde es therotisch reichen, hier nur Dein LAN-Netz anzugeben, also zB 192.168.174.0/24.
sehe ich beim WireGuard keine Verbundenen Benutzer (wenn OpenVPN läuft, sehe ich, dass der verbunden ist. Ist das ein bekannter Bug?
Das habe ich auch schon festgestellt und irgendwo beschrieben, wahrscheinlich in einem QNAP Blog. Das kann nur ein Bug sein, bzw.... so konfus wie sich WG darstellt hat QNAP es wohl nicht ordentlich hinbekommen :D
Wie kann ich also überhaut sehen, dass die Verbindung aktiv ist?
Das ist überhaupt schwierig mit WG... dem fehlt halt noch einiges!
Letzter Handshake ist über 15 Minuten her, obwohl das Keepalive auf 10 Sekunden steht (brauchts das überhaupt)?
An der Einstellung habe ich noch nicht gerüttelt, habe nichtmal einen Wert angegeben... wer weiß was der bei WG bezweckt?! ;) :D

So, nun gehe ich aber ins Bett :)
 

MarkusAT

Member
Dürfte in diesem Fall eigentlich und nur theoretisch egal sein, da der Server (so meine Erfahrung) den Clients ohnehin immer die gleiche IP zuweist. Ist halt wie DHCP... eigentlich gibt es immer die gleiche Adresse wenn sich der Client verbindet... eigentlich... wer weiß das schon?
Naja, immerhin OpenVPN wechselt bei mir immer zwischen 2 Adressen hin und her, x.x.x.6 und x.x.x.10, obwohl es nur einen einzigen Client gibt :O

Also: keine Ahnung :)
Ich fühle mich verstanden :D

Keine Ahnung was bei QVPN gemeint ist, bei mir ist die Angabe des Ports obligatorisch, sofern ein anderer als der Default Port verwendet wird.
Naja, ich habe beim Server einen "eigenen" Port freigegeben, also nicht den Standardport, kann das aber trotzdem leer lassen (also auf Client Seite, auf Server Seite habe ich eben nicht den Standardport gewählt, daher eben auch meine Verwunderung).

Bei Bedarf bietet sich ein IP Rechner an um das mit den /xx (CIDR Suffix) bzw. Netzmasken mal durchzuspielen: https://www.heise.de/netze/tools/netzwerkrechner/
Die /24 und /32 kann ich gar nicht ändern, diese sind fix vorgegeben. Danke für den Rechner, also, wenn ich das richtig verstehe:
192.168.0.xxx/24 ==> Bereich von .1 bis .255
192.168.0.xxx/32 ==> genau .xxx
192.168.9.xxx/27 ==> gibt mir 30 Clients (1-30, 33-62, 65-94, etc...

https://www.heise.de/netze/tools/netzwerkrechner/
Für Deinen Fall würde es therotisch reichen, hier nur Dein LAN-Netz anzugeben, also zB 192.168.174.0/24.
Das der VPN aber (aktuell) von NAS to NAS geht, ist das (fast) egal. Heißt also, wenn NAS_AT mit NAS_DE verbunden ist und ein Auto Dropbox Backup macht, läuft das über Internet_DE? Die generelle Internetverbindung von AT bleibt aber in AT (da die ja nicht über das NAS läuft).

Das habe ich auch schon festgestellt und irgendwo beschrieben, wahrscheinlich in einem QNAP Blog. Das kann nur ein Bug sein, bzw.... so konfus wie sich WG darstellt hat QNAP es wohl nicht ordentlich hinbekommen :D

Das ist überhaupt schwierig mit WG... dem fehlt halt noch einiges!
Okay, Danke Dir :)
Ich fasse also zusammen:
- kann (evtl) unfassbar viel, aber eine vernünftige Doku (generell für WG, noch genereller für das QNAP WG) fehlt einfach :)
- ich bin gar nicht so dumm wie ich dachte, immerhin läuft das Ding stabil
- ich bleib, vorerst, doch bei OpenVPN (was vor allem für meine HW-Auswahl wichtig ist)

Was ich aber auch festgestellt habe. Mit WG ging auch mein NAS_DE nie mehr aus, besser gesagt alle paar Sekunden schrieben die HDD's (auf Dauer nervig im Wohnzimmer, weil man 24h den Schreibkopf hört). Überlegt, was habe ich verändert... Hm, klar, OpenVPN auf WG. Logs geöffnet und siehe da, direkt im Kernel log:
1642330950156.png
 

tiermutter

Well-known member
Das das NAS nicht schläft kommt sicherlich vom keepalive. Bei OVPN kannst du dir ggf so behelfen, dass der Server nur aus einem adressraum von zwei IPs verteilt... Also zB 10.8.0.1 für den Server und 10.8.0.2 für das Client NAS. Wenn du einen weiteren Zugang zB für dich selbst brauchst, geht das natürlich nicht auf, da könntest du dann WG nehmen, da man ja nur einen OVPN Server auf QNAP erstellen kann.
 

MarkusAT

Member
Das das NAS nicht schläft kommt sicherlich vom keepalive.
Nicht schlafen bin ich ja schon gewohnt, aber dauernd schreiben ist dann nochmals nerviger ^^

Bei OVPN kannst du dir ggf so behelfen, dass der Server nur aus einem adressraum von zwei IPs verteilt...
Leider nein, da ausgegraut:
1642336986900.png
Aber anderes Thema, ich will jetzt nicht deinen tollen WG-Guide für OVPN Problemlösungen kapern.
Spätestens wenn der OVPN-Server extern läuft, kann ich den OVPN Server auch vernünftig einstellen.

Danke auf jeden Fall für die Hilfe, so kann ich mir im Fall der Fälle immerhin einen WG-Server basteln.
 

Zurzeit aktive Besucher

Keine Mitglieder online.

Letzte Anleitungen

Statistik des Forums

Themen
937
Beiträge
13.660
Mitglieder
466
Neuestes Mitglied
wischi83
Oben