Beantwortet: [Linux] Traffic auf VPN beschränken: Firewall- vs. OpenVPN-Settings?

byomiger_tag_heute

Junior Member
Hallo zusammen!

Wie ich gelesen habe, gibt es verschiedene Ansätze, Internettraffic ausschließlich über das VPN zu erlauben. In vielen Lösungen wird das über das Konfigurieren einer Firewall, z.B. iptables, realisiert. Was hat es mit der OpenVPN-Option redirect-gateway auf sich und weshalb reicht diese nicht aus, um sicherzustellen, dass jeglicher Internettraffic über das VPN läuft und bei Verbindungsabbruch zum VPN auch keine Verbindung mehr zum Internet möglich ist?

Ich danke euch für jegliche Antworten!
 
Solution
Wirf einen Blick in die ovpn-Howtos, um Details zu erfahren (https://openvpn.net/index.php/open-source/documentation/howto.html).
redirect-gateway sorgt dafür, daß alles über den Tunnel geht (auch z.B. DHCP-requests für eth0, die ja am Tunnel vorbei gehen sollen).
Ich finde es daher besser, sowas mit einem script selbst in die Hand zu nehmen und eine entsprechende routing-Tabelle zu setzen.
Nach Tunnelaufbau würde ich auch immer kontrollieren, ob das routing so steht, wie ich es möchte (ip -4 route show, bzw. mal testen, über welches Interface ein request geht: ip -4 route get <ip>)
Zusätzlich würde ich in jedem Fall iptables so konfigurieren, daß alles über eth0 gedroppt wird, außer ports 1149...1151 und ggf DNS/DHCP.
Kracht...
Wirf einen Blick in die ovpn-Howtos, um Details zu erfahren (https://openvpn.net/index.php/open-source/documentation/howto.html).
redirect-gateway sorgt dafür, daß alles über den Tunnel geht (auch z.B. DHCP-requests für eth0, die ja am Tunnel vorbei gehen sollen).
Ich finde es daher besser, sowas mit einem script selbst in die Hand zu nehmen und eine entsprechende routing-Tabelle zu setzen.
Nach Tunnelaufbau würde ich auch immer kontrollieren, ob das routing so steht, wie ich es möchte (ip -4 route show, bzw. mal testen, über welches Interface ein request geht: ip -4 route get <ip>)
Zusätzlich würde ich in jedem Fall iptables so konfigurieren, daß alles über eth0 gedroppt wird, außer ports 1149...1151 und ggf DNS/DHCP.
Kracht der Tunnel zusammen, geht weiterhin nichts über eth0 und man merkt es sofort.
ip6tables nicht vergessen!
 
Solution
auch z.B. DHCP-requests für eth0, die ja am Tunnel vorbei gehen sollen

Lokale Requests gehen nicht durch den Tunnel, was ja bei DHCP idR so ist, der Router steht ja nicht im Internet, da alles was für das LAN bestimmt ist nicht durch den Tunnel geht.
 
Redirect-Gateway setzt die Route so, dass jeglicher Traffic durch den Tunnel geht mit Ausnahme lokaler Traffic in dein LAN, was ja auch so sein soll. Solange der Tunnel steht ist das soweit ok, wenn OpenVPN allerdings zusammenbricht kann es sein, dass dein Traffic wieder über deinen lokalen Adapter direkt ins Internet geht. Für diesen Fall verwendet man ne Firewall, wie zb die iptables.
 
Was passiert, wenn ich nach Aufbau eines Tunnels eth0 einfach statisch setze und den Adapter mit Dummy-Daten fülle? Sollten dann nicht bei Zusammenbruch des Tunnels ebenfalls keine Internetverbindungen mehr möglich sein?

P.S. Vielen Dank für eure bisherigen Ausführungen!
 
Ist unsicher, da du im Falle der DHCP Lease läuft ab, einfach die default Route wieder vom DHCP gepusht bekommst. Das sauberste ist ne Firewall Lösung als so ne Notlösung.
 
  1. Ein statischer Adapter wird doch manuell konfiguriert. Kann da per DHCP dann überhaupt etwas gepushed werden?
  2. Bei der von theoth vorgeschlagenen iptables-Konfiguration empfiehlt er, diverse Ports offen zu lassen. Kann beim Zusammenbruch des Tunnels dann nicht theoretisch andere Software über diese Ports nach außen kommunizieren?
 
Sinn macht hier nur die default Route über deinen Router nach Aufbau des Tunnels zu löschen. Dazu ist es nicht nötig, die Config manuell zu erledigen, wenn du das machst wird natürlich nichts vom DHCP gepusht. Um allerdings erneut nen VPN Aufbau hinzukriegen musst du die default Route letztlich wieder über deinen Router laufen lassen, was bedeutet, dass in dieser Zeit jegliche Software über alle Ports ins Internet gelangt. Bei der FW Lösung sind explizit nur die VPN Ports erlaubt, evtl noch DNS, mehr nicht, sehr unwahrscheinlich, dass eine andere Software ausgerechnet den VPN Port über zB UDP nutzt. Wie gesagt ich würde die FW Lösung der anderen vorziehen.
 
Wie gesagt ich würde die FW Lösung der anderen vorziehen.

Nachdem ich deine Erklärung gelesen habe, muss ich dir zustimmen. Allerdings frage ich mich, ob man die Ausnahmen in der Firewall nicht noch genauer definieren könnte. Mir fehlt das tiefe Hintergrundwissen zu OpenVPN, also korrigiert mich bitte, falls ich mir nun etwas Unsinniges zusammendenke: Wäre es möglich, mittels iptables nicht nur ausschließlich die benötigten OpenVPN-Ports freizugeben, sondern darüber hinaus die Belegung dieser auch nur durch den bzw. die Benutzer zu erlauben, unter welchen der OpenVPN-Adapter/-Prozess laufen? Dann hätte man doch den bereits sehr unwahrscheinlichen Fall, dass andere Software über diese Ports nach außen kommuniziert, komplett unterbunden.
 
Der OpenVPN Prozess wechselt idR den User von zuerst root, was zum Setzen der Routen etc nötig ist, zu zb nobody, wenn keine administrativen Aufgaben mehr zu erledigen sind. Dadurch wird verhindert, dass OpenVPN ständig mit root Rechten läuft. Somit wird das schwierig mit Usern zu arbeiten.

Um überhaupt ein solches Szenario herbeizuführen, dass der OpenVPN Port von anderer Software genutzt wird, müsste irgendwo ein Prozess auf zb UDP 1149 laufen, damit die Software diesen unter diesem Zielport erreichen kann. Dabei handelt es sich zum einen noch nichtmal um einen Standardport, der OpenVPN Port ist normalerweise UDP 1194, zum anderen gibt es über 65000 unterschiedliche Ports, die es auch noch für TCP und UDP zugleich geben kann.
Du siehst wie wenig zielführend das ganze wäre, nen Prozess auf nem PP OpenVPN Port laufen zu lassen, zumal derjenige nicht weiß, wann PP wieder die Ports ändert und es noch zig andere Privacy Dienstleister gibt, die wieder andere Ports verwenden.

Darüber würde ich mir echt keine Gedanken machen.
 
Back
Top