Dynamishe/statische IP für tun0

[TBow]

Verbinde ich mich von meinem Linux System zu einem VPN Server, so wird ein tun0 Interface eingerichtet. So weit, so gut.
Die IP Adresse von tun0 ist jedoch dynamisch, sprich, bei der nächsten Einwahl zum VPN Tunnel ist die IP des Tun0 Interfaces eine andere. Darum muss ich die IP Adresse in den Iptables auch ändern, was ich nun ändern will, indem ich dem Interface eine statische IP Adresse zuweise, oder das anderweitig löse.
Hat jemand eine Idee, wie ich das hinbekomme?

 

[MrNice]

das kannst du nicht ändern, lass die IP aus den iptables weg und benutzt nur -i tun0

 

[TBow]

Schade. Trotzdem Danke!
Lass dann wohl, wie von dir vorgeschlagen, das ganze Interface in den Iptables.

 

[MrNice]

was willst du erreichen? sowas https://github.com/ovpn-to/oVPN.to-IPtables-Anti-Leak ?

 

[TBow]

was willst du erreichen?

"Einsperren" einer virtuellen Maschine
Die VM darf nur Pakete über tun0 an eine bestimmte IP Adresse und Port senden. Alles andere wird verworfen.

 

[Kugelfisch]

Dann würde sich in der Tat anbieten, anhand der Quell- und Ziel-Interfaces und nicht anhand der IP-Adressen zu filtern. Damit vermeidest du auch Leaks bei IP-Netzadresskonflikten (wenn z.B. ein über das physische Interface erreichbares Netzwerk dieselbe private Netzwerkadresse nutzt wie das VPN).

Du könntest in deinen iptables-Aufrufen natürlich auch die IP-Adresse dynamisch ermitteln (z.B. [kw]iptables ... -d $(/sbin/ifconfig tun0 | sed -ne '/inet addr/ s/.*inet addr:\([^ ]*\) .*/\1/ p')[/kw]), allerdings ist das ein übler Hack, von welchem ich im Allgemeinen stark abraten würde.

 

[MrNice]

Poste doch mal dein Regelwerk.

 

[TBow]

Danke an euch beide.

Poste doch mal dein Regelwerk.

here it is...
..target..........prot......in..... out...........source.................destination
ACCEPT........udp.....any....eht0.......anywhere............VPN.IP.Adr.esse......udp.....dpt:1150
ACCEPT........udp.....any....tun0....tun0.IP.Adr.esse.........anywhere

Dann würde sich in der Tat anbieten, anhand der Quell- und Ziel-Interfaces und nicht anhand der IP-Adressen zu filtern.

Ist das nicht eine Schwächung der Sicherheit, wenn die VM (tun0) alles machen darf und nicht auf eine IP/Port beschränkt wird?

 

[MrNice]

auf was ist die policy gesetzt?

da am tun0 garkeine andere adresse anliegen kann und tun0 nur existiert, wenn die verbindung zum vpn-server aufgebaut ist, sehe ich darin kein problem.

 

[TBow]

da am tun0 garkeine andere adresse anliegen kann und tun0 nur existiert, wenn die verbindung zum vpn-server aufgebaut ist, sehe ich darin kein problem.

Herrje, ich hab echt einen an der Waffel gehabt.
Klar, existiert der VPN Tunnel, dann laufen alle Daten von tun0 in den Tunnel, bricht er zusammen, dann gibts kein Interface tun0 mehr und die Regel ist fürn Popo.
Danke!

 

[MrNice]

hast du POLICY DROP?

Poste doch mal bitte die regeln als text oder wie kommen die da rein? Was sollen die ...... da?

 

[TBow]

hast du POLICY DROP?

Poste doch mal bitte die regeln als text oder wie kommen die da rein? Was sollen die ...... da?

Nach dem Einloggen füge ich folgendes in den Terminal ein...

iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -A OUTPUT -p udp -o eth0 -j ACCEPT
iptables -A OUTPUT -p udp -o tun0 -j ACCEPT

Das klappt auch.
Füge ich jedoch "iptables -F" vorher ein, dann hängt die Einwahl des VPN Tunnels, obwohl ich zB keine Namensauflösung benötige, da ich keine Url, sondern die IP eingebe.
Überprüfe ich vorher die iptables mit "iptables -L -v", so werden mir keine Regeln angezeigt, nach "iptables -F" auch nicht, aber das geschilderte Problem tritt nun auf.
Welche Regel habe ich wohl irrtümlich gelöscht?

 

[MrNice]

Vielleicht schaust du dir mal das oben verlinkte Script an.
Wenn du openvpn benutzt, liest es automatisch aus den Configs auch die VPN-Server IPs mit dem Port und Proto und öffnet per eth0 auch nur Richtung diese.
Du hast komplett UDP offen per eth0. und iptables -F? FLUSH ist löschen.

 

[TBow]

Vielleicht schaust du dir mal das oben verlinkte Script an.

Werds mal testen. Danke.