VPN Gateway mit debian

[RockNLol]

hi,
ich spiele gerade mit einer debian-VM herum, die als Gateway zu einem VPN-Tunnel dienen soll. Folgende Anleitungen habe ich dafür verwendet:
VPN mit killswitch
Gateway/NAT
getrennt voneinander funktionieren diese beiden "Bausteine" auch. Die Gateway-VM selbst kommt nur ins Internet, wenn der openvpn-tunnel steht, wie in der ufw festgelegt (default outgoing deny und ausnahme zur VPN-Server-IP und allow outgoing on tun0)
Solange der VPN-Tunnel steht, funktioniert auch das Gateway korrekt. In der /etc/ufw/before.rules ist definiert:
-A POSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE
Eine zweite debian-VM, bei der die IP fix gesetzt wurde und die Gateway-VM als Standardgateway definiert wurde kommt über den VPN-Tunnel ins Internet und hat auch die öffentliche IP des VPNs, getestet mit "curl ipinfo.io".

Bricht der Tunnel allerdings ab, simuliert mit killall openvpn in der Gateway-VM, kommt das Gateway selbst nicht mehr ins Internet, aber die zweite Test-VM, die die erste VM als Gateway verwendet, erreicht weiterhin das Internet, diesmal aber über meine eigene öffentliche IP.

Sieht jemand den Haken, warum das so ist?

 

[b1nb4sh]

Wie sieht die Route der debian-vm aus? Kann es sein, dass dein GW-VM sonst noch ein Iface MASQ?

 

[RockNLol]

Bei der zweiten debian-VM hab ich mit
ip route del default
ip route add default via 192.168.0.GW-VM
die Route gesetzt. Passt das so?

auch bei /etc/network/interfaces habe für eth0 (einziges interface) als Gateway die GW-VM eingetragen.

Bei der GW-VM habe ich nur diese eine Zeile mit
-A POSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE
geändert. Soetwas wie
-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE oder so, was das Symptom erklären würde, sehe ich nirgends.

 

[b1nb4sh]

Mit einem "ip r" lieferst du einmal die gesamte Tabelle aus.
-A POSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE <-- besagt, dass alle Pakete wenn sie von -s kommen und über -o verlassen, maskiert werden.
ufw ist nur ein Vereinfachungswrapper für iptables.

Du kannst die iptables Tabelle auch mit iptables -L (listet die INPUT,FORWARD,OUTPUT Chains auf) und mit iptables -t nat -L (POSTROUTING, FORWARD, PREROUTING Chains)

 

[RockNLol]

ip r auf der zweiten VM ergibt:
default via 192.168.0.GW-VM dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.test-VM

traceroute 1.1.1.1 auf der test-VM bei getrennter VPN-Verbindung des Gateways zeigt, dass als Gateway einfach mein Router verwendet wird. Die Gateway-VM ist Hop 1, der Router Hop 2, Rest ist Internet. Bei bestehender VPN-Verbindung verschwindet der Router als Hop.

Wenn du sagst dass diese Zeile mit dem POSTROUTING nur maskiert, wo definiere ich denn überhaupt die Weiterleitung durch den Tunnel?
DEFAULT_FORWARD_POLICY="ACCEPT"
in /etc/default/ufw ist ja dann sehr allgemein und schickt einfach alles weiter, egal welches Interface, wenn ich das richtig verstehe. Dass die Firewallregel
ufw default deny outgoing
hier nicht greift, verstehe ich auch nicht ganz. sagt ja schon der Name der Datei "before.rules"....

 

[b1nb4sh]

DEFAULT_FORWARD_POLICY="ACCEPT" <-- das sagt doch alles. Zwischen den Interfaces findet ein Forwarding statt. Keine Regel, also Standardverhalten --> ACCEPT.
Du musst über den VPN Tunnel auch dein Standard GW ersetzen lassen, sonst verwendet er nur für den Bereich das GW.

Grundwissen zur UFW

Lies Mich

Konfigurationsdateien

 

[RockNLol]

Ganz schlau werd ich aus der Sache immer noch nicht. DEFAULT_FORWARD_POLICY ist jetzt wieder auf DROP. Ich versuche jetzt normale iptables commands in die before.rules einzupflegen, um die default policy zu ersetzen. Folgendes habe ich versucht, wird aber nicht von ufw akzeptiert:
-A POSTROUTING -o tun0 -j MASQUERADE #maskiert wieder nur alles was über tun0 raus geht
-A FORWARD -i eth0 -o tun0 -j ACCEPT #über diese Zeile beschwert sich ufw und bricht ab, sollte Traffic von eth0 auf tun0 forwarden
-A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT # so weit kommt ufw gar nicht.

was mach ich hier falsch?

*edit: Habs geschafft, folgendes habe ich gemacht:
in /etc/default/ufw ist DEFAULT_FORWAD_POLICY="DROP"

am Ende der /etc/ufw/before.rules habe ich angehängt:

# Forwarding
:FORWARD ACCEPT [0:0]

-A FORWARD -i eth0 -o tun0 -s 192.168.0.0/24 -j ACCEPT
-A FORWARD -i eth0 -o eth0 -j DROP # Warum ich das brauche kann ich nicht genau sagen, ohne diese Zeile wird bei getrenntem VPN wieder weitergeforwarded.
COMMIT

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o tun0 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT

Damit habe ich das gewünschte Verhalten, dass bei getrenntem VPN keine Verbindung der VMs hinter dem Gateway mit dem Internet zustande kommt.

 

[Raijin]

Hm.. Sieht für mich logisch aus. Forward ist auf accept, das heißt alles was reinkommt und weitergeleitet werden soll, wird erstmal accepted und weitergeleitet - so auch eingehender Traffic auf eth0, der dann wieder auf eth0 Richtung Router raus geht.
Mit der Drop-Regel -i eth0 -o eth0 verhinderst du, dass Traffic quasi einmal durch eth0 durchgereicht wird.

Im übrigen ist es fraglich inwiefern eine ACCEPT Regel sinnvoll ist, wenn die ganze Chain auf Accept steht. Dazu müsste man aber die komplette Chain sehen. Üblicherweise ist eine Chain so aufgebaut:

Drop x
Drop Y
Drop z
Default Accept

(bei Default Drop entsprechend andersherum)

So ergibt es aber herzlich wenig Sinn:

Accept x
Accept y
Accept z
Default Accept

Bitte bei solchen Threads immer die komplette Ausgabe von iptables posten und nicht so halb mit Text und halb mit einzelnen Kommandos erklären. Das gesamte Bild der Regeln ist wichtig, nicht 2-3 einzelne Zeilen...


Zur Erklärung:

iptables (ufw ist nur ein vereinfachtes Frontend) arbeitet mit Chains. Diese funktionieren aber nicht unbedingt so wie Otto Normal das denken würde, die Bezeichnungen können leicht falsch interpretiert werden.

Die "Input" Chain deckt zB ausschließlich eingehenden Traffic ab, der aber auch lokal verabeitet wird, also direkt an den Server selbst gerichtet ist (zB an einen lokalen FTP-Server).

Die "Forward" Chain deckt ebenfalls eingehenden Traffic ab, allerdings nur den, der nicht direkt an den Server gerichtet ist, sondern für ein anderes Ziel bestimmt ist und weitergeleitet wird.

Die "Output" Chain wiederum greift nur bei Traffic, der lokal vom Server stammt. "Output" deckt nicht den gesamten Traffic ab, der den Server wie auch immer verlässt, also auch nicht den ausgehenden Forward-Traffic.

(Quelle: Boolean World)


Ich gehe daher davon aus, dass dein Killswitch sich auf die Output-Chain bezieht. Dann kann der Server ohne VPN zB nicht mehr nach draußen pingen (ping=lokaler Prozess), weil im Output ein Drop steht, aber weitergeleiteter Traffic, der nun mal nur durch die Forward-Chain geht, wird diese Output-Regel niemals zu Gesicht bekommen.
Um zu beurteilen ob das bei dir der Fall ist, müsstest du aber wie erwähnt die kompletten iptables posten, als Screenshot oder Copy&Paste in einem Code-Tag und ggfs in einem Spoiler-Tag.