VPN Zugriff einschränken

[ZuseZ3]

IST Zustand:
Mein Netzwerk besteht aus 3 relevanten Geräten:
Eine Fritzbox mit Portweiterleitung (für wireguard) auf den Pi.
Ein Pi auf dem wireguard (und PiHole) läuft .
Eine NAS auf der Nextcloud läuft.

Wireguard nutze ich für 3 Fälle:
Von extern auf die NAS zugreifen (mittels Split-vpn)
Von extern auf die FB zugreifen (Hier könnte man wohl auch die https freigabe nutzen, aber ich möchte möglichst einheitlichen Zugriff auf die Geräte und nicht den myfritz dns Namen jedes mal raussuchen müssen).
Von extern über mein Heimnetzwerk surfen (bei unsicheren WLANs oder um das Pi-hole zu nutzen)

Auf andere Geräte als die NAS und die FB muss kein einziger vpn-nutzer zugreifen können, dies ist aktuell aber möglich.

SOLL Zustand:
Familien-intern reicht das setup, jeder hat direkt oder via vpn Zugriff auf die NAS.
Nun würde ich aber gerne Freunden o.ä. auch Nextcloud Accounts anlegen und darüber Daten teilen.
Dementsprechend müsste ich ihnen aber dann auch wireguard Accounts einrichten, damit sie an die NAS rankommen.
Bevor ich das mache, möchte ich den Zugriff über VPN aber so einschränken, dass nur noch auf die NAS, die Fritzbox und ggf das Internet zugegriffen werden kann.
Besonders schön wäre es, wenn ich den Fritzbox sowie Internetzugriff nur für gewisse Wirguard Profile freigeben könnte.

Hintergrund:
Mir ist klar, das es einfacher wäre eine Portweiterleitung direkt zur Nextcloud einzurichten.
Allerdings finde ich den ganzen Cloudstack deutlich zu umfangreich und damit unsicher.
Sicherlich kann ein Admin eine NC sicher einrichten und aktuell halten, ich selbst komme aber nur zu unregelmäßig dazu.
Allen Leuten die ein VPN Zugriff bekommen traue ich natürlich grundsätzlich. Aber es kann natürlich immer was passieren (Handy verloren/abgenommen/was-auch-immer) und dann fühle ich mich deutlich wohler, wenn nur eine halbwegs gesicherte Nextcloud erreichbar ist, statt direkt die Arbeits-PCs meiner Eltern..

 

[till69]

Fixe IPs für Wireguard verwenden ... dann kann der PI mittels iptables filtern

 

[Pilatesjünger]

Jo, mehrere interfaces und entsprechend routen, aber warum. Nextcloud mit 2fa über ssl tut es doch auch.

 

[till69]

Von extern über mein Heimnetzwerk surfen

Wenn das zuverlässig und überall funktionieren soll, ist Wireguard übrigens nicht das Richtige, da UDP von vielen Firewalls geblockt wird. Hier wäre OpenVPN mit "tls-crypt" über TCP 443 zu empfehlen.

 

[ZuseZ3]

@till69
OpenVPN ist für mich keine Option. Ich benutze NC auch gerne am Handy / unterwegs und da kann openVPN nicht mithalten was Performance, Latenz u.ä. angeht.
Ich rechne nicht damit, dass irgendwer aus meinem Umfeld eine Firewall betreibt und wenn doch, sollte er dadurch in der Lage sein eine Ausnahme zu erstellen.

@shuikun Nextcloud mit 2fa und ssl ist halt zusätzlicher Aufwand und es ändert nichts daran, dass ich dann jegliche Sicherheitsupdates Zeitnah installieren muss und trotzdem Pech haben kann, wenn updates nicht oder zu spät kommen.

 

[till69]

OpenVPN ist für mich keine Option.

Doch, evtl. als Backup wenn Wireguard mal nicht geht ... z.B. in manchen öffentlichen WLANs (Hotels usw.)

 

[ZuseZ3]

Ah danke, das ist tatsächlich ein gutes Argument, das hatte ich nicht im Kopf.
Aber ich muss sagen, der zusätzliche Config-aufwand durch parallele Systeme und die bei falscher Config entstehenden Sicherheitslücken schrecken mich dann doch zu sehr ab.
Ich bin nicht so oft in öffentlichen WLANs und die WLANs die WG dann blockieren sind ja nochmal eine Teilgruppe davon. Das ist mir den Aufwand nicht wert.
Wenn dann würde ich auch eher schauen, wie ich in dem Fall UDP über TCP Tunneln kann.

 

[Raijin]

Ich rechne nicht damit, dass irgendwer aus meinem Umfeld eine Firewall betreibt und wenn doch, sollte er dadurch in der Lage sein eine Ausnahme zu erstellen.

Das meinte @till69 auch nicht. Du sprichst explizit von Fernzugriff, u.a. mobil. Es geht dabei um die Firewall des Internetgateways aka Routers. Zu Hause hat man selbstverständlich freie Hand, aber im Hotel, am Hotspot oder gar im Mobilfunk hat man keinerlei Zugriff auf den Router und dessen Firewall.

Wenn ein Hotel beispielsweise ausschließlich Surfen ermöglichen will, wird ausgehend jeder Port außer tcp 80 bzw 443 geblockt, also http/https only. Bei OpenVPN kann man Protokoll und Port frei wählen, also eben auch tcp 443 wie @till69 angesprochen hat.

OpenVPN auf tcp 443 wird durch gefühlt 99,99% aller Firewalls durchgehen, weil es wie normaler https-Traffic aussieht. Da müsste man schon mittels DPI die Pakete im Detail analysieren, um OpenVPN zu erkennen - und das erfordert reichlich Leistung, die ein normaler Router kaum bietet.

Wenn dann würde ich auch eher schauen, wie ich in dem Fall UDP über TCP Tunneln kann.

Wie sollte dir das helfen? Wenn der Port von Wireguard geblockt wird, wird er geblockt, keine VPN-Verbindung, die irgendwas tunneln könnte. Da bräuchtest du eben ein zweites VPN via tcp 443 über das du anschließend Wireguard tunneln könntest, aber dann kannst du das zweite VPN auch direkt nutzen.......

Fixe IPs für Wireguard verwenden ... dann kann der PI mittels iptables filtern

@ZuseZ3 schreibt zwar, dass er den Nutzern vertraut, spricht aber gleichzeitig explizit davon, dass ein Endgerät wie zB das Handy auch mal verloren gehen kann. Da sind fixe IPs keine relevante Hürde mehr. Grundsätzlich hättest du Recht, aber bei bewusstem Missbrauch unwirksam.

Jo, mehrere interfaces und entsprechend routen

Geht das bei Wireguard? Ich bin selbst stets auf OpenVPN unterwegs und hatte mit Wireguard im speziellen bisher nur wenig Berührungspunkte. Grundsätzlich ist die Idee dahinter aber goldrichtig.

Wenn man zwei separate Instanzen eines VPN-Servers einrichtet, sind das zwei gänzlich voneinander getrennte VPNs, die auch vollumfänglich und von Seiten der Clients nicht zu umgehen sind. Ich hab zB auch 2x OpenVPN laufen, einmal mit Vollzugriff für mich selbst und einmal ausschließlich für bestimmte Teile meiner Netzwerke für die Standortverbindungen zwischen den Wohnungen meiner Familie. Selbst wenn jemand wollte, könnte er vom Familienzugang niemals auf die geschützten Teile meines Netzwerks zugreifen, weil der Zugang in einem völlig anderen VPN-Netzwerk liegt, das durch meine Firewall reglementiert ist - egal ob der VPN-Nutzer am anderen Ende mit IP-Adressen oder Routen rumspielt. Dazu bräuchte derjenige schon ein Zertifikat für mein Admin-VPN.

 

[Bob.Dig]

Sehe es wie @Raijin , einfach zwei VPN-Server aufsetzen.
Bei dir scheint sich alles um Wireguard zu drehen. Willst Du das jetzt auch bei allen Freunden installieren? Vermutlich ja, aber das wird vielleicht auf wenig Gegenliebe stoßen. Nextcloud kann man als virtuelle Appliance runterladen oder auf dem Pie installieren, diese sollten sich dann selbständig updaten. Ob es natürlich den Aufwand wert ist...
😆 Stelle gerade fest, dass ich auf meine NC nicht mehr zugreifen darf und sie sich beschwert, sie sei nicht aktualisiert worden. Von der Kommandozeile geht es aber auch nicht so wie gedacht. Nextcloud ist schon ein Krampf. Deswegen habe ich da auch so gut wie nix drin. 😁

 

[ZuseZ3]

😆 Stelle gerade fest, dass ich auf meine NC nicht mehr zugreifen darf und sie sich beschwert, sie sei nicht aktualisiert worden. Von der Kommandozeile geht es aber auch nicht so wie gedacht. Nextcloud ist schon ein Krampf. Deswegen habe ich da auch so gut wie nix drin. 😁

Und genau deswegen kommt meine nicht direkt ans Netz
Und die Freunde die darauf zugreifen sind entweder so wie ich infos oder werden direkt von mir an die Hand genommen. Und die Wireguard app installieren und mit ihr nen QR Code einscannen sollte btw. wohl auch jeder nicht-info ohne Hilfe schaffen.

[snip]
Rest hat sich erledigt, siehe unten

 

[ZuseZ3]

@Raijin Du hattest was davon geschrieben die fixen IPs zu hintergehen, aber am Ende angemerkt selbst nicht WG zu nutzen. Hast du dich da vielleicht vertan, oder kannst du das genauer ausführen? Ich habe mal versucht bei einzelnen Clients, die sich laut config auf z.B. 10.0.6.2 verbinden sollten, diese auf 10.0.6.3 (vergeben an anderen inaktiven client) bzw. 10.0.6.4 (nicht vergeben) zu ändern. Eine Verbindung fand in keinem Fall statt.
Demnach scheint WG ja zu verlangen, dass ein Verbindungsversuch mit einem bestimmten Key immer auf der im server hinterlegten ip erfolgt und weißt andere verbindungsversuche ab.
Damit kann ich aber doch einfach davon ausgehen, dass hinter 10.0.6.17 IMMER der selbe Peer steckt und diesen einfach per iptable einschränken, ohne mehrere Interfaces zu nutzen, oder sehe ich da was falsch? Immerhin könnte ich dann auch weiterhin alles angenehm über pivpn managen.

 

[Raijin]

Ich kann bezüglich WireGuard nur anhand der grundsätzlichen Netzwerkmechanik urteilen und da ist es nun mal so, dass eine Firewall, die einzelne IPs in ihrem eigenen Subnetz blockiert, unwirksam wird sobald der fragliche Client seine IP ändert - sei es manuell oder nach abgelaufenem DHCP-Lease. Auch statisch reservierte IP-Adressen im DHCP ändern daran nichts, weil DHCP stets nur ein Angebot ist, das der Client auch ablehnen kann. Allerdings gibt es einen entscheidenden Unterschied zu einem VPN: In einem herkömmlichen Netzwerk gibt es keinen zentralen Knoten, über den sämtliche Verbindungen laufen, weil Clients auch direkt über die Switches kommunizieren können, ohne den Router und dessen Firewall dazwischen - das gilt auch für den Switch im Router.
Bei VPN ist das etwas anders, weil der Server immer aktiv zwischen den Clients agieren muss.

Es mag daher sein, dass WireGuard intern eigene Mechanismen hat, einzelne Clients zu reglementieren. Eventuell ist das schlichtweg ein banaler Plausibilitätscheck, der prüft ob eingehende Pakete von Client X auch mit der SRC IP getagged sind, die für diesen Client vorgesehen war. Somit könnte der Client seine IP zwar ändern, der Server würde dies aber bemerken und blockieren. Bei WireGuard weiß ich nicht ob das so ist, bei OpenVPN habe ich das vor vielen Jahren und Versionsnummern mal ausprobiert und da ging es zumindest. Heißt: Ich konnte am OpenVPN-Client die IP ändern und so die Firewall im Server umgehen. Ob das immer noch so ist, werde ich tatsächlich gleich mal ausprobieren.

Generell wäre ich dankbar, wenn wir es jetzt mit OpenVPN und anderen Sachen gut sein lassen könnten.

So funktioniert ein öffentliches Forum aber nicht. Es lebt von einer Diskussion, die auch andere Wege aufzeigt - insbesondere, wenn der Fragende diese Wege gegebenenfalls gar nicht kannte. Wenn man keine anderslautenden Antworten wünscht, ist man in einem öffentlichen Forum an der falschen Adresse. Was meinst du in wie vielen Threads hier sinnbildlich danach gefragt wird wie man von A nach B kommt, aber im weiteren Text so ziemlich alle potentiellen Antworten bereits im Vorwege ausgeschlossen werden - nicht zu Fuß, mit dem Fahrrad, Motorrad, Auto, Bus, Bahn, Schiff oder Flugzeug. Eine Diskussion muss offen geführt werden können, sonst ist sie sinnlos.

Ergänzung (30. Dezember 2020)

WTF?! Ich nehme alles zurück. Zumindest mit OpenVPN geht das nicht (mehr). Sobald ich bei einem OpenVPN-Client die IP ändere, tauchen beim Server Meldungen auf wie diese hier: "Bad source address from client, packet dropped". Das heißt, dass der Server merkt, dass die Absender-IP nicht die ist, die der Client haben sollte. Seit ich das damals getestet hatte wurde das offenbar im Laufe der Zeit ergänzt. Da WireGuard deutlich moderner ist, gehe ich davon aus, dass ein ähnlicher Mechanismus verbaut ist. Das kann ich in meinem Labornetzwerk aber zZt nicht testen, weil ich dort nur ein OpenVPN-Setup laufen habe und um fast 4 Uhr nachts kein WireGuard mehr einrichten werde

Unter diesen Umständen muss ich meine Aussage von oben revidieren. Es kann durchaus sein, dass das mit WireGuard so funktioniert.