117471
Oct 06, 2015, updated at 18:24:44 (UTC)
3349
6
0
Route hinter VPN-Gateway
Ich lerne gerade Netzwerktechnik und bastle ein bisschen mit OpenVPN herum.
Folgendes Szenario auf dem Client (RoadWarrior):
eth0 (Client) - DHCP
tun0 (Client) - 1.1.1.6/24 (das ist eine statische IP-Adresse, die der Client vom VPN-Server bekommen hat. Der VPN-Server kann diese anpingen. Der Server hat an seinem Tunnelende die 1.1.1.5/24).
eth1 (Client) - 2.2.2.2/24
IP-Forwarding ist auf dem Client eingeschaltet.
Jetzt möchte ich auf dem Server eine statische Route setzen um die 2.2.2.2 erreichen zu können. Mein erster Versuch:
Ich habe gelernt, dass das nicht funktionieren kann. Der route-Befehl kann nur IP-Adressen handhaben, die an seinen Netzwerkschnittstellen hängen.
Also habe ich es über das Device versucht:
Im Nachhinein ziemlich naiv - hinter tun0 könnte schließlich "alles Mögliche" hängen. Also habe ich es mit einer Kombination der beiden Parameter versucht:
Und genau das funktioniert auch nicht. Seufz!
Einen IPSec-Tunnel möchte ich vermeiden, da ich mit dem Client "friendly user" in einem Testnetz bin und nichts überstrazieren möchte, indem ich Portforwardings usw. einfordere. Die VPN-Verbindung ist natürlich "genehmigt".
Eine Netz-zu-Netz-Kopplung via VPN möchte ich vermeiden, da VPN-Server und Netzwerkkonfiguration eigentlich über eine Web-GUI und eine Paketverwaltung beeinflusst werden. Da ist halt vieles direkt mit dem tun-Device verheiratet.
Die "push route" Funktion von OpenVPN funktioniert doch eigentlich nur, wenn der Server eine Route an den Client verteilt (oder?).
Wie werde ich da am ehesten glücklich?
Folgendes Szenario auf dem Client (RoadWarrior):
eth0 (Client) - DHCP
tun0 (Client) - 1.1.1.6/24 (das ist eine statische IP-Adresse, die der Client vom VPN-Server bekommen hat. Der VPN-Server kann diese anpingen. Der Server hat an seinem Tunnelende die 1.1.1.5/24).
eth1 (Client) - 2.2.2.2/24
IP-Forwarding ist auf dem Client eingeschaltet.
Jetzt möchte ich auf dem Server eine statische Route setzen um die 2.2.2.2 erreichen zu können. Mein erster Versuch:
route add -net 2.2.2.0/24 gw 1.1.1.6Ich habe gelernt, dass das nicht funktionieren kann. Der route-Befehl kann nur IP-Adressen handhaben, die an seinen Netzwerkschnittstellen hängen.
Also habe ich es über das Device versucht:
route add -net 2.2.2.0/24 dev tun0Im Nachhinein ziemlich naiv - hinter tun0 könnte schließlich "alles Mögliche" hängen. Also habe ich es mit einer Kombination der beiden Parameter versucht:
route add -net 2.2.2.0/24 gw 1.1.1.6 dev tun0Und genau das funktioniert auch nicht. Seufz!
Einen IPSec-Tunnel möchte ich vermeiden, da ich mit dem Client "friendly user" in einem Testnetz bin und nichts überstrazieren möchte, indem ich Portforwardings usw. einfordere. Die VPN-Verbindung ist natürlich "genehmigt".
Eine Netz-zu-Netz-Kopplung via VPN möchte ich vermeiden, da VPN-Server und Netzwerkkonfiguration eigentlich über eine Web-GUI und eine Paketverwaltung beeinflusst werden. Da ist halt vieles direkt mit dem tun-Device verheiratet.
Die "push route" Funktion von OpenVPN funktioniert doch eigentlich nur, wenn der Server eine Route an den Client verteilt (oder?).
Wie werde ich da am ehesten glücklich?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 284772
Url: https://administrator.de/contentid/284772
Printed on: April 23, 2024 at 09:04 o'clock
6 Comments
Latest comment
das ist eine statische IP-Adresse, die der Client vom VPN-Server bekommen hat
Das ist Blödsinn, denn die bekommt er natürlich dynamisch vom Server verteilt !Guckst du hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Das ist das IP Netzwerk was du im Server in dessen Konfig Datei mit server 10.1.1.0 255.255.255.0 z.B. definierst.
Nicht besonders intelligent hier öffentliche IPs zu nehmen dessen Besitzer du nicht bist !
Sinnvoller ist es hier private RFC 1918 IP Adressen zu verwenden...wie immer.
Der VPN-Server kann diese anpingen.
Der Client und alle anderen auch...Der route-Befehl kann nur IP-Adressen handhaben, die an seinen Netzwerkschnittstellen hängen.
Woher hast du diese "Weisheit". Stimmt natürlich nicht. Richtig ist das die Next Hop IP zu diesem Netz an einem Adapter dran ist am Server.Versuchst doch mal mit push "route 2.2.2.0 255.255.255.0"
Es reicht aber auch ein ganz normales route 2.2.2.0 255.255.255.0 in der Server Konfig.
Wieder nutzt du hier keine privaten IP Netze ! Besser ist 10.2.2.0 /24 !!
Am Client dann ein route print (wenn dieser ein Winblows Client ist !) bei aktiviertem OVPN Client und du weisst ob deine Route ins 2er Netz sauber auf den Client propagiert wurde vom Server und die Pakete ins 2er Netz dann in den Tunnel geroutet werden.
Hier sind auch wieder Traceroute und Pathping deine besten Freunde...
Alles andere erklärt dir das oben zitierte OVPN Tutorial hier im Forum.
Ja, aber es ist immer die Gleiche. Das habe ich im ccd in der Client-Config eingestellt:
ifconfig-push 1.1.1.6 1.1.1.5Der route-Befehl kann nur IP-Adressen handhaben, die an seinen Netzwerkschnittstellen hängen.
Woher hast du diese "Weisheit".
Aus der Dokumentation des route-Befehls (Linux!).
Alles andere erklärt dir das oben zitierte OVPN Tutorial hier im Forum.
Das beschränkt sich leider auf pfsense und dd-wrt. Da nicht immer beschrieben ist, was die einzelnen Optionen in der VPN-Konfiguration bzw. in den zugrundeliegenden Betriebssystemen bewirken, bekomme ich das irgendwie nicht auf das pure OpenVPN herunterprojeziert. Wenn ich das könnte, gäbe es wohl nichts mehr zu lernen.
Nachtrag: Die hier dargestellten IP-Adressen sind lediglich "der Einfachheit halber" gewählt. Grundsätzlich benutze ich natürlich private Netze.
Auf dem Server: 10.10.10.0/24
Auf dem Client: 10.10.30.0/24
Im VPN: 10.10.31.0/24
Auf dem Server: 10.10.10.0/24
Auf dem Client: 10.10.30.0/24
Im VPN: 10.10.31.0/24
bekomme ich das irgendwie nicht auf das pure OpenVPN herunterprojeziert. Wenn ich das könnte, gäbe es wohl nichts mehr zu lernen.
Na ja...mit ein bischen Nachdenken und Intelligenz kann man sich das aber auch sehr einfach erschliessen. Hinter dem GUI werkelt ja nix anderes als eine einfache Konfig Datei.Grundlage ist immer das:
https://openvpn.net/index.php/open-source/documentation/howto.html
Das "Problem" ist gelöst. Und für denjenigen, der via Suchmaschine über diesen Beitrag stolpern, fasse ich gerne noch einmal meine Erkenntnisse zusammen.
Die Route muss im OpenVPN-Server an zwei Stellen konfiguriert werden:
1. In der Clientspezifischen Konfigurationsdatei (ccd) gehört - meinem Beispiel folgend - dieser Eintrag:
Damit wird dem OpenVPN-Server die IP-Adresse von dem Gateway mitgeteilt, über das er das Netz an der zweiten Schnittstelle des Clients erreichen kann.
2. In der server.conf gehört hingegen dieser Eintrag:
Dieser Eintrag veranlasst den Kernel des Betriebssystems (also des VPN-Servers), das Gateway für das Netz auf dem Tunneldevice des OpenVPN-Serverdienstes zu suchen.
Damit sollten alle Clients, die den VPN-Server als Gateway benutzen, das Netz hinter dem Client erreichen können.
Eine Ausnahme bilden andere Clients, die sich ebenfalls mit dem OpenVPN-Server verbinden. Neben der obligatorischen client-to-client-Option wird hier (in der server.conf) der folgende Eintrag gesetzt:
Damit automatisieren wir quasi Schritt 2. auf den anderen Clients: Diese verbinden sich via VPN und bekommen vom Server die Route auf den entsprechenden Client vermittelt. Unter Windows gäbe es noch die Besonderheit, dass das OpenVPN hierfür mit administrativen Rechten gestartet werden muss.
Dass man zumindest unter Linux nur dann Routen setzen kann, wenn der Kernel die IP-Adresse vom Gateway "sieht", geht übrigens auch aus dem Handbuch des route-Befehls hervor:
Quelle: http://linux.die.net/man/8/route
Die Route muss im OpenVPN-Server an zwei Stellen konfiguriert werden:
1. In der Clientspezifischen Konfigurationsdatei (ccd) gehört - meinem Beispiel folgend - dieser Eintrag:
iroute "2.2.2.0 255.255.255.0" 2. In der server.conf gehört hingegen dieser Eintrag:
route 2.2.2.0 255.255.255.0Damit sollten alle Clients, die den VPN-Server als Gateway benutzen, das Netz hinter dem Client erreichen können.
Eine Ausnahme bilden andere Clients, die sich ebenfalls mit dem OpenVPN-Server verbinden. Neben der obligatorischen client-to-client-Option wird hier (in der server.conf) der folgende Eintrag gesetzt:
push "route 2.2.2.0 255.255.255.0" Damit automatisieren wir quasi Schritt 2. auf den anderen Clients: Diese verbinden sich via VPN und bekommen vom Server die Route auf den entsprechenden Client vermittelt. Unter Windows gäbe es noch die Besonderheit, dass das OpenVPN hierfür mit administrativen Rechten gestartet werden muss.
Dass man zumindest unter Linux nur dann Routen setzen kann, wenn der Kernel die IP-Adresse vom Gateway "sieht", geht übrigens auch aus dem Handbuch des route-Befehls hervor:
NOTE: The specified gateway must be reachable first. This usually means that you have to set up a static route to the gateway beforehand.
Quelle: http://linux.die.net/man/8/route
Du wirst lachen - habe die gerade vor 2 Sekunden zugeklickt
Ich glaube, so langsam habe ich es verstanden^^
