VPN - "Kill-Switch" über IPtables

[manudrescher]

Guten Morgen

Ich fasse kurz die Netzwerkkonfiguration zusammen, das macht es wohl deutlich einfacher:

DSL-Router (FritzBox 7490)
IP: 192.168.2.1/24

DS115
IP: 192.168.2.222/24
GW: 192.168.2.1

Clients
Beziehen ihre Konfiguration per DHCP von der DS, das Gateway ist hier ebenfalls die DS mit der 192.168.222

Zusatzinfos:

-Prävention gegen DNS-Leaks ist in Bezug auf die Zuweisung entsprechender, öffentlicher DNS-Server bereits berücksichtigt.
-Ich muss zwangsweise den DHCP-Server der DS verwenden, da eine FritzBox es per DHCP nicht erlaubt, ein anderes Gateway als sich selbst zu vergeben


Ausgangssituation:

Auf der DS läuft der VPN-Client mit gemeinsamer Nutzung. Alle Clients im Netz nutzen die DS als Gateway und gehen getunnelt über den VPN ins Netz. Soweit so gut.
Jetzt besteht die "Herausforderung", dass bei Abbruch/Abbau des VPN-Tunnels die DS den Traffic "stumpf" und verzugslos dann über ihr reguläres Default-Gateway (also die FritzBox auf 192.168.2.1) "routet".

In der Praxis extrem ungünstig, denn (reproduzierbar) geschieht dies nahtlos, bei Abbruch/Abbau des VPN-Tunnels geht der Client ungetunnelt ins Netz und dies ist für den Nutzer nicht transparent.


Behelfslösung
So einfach wie "genial", als derzeitigen Kill-Switch nutze ich die Kindersicherung der FritzBox^^
Sprich alle Clients sind für die Internetnutzung gesperrt, ausgenommen die Synology.

In der Praxis kann nun jeder Client bei laufendem VPN durch die Syno einwandfrei ins Netz....wird der Tunnel abgebaut und die Syno routet stumpf durch -> kein Internet und "aus die Maus".
Wird der Tunnel wiederhergestellt, besteht wieder getunnelter Zugriff.

Ziel:
Das mit der Kindersicherung funktionier zwar einwandfrei...ist aber in meinen Augen doch "unsauber".

Daher wollte ich das direkt auf der DS per IPtables lösen.

Ich weiß auch das es geht und das wohl nur ein paar Zeilen sind...aber mein Kung-Fu ist hier leider nicht stark genug.

Mein Königsweg wäre, dass die DS den Traffic der Clients ausschließlich auf die VPN-Schnittstelle (tun) bläst und bei Abbau/Verbindungsverlust des Tunnels keinen Traffic der Clients auf die 192.168.2.1 zulässt.
Die DS selbst muss natürlich dieses Gateway nutzen können, sonst kann sie über die FritzBox ja keinen Tunnel aufbauen.

Und wenn das Ganze dann auch noch so gesetzt wird, dass die IP-Tables auch beim einem Neustart erhalten bleibt...dann hätte ich daheim das "VPN-All-in-One-Action-Paket"

Ich habe mich auch schon mit den tables rumgeschlagen...aber ich bin wohl dafür einfach zu doof.

Grüße

 

[mexx81]

Da hast Du Dir aber irgendwie eine Vergewaltigung gebaut oder willst es. Wieso machst Du VPN Tunnel Deiner Clients im LAN zum VPN Server im LAN auf? Ja es geht, aber entspricht nicht unbedingt dem Grundgedanken von VPN. Du bist ja schon im LAN, wozu ein weiteres Virtuelles Privates LAN aufmachen? Ich nutze den VPN Server, wenn ich ausserhalb meines LANs im Hotel bin und eine sichere Verbindung zum Server haben will, aber wenn ich im LAN bin, ist das doch unnütz.

Wenn es Dir darum geht, dass alle Clients die DS zum surfen nehmen, nutze doch das Paket Proxy Server. Wenn Dir das nicht gefällt, nutze den DNS Server mit Weiterleitung zum DNS der Fritzbox.

Ich habe selber viel und oft mit den IPTables gespielt, lasse sie aber mittlerweile in Ruhe. Bei Updates werden Sie überspielt und um sie bootfest zu machen, müsstest Du die Autostartdateien der DS bearbeiten.

Dein Ziel hab ich noch nicht ganz verstanden, aber VPN im LAN sehe ich nicht als richtigen Weg. Dann doch eher Proxy oder DNS. Aber eigentlich ist die DS kein Router. Was Du brauchst ist ein Router. Gerne den von Synology, aber vergewaltige doch Dein NAS nicht zum Router.

 

[manudrescher]

Hallo,

ich sehe das nicht als "Vergewaltigung", wenn eine DiskStation von Synology es "out of the box" anbietet, den gesamten Traffic aller Netzteilnehmer durch einen VPN zu pusten und sozusagen als "VPN-Gateway" agiert.

Eigentlich ist dies sogar ein großer Mehrwert.
Ich nutze grundsätzlich auf meinem "Hauptrechner" einen VPN-Client eines VPN-Anbieters um getunnelt ins Netz zu gehen. Das ist auch kein exotischer Anwendungsfall, sondern ist bei vielen "IT-Affinen" mit einer gewissen Sensibilisierung schon fast ein Standardfall.

Und diese - von Synology angebotene Leistung - erlaubt es, allen Teilnehmern im Heimnetz einen VPN-Zugang zum Netz zu verwenden.

Ich "frickel" mir nichts zusammen, die DS bietet dies regulär an.
Nur da sie hier als Gateway funktioniert, leitet sie den Traffic "gut gemeint" bei Ausfall des VPN-Tunnels an ihr Default-Gateway...und das ist meinerseits nicht gewollt.

 

[mexx81]

Du sagst es selbst. Du nutzt Deinen Rechner als VPN-Client um Dich mit einen extern stehenden VPN-Anbieter zu verbinden. Damit nutzt Du VPN so, wie es gedacht ist.



Quelle: https://de.wikipedia.org/wiki/Virtual_Private_Network

Die von der DS angebotene VPN Funktion ist da, aber eben um aus dem Internet darauf zuzugreifen. Hier ein Auszug aus der Hilfe des VPN Servers.




Oder schau Dir das mal an. Eine Info zum Thema VPN Server von Synology.

https://www.synology.com/de-de/knowledgebase/DSM/tutorial/Application/How_to_connect_to_Synology_s_VPN_Server_using_a_Windows_PC_or_Mac

Bitte glaube einen erfahrenen "IT-Affinen", VPN ist in der Regel nicht für diese Zwecke gedacht.

Ich verweise noch mal auf den Proxy Server, DNS Server oder einen zweiten Router. Selbst VLAN wäre eine bessere Lösung. Ich empfehle die einen managed Switch mit VLAN Option.

 

[MMD*]

Hallo,

Missverständnis @mexx81 ?

LAN-Clients--->DS-OVPN-Client--->Tunnel--->OVPN-Anbieter--->Internet

@manudrescher mochte eine Fail Safe haben sodass bei Ausfall OVPN Verbindung den Zugang ins Internet blockiert wird.

Das hat er jetzt über die Kinder Sicherung mochte das aber anders losen.

 

[mexx81]

So wie ich Ihn verstanden habe:

LAN-Client -> VPN-Client -> Diskskation -> Internet

Für mich macht eine VPN Verbindung der LAN Clients zum LAN VPN Server keinen Sinn, weil für mich ein VPN zum Verbinden mehrerer per Internet getrennter Netze zuständig ist. Um den Netzwerkverkehr im LAN zu reglementieren ist ein LAN Proxy, DNS, Router, managed Switch mit VLANs geeigneter.

 

[jahlives]

solange der VPN Client auf der DS läuft wird das nie ganz zuverlässig funzen. Natürlich kannst du allen Clients im Netz als default GW via dhcp die IP der DS geben. Wenn du dann aber den "Kill Switch" auf der DS aktivierst, was hindert denn den Client daran als default GW einfach die IP der Fritte anzugeben und damit ohne VPN ins Netz zu kommen? Dieser Traffic würde ich nicht via DS gehen und wäre daher vom "Kill Switch" nicht betroffen.
Der einzig saubere Weg ist es den OpenVPN Client auf der Fritte (dem default Gateway deines LANs) zu haben. Dann kannst du mittels Firewall recht einfach sagen, dass ausser dem Traffic der DS, keinerlei Traffic raus darf solang der VPN nicht oben ist

 

[Iarn]

Ganz dumme Frage, aber wäre es nicht einfacher zwei getrennte Subnetze zu machen: Eins mit Fritte und Syno und eins mit Syno und den Clients. Dann müssen die Clients über VPN auf der Syno gehen, da die Syno weder switched noch routed.

Fritzbox <--- > Synology Port 1 | Synology Port 2 <---> Switch <---> Clients

 

[manudrescher]

Hallo,

...
LAN-Clients--->DS-OVPN-Client--->Tunnel--->OVPN-Anbieter--->Internet
...

Exakt genau so, die DS ist der VPN-Client und bietet bei der Einrichtung explizit an, diesen VPN-Zugang für andere Nutzer im Netz bereit zu stellen.


@jahlives
Da bin ich sogar voll bei dir.
Natürlich könnte ein Nutzer am Client einfach die IP-Config ändern und direkt als GW die Fritte angeben und würde somit die DS faktisch umgehen.
Aber der "Kill-Switch" soll ja nicht die Zugangsberechtigung regeln, sondern als "Handbremse" falls der VPN-Tunnel nicht mehr stehen sollte.

Und das Szenario befindet sich in einem Privathaushalt wo ich die konkrete Aussage treffen kann: Außer mir ändert da niemand etwas an der IP-Konfiguration der Clients/Endgeräte.

Und ja, ich würde das sogar liebend gerne auf der FritzBox einrichten.
Nur die FritzBox bietet es nicht an, einen VPN-Zugang "shared" für das Heimnetz zur Verfügung zu stellen. Zudem die Möglichkeit, eine VPN-Verbindung als Client zu (irgend)einem VPN-Anbieter herzustellen "einfach so" auch nicht geht.
Denn bei der FritzBox müssen im Rahmen der VPN-Konfiguration Details über das Netz der Gegenstelle angegeben werden, welche ich als VPN-Kunde gar nicht habe.
Das ist eher für eine Verbindung von einem mir bekannten "Firmennetz A" zu "Firmennetz B" gedacht.

Dies wäre nur mit "Freetz" möglich oder bspw. der Austausch gegen einen Router mit OpenWRT (oder andere Möglichkeiten).

@larn
Saubere Idee....würde ich auch genauso machen.....aber wir sprechen von einer DS115 mit einem LAN-Port^^

 

[jahlives]

wenn es dir so wie von dir beschrieben reicht dann ist der Traffic von den Clients im LAN ja ein FORWARD für die DS. Also kannst du diesen Traffic wohl recht einfach über eine iptables Regel im FORWARD killen. Also so was in der Art

iptables -I FORWARD -j DROP
#oder ein REJECT wenn du willst, dass der Client eine Rückmeldung erhält, dass seine Verbindung abgewürgt wurde
iptables -I FORWARD -j REJECT

Wobei nochmals angemerkt wirklich funzen tut das Vorhaben nur wenn der Gateway des LANs die VPN Verbindung aufbaut. Wenn es die Fritte nicht kann, dann gibt es - falls du nicht auf die Fritte angewiesen bist - z.B. pfSense als Firewall. Aus eigener Erfahrung kann ich dir sagen, dass pfSense problemlos OpenVPN Verbindungen sowohl als Client als auch als Server aufbauen kann. Bei pfSense hättest du zudem den Vorteil, dass es keinen Kill Switch braucht. Denn man kann Policy Based Routing machen d.h. den Traffic auf den eine Regel zutrifft an eine bestimmten Gateway zu schicken.
In deinem Fall würde dann eine Regel reichen, die jeglichen Traffic nach extern, der nicht von der DS kommt, an die OpenVPN IP des OpenVPN Server weitergibt. Ist der Tunnel down laufen diese Verbindungen ohne weitere Regel ins Leere --> das wäre dann der Kill Switch. Als Hardware für einen pfSense Router kann ich dir aus eigener und guter Erfahrung folgendes empfehlen: http://www.pcengines.ch/apu.htm Die liefern für Privatkunden zwar nur innerhalb der Schweiz, aber es würde sich für dich sicher ein Schweizer finden, der die Bestellung für dich abhandeln könnte Für ungefähr 160 CHF hast du dafür eine sehr performante Firewall.

Das ganze Policy Based Routing würde zwar auch mit der DS grundsätzlich gehen (also dass es keinen expliziten Kill Switch braucht). Lässt sich aber bei pfSense sehr viel weniger fummelig umsetzen. Zudem hättest du bei pfSense ein sehr brauchbares GUI

 

[MMD*]

Kenne mich nicht ganz aus mit iptables aber sollte das für ein DS nicht sein:

iptables -I DEFAULT_FORWARD -d IP-FRITZBOX -j DROP

?

 

[jahlives]

stimmt die Chains heissen bei Syno ja DEFAULT_CHAIN
Allerdings ist deine Regel falsch. Denn die abzuwürgenden Pakete sind nicht für die Destination IP-Fritte, sondern für das grosse weite Internet

 

[MMD*]

Ach ja, natürlich da hast recht.

Die FORWARD ist schon da aber die syno macht Standard ein -j(ump) zum DEFAULT_FORWARD
(wen ich mich nicht irre)

*nat
: PREROUTING ACCEPT [0:0]
: INPUT ACCEPT [0:0]
: OUTPUT ACCEPT [0:0]
: POSTROUTING ACCEPT [0:0]
: DEFAULT_POSTROUTING - [0:0]
COMMIT
*filter
: INPUT ACCEPT [0:0]
: FORWARD ACCEPT [0:0]
: OUTPUT ACCEPT [0:0]
: DEFAULT_FORWARD - [0:0]
: DEFAULT_INPUT - [0:0]
: DOS_PROTECT - [0:0]
-A INPUT -j DOS_PROTECT
-A INPUT -j DEFAULT_INPUT
-A FORWARD -j DEFAULT_FORWARD
COMMIT

 

[dany]

Ich verstehe nicht warum du nicht einfach einen Proxyserver nimmst. Mit dem Squid kannst du alle Clients in deinem Netzwerk versorgen und bei bedarf kannst du ihn einfach abschalten. Auf deinem Router kannst du alle Ports 80/443 nach aussen ausser für die NAS sperren. Somit kann niemand auf das Internet zugreifen der nicht darf. Mit dem Proxyserver kannst du sogar im GUI explizit IP Adressen/Adressraum erlauben.

Mir ist nicht ganz klar was du für ein Ziel zu verfolgst. Willst du auf Knopfdruck alle Internetverbindung der Clients kappen?

 

[jahlives]

@dany
ein Proxy arbeitet aber nur für wenige Protokolle z.B. http So wie ich den TS verstanden habe will er aber sämtliche Protokolle durch den Tunnel schiessen. Das geht mit einem Proxy z.B. für DNS nicht. Der TS erwähnt im Eingangspost den Schutz vor DNS Leaks, aber genau das könnte ein Proxy nicht leisten