VPN Tunnel IP für internes Netzwerk maskieren/natten?

[goetz]

Hallo,
brse, ich bin nicht so schnell, lieber neuen Beitrag schreiben, die Änderungen sieht man nicht gleich, ich bin doch schon alt.

Gruß Götz

 

[Kidaru]

Hallo,
irgs, das kann ja nicht funktionieren, Du willst ja nach eth1 raus.
Temporärer Versuch

iptables -t nat -I POSTROUTING 1 -s 10.10.10.0/24 -o eth1 -j MASQUERADE

Gruß Götz

whuuha ! goetz dat funktioniert, alle Rechner die ich haben will antworten fein und artig inklusive der Drucker/Fax/Scanner


so und bitte nun nochmal im klartext, ich kann gerade noch so erkennen das das POSTROUTING an erster stelle eingefügt wird ?

 

[goetz]

Hallo,
genau, -I ... 1 fügt an erster Stelle ein. Die Tabellen werden der Reihenfolge abgearbeitet und wenn eine Regel zutrifft verlassen.

Gruß Götz

PS: @jahlives

ganz ehrlich: ich glaub ned, dass du mit nat auf einen grünen Zweig kommen wirst.

all unsere "Home-Router" sind nichts weiter als NATter, Ringel an den NATter mal

 

[jahlives]

und was passiert nun wenn ein OpenVPN Client via dem OpenVPN-Tunnel ping google.de macht? ;-) Du solltest bei der NAT-Regel mindestens 2 machen. einmal explizit alle via openvpn erreichbaren Netze (und auch die lokalen Netze) mit NAT an eth1 und den Rest via NAT an eth0. Ich würde also noch zusätzlich mit der destination arbeiten

 

[jahlives]

@goetz
das alle Homerouter natten ist mir schon bewusst ;-) Ich habe auch nichts gegen NAT, wo man es unbedingt braucht. Aber diese Konstellation Router == OpenVPN-Server schreit förmlich nach routing ;-)

 

[Kidaru]

und was passiert nun wenn ein OpenVPN Client via dem OpenVPN-Tunnel ping google.de macht? ;-) Du solltest bei der NAT-Regel mindestens 2 machen. einmal explizit alle via openvpn erreichbaren Netze (und auch die lokalen Netze) mit NAT an eth1 und den Rest via NAT an eth0. Ich würde also noch zusätzlich mit der destination arbeiten

er macht genau das ...

night@night:~$ ping www.google.de
PING www-cctld.l.google.com (173.194.69.94) 56(84) bytes of data.
64 bytes from bk-in-f94.1e100.net (173.194.69.94): icmp_seq=1 ttl=50 time=63.3 ms
64 bytes from bk-in-f94.1e100.net (173.194.69.94): icmp_seq=2 ttl=50 time=62.1 ms
64 bytes from bk-in-f94.1e100.net (173.194.69.94): icmp_seq=3 ttl=50 time=64.1 ms
64 bytes from bk-in-f94.1e100.net (173.194.69.94): icmp_seq=4 ttl=50 time=63.0 ms
64 bytes from bk-in-f94.1e100.net (173.194.69.94): icmp_seq=5 ttl=50 time=61.0 ms
64 bytes from bk-in-f94.1e100.net (173.194.69.94): icmp_seq=6 ttl=50 time=63.9 ms
64 bytes from bk-in-f94.1e100.net (173.194.69.94): icmp_seq=7 ttl=50 time=61.8 ms
64 bytes from bk-in-f94.1e100.net (173.194.69.94): icmp_seq=8 ttl=50 time=61.3 ms

... aufgrund der vorhandenen Netzwerktopologie in der die DS mit eth1 steht, das genau zu erklären würde aber den nächtlichen Rahmen sprengen. ^^

 

[jahlives]

und du bist auch ganz sicher dass diese ping Pakete direkt durch das tun gingen? Das ist auch nicht der OpenVPN Server selber, der das ping absetzt? Die könnten auch direkt via lokalem Gateway gegangen sein. Ich glaubs (aus eigener leidiger Erfahrung) erst wenn ich einen tracert oder tcpdump sehe. Hat mich schon etliche Stunden gekostet weil ich gemeint habe die Pakete gingen einen bestimmten Weg ;-)

Gruss

tobi

 

[Kidaru]

Ein ganz dickes Danke an euch beide, jetzt kann ich Sonntags wieder ruhig Mittagschlaf machen.

Fall gelöst !

 

[goetz]

Hallo,
man muß halt Aufwand und Nutzen immer abwägen, für ein paar Sonderdrösel ist NAT gut genug, bin auch kein NAT Fan, aber die Lösung scheint einfach praktikabel.

Und den Alm-Öhi freß ich eh

Gruß Götz

PS mein Gott bin ich langsam

 

[Kidaru]

und du bist auch ganz sicher dass diese ping Pakete direkt durch das tun gingen? Das ist auch nicht der OpenVPN Server selber, der das ping absetzt? Die könnten auch direkt via lokalem Gateway gegangen sein. Ich glaubs (aus eigener leidiger Erfahrung) erst wenn ich einen tracert oder tcpdump sehe. Hat mich schon etliche Stunden gekostet weil ich gemeint habe die Pakete gingen einen bestimmten Weg ;-)

Gruss

tobi

Jap, die tun durch das tun gehen, hab gerade noch nen traceroute laufen lassen und der kabelhai sagt auch nix gegenteiliges.
Das Netzwerk mit dem ich nun über den Tunnel verbunden bin teilt sich intern nochmal in zwei weitere, ergo stehen mir theoretisch drei Gateways zur Verfügung über die ich aus dem Netzwerk ins Internet gehen könnte.

Was aber viel wichtiger ist, ich kann nun in drei Firmen gleichzeitig die Rechner supporten und das von zu Hause aus und auch wenn ich mal wieder auf Lehrgang außerhalb bin. Die Zeitersparnis durch den Wegfall der Fahrzeit ist enorm.


Grüße Kidaru

 

[ubuntulinux]

@tobi Wenn man nicht den Subnet-Modus nimmt ists doch ein P-t-P? Das geht doch auch mit routing?

 

[jahlives]

@tobi Wenn man nicht den Subnet-Modus nimmt ists doch ein P-t-P? Das geht doch auch mit routing?

ich sage nicht, dass es nicht gehen würde, sondern dass es sehr komplex werden wird und sehr viele wichtige Infos (für eine Firewall) verloren gehen. Komplex weil beim ptp der Serverendpunkt für jede Verbindung (etwas weiter unten stehen die gültigen Oktete für ptp resp subnet30) eine andere IP hat. Man wird also wohl für jeden OpenVPN Client routen müssen. Es kommt schwer darauf an wieviele Client man hat. Sind es nur wenige, dann wird auch ein ptp-Setup nicht so umfangreich, sind es viele, dann viel Spass beim routen-Einrichten. Da wirst du dir einen Wolf tippen.
Der Vorteil beim subnet gegenüber ptp ist, dass einmal eingerichtet, ein neuer Client sehr schnell im Netz ist und das ohne grössere Anpassungen. Einfach das entsprechende ccd File auf dem Server anlegen, darin die gewünschten Optionen verteilen. That's it. Braucht keine weiteren Routen auf dem Server oder dem Client. Klar kann man ccd Files auch bei ptp verwenden, jedoch wird man wohl für jede Server/Client-Verbindung irgendwas routen müssen, weil der Server ne andere IP hat.
Was mich am NAT aber am meisten stört ist, dass die src-IP verloren geht. Meine Firewalls erwarten, dass ein Paket mit dem originalen LAN Absender ankommt und nicht mit der IP des Servers. z.B. aus meinem Homenetz kann man die entfernten Netze via OpenVPN erreichen, AUCH wenn der anfragende Client selber nicht am OpenVPN angemeldet ist. Jetzt will ich ja nicht, dass jeder Client zu Hause das kann/darf, drum prüfe ich für meine admin-pc die IP/MAC-Zuordnungen auf der Firewall des Servers. Desweiteren sollen alle Teilnehmer in den Subs die originale IP erhalten, damit Anwendungen auf den Clients darauf reagieren können

 

[ubuntulinux]

Vorher hatte ich aber kein topology-subnet. Da hat eine Route gereicht im Router (Subnetz 10.8.0.0/24 / Gateway IP_DER_DS). Das war doch PtP?

 

[Kidaru]

@jahlives

bei vielen Benutzern wird es unübersichtlich das stimmt, da hier aber nur eine äußerst übersichtliche Anzahl an Benutzern den Tunnel nutzen darf und die Quell IP mit VPN IP samt Benutzernamen, Datum/Uhrzeit der Verbindung im Log des VPN Servers über den DSM angezeigt wird, finde ich die derzeitige Lösung für mich persönlich vertretbar.

 

[jahlives]

Da hat eine Route gereicht im Router (Subnetz 10.8.0.0/24 / Gateway IP_DER_DS). Das war doch PtP?

jap das ist/war ptp, aber wenn du es so wie im Wiki gemacht hast, dann hast du client-to-client genommen

--client-to-client
Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router. The --client-to-client flag tells OpenVPN to internally route client-to-client traffic rather than pushing all client-originating traffic to the TUN/TAP interface.When this option is used, each client will "see" the other clients which are currently connected. Otherwise, each client will only see the server. Don't use this option if you want to firewall tunnel traffic using custom, per-client rules.

 

[ubuntulinux]

Nicht ich mache es so wie das wiki, sondern das Wiki wie ich Hab ein bisschen rumgespielt mit dem Subnetmode, gefällt mir gut