Gefangen im VPN | kein Zugang zum LAN bei VPN-Verbindung

[HeinzM]

Ahoi,

ich habe darüber nachgedacht, meinen Zugang zum LAN von außerhalb per VPN etwas sicherer zu machen.
VPN-Server installiert und "konfiguriert"
LAN 10.8.7.*
VPN 10.8.8.*
Certifikate , Schlüssel usw. erstellt. Verbindung getestet klappt.
Allerdings bin ich im Subnet gefangen.
Ich habe mich ein bissl belesen und anscheinend kann man über iptables aus dem VPN ins LAN ne Route erstellen.
Leider funktioniert das nicht so dolle.

Deswegen meine Frage: Ist es möglich die VPN-Clients gleich so zu integrieren, das man ne 10.8.7er IP bekommt und im richtigen Subnet ist? Wenn ich das Config-File einfach verändere tut sich irgendwie nichts....

MfG
Heinz

 

[HominiLupus]

cat /proc/sys/net/ipv4/ip_forward

 

[Raijin]

Interessant wäre auch von welchem VPN überhaupt die Rede ist.......

 

[HeinzM]

debianvpn:~$ cat /proc/sys/net/ipv4/ip_forward
1

Debian minimal-Installation mit OpenVPN-Server

 

[Raijin]

Entweder pusht der VPN-Server eine Route zum LAN zu den VPN-Clients oder die fügen sie selbst hinzu.

Beispiel OpenVPN-Server-Config:

push "route 10.8.7.0 255.255.255.0"


Beispiel OpenVPN-Client-Config:

route 10.8.7.0 255.255.255.0 10.8.8.1



Kleiner Tip am Rande: Ich würde die Subnetze deutlicher voneinander trennen. Ich musste für diesen Beitrag gefühlt ein halbes Dutzend Mal nachschauen ob ich die .7. bzw. .8. nicht verwechselt habe und wahrscheinlich hab ich's doch falsch

Nimm lieber sowas wie LAN 10.8.7.0/24 und VPN zB 172.23.48.0/24. Dann siehst du sofort "oh, ne 172er IP, das is VPN".

Der VPN-Server ist im übrigen eh in beiden Subnetzen unterwegs und braucht keine explizite Route vom VPN ins LAN. Sofern obiges IP-Forwarding aktiv ist, leitet er gemäß seiner normalen Routing Tabelle, die nun mal beide Subnetze beinhaltet, weiter. Vorsicht muss man dabei allerdings bei der Antwort walten lassen. Pingst du zB ein NAS aus dem VPN, dann kommt als Quell-IP beim NAS eine VPN-IP an. Die kennt das NAS nicht und antwortet ans Standardgateway. Das wiederum ist evtl. der Internetrouter und NICHT der VPN-Server. In dem Falle entweder den VPN-Server als Gateway im NAS eintragen oder aber vom VPN-Server VPN<->LAN NAT einrichten.

Ergänzung (18. März 2015)

Das wäre die NAT-Regel für LAN=eth0. Dann wird alles was aus eth0 bzw. dem LAN-Interface (10.8.7.1 oder so) rauskommt geNATtet und das NAS würde in dem Falle denken der Ping käme vom VPN-Server und antwortet ihm. Dieser wiederum leitet es dann an die genattete VPN-IP zurück.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

 

[HITMAN00]

wenn das problem mit dem routen gelöst ist, bitte auch die MTU beachten, die war bei mir das Problem...

 

[Raijin]

Was die MTU angeht, kann man einiges optimieren. Mein OpenVPN lief im LAN nur mit ca. 120 Mbit/s und ich hab mal geschaut wie man das verbessern kann. Nachdem ich folgenden Link durchgearbeitet hatte, lag mein VPN-Speed bei 600 Mbit/s! Die Änderungen sind zT etwas gewöhnungsbedürftig (MTU bis zu 60000), aber es wirkt. Nichtsdestotrotz muss die MTU des zugrundeliegenden Netzwerks selbstverständlich passen (zB 1500). Nur die MTU des VPNs wird geändert.

Es lohnt sich also, sich diesen Artikel genauer durchzulesen und die Einstellungen im eigenen VPN zu testen.


Optimizing performance on gigabit networks


P.S.: Das ist allerdings etwas fortgeschritten und keineswegs notwendig. Wer Spaß dran hat kann so aber die Grenzen des VPN ausreizen.

 

[HeinzM]

Diese Push-Anweisungen haben leider nichts gebracht. Keinerlei Veränderungen.

IP-Vergabe per DHCP im gewünschten Adressbereich ist wohl nicht möglich?

 

[Raijin]

Inwiefern? Haben sie nicht funktioniert oder hatten sie nicht die gewünschte Wirkung? Bitte vollständiges Feedback geben, "bringt nix" bringt auch den Helfern nichts..

 

[HeinzM]

"Keinerlei Veränderungen"

Ich habe
a) mit den Pushanweisungen in der Server-Config -> Verbindung wie vorher, Zugang zum LAN nein
b) mit den Pushanweisungen in der Client-Config -> Verbindung wie vorher, Zugang zum LAN nein

Ich werde mich nach den Klausuren nochmal etwas tiefer in die Materie einlesen.
Danke erstmal bis hierhin.

 

[Raijin]

Das hilft immer noch nicht Es kann zB sein, dass die Routen wegen fehlender Adminrechte gar nicht erst eingetragen werden. Dann können sie auch nicht wirken..

Im Verbindungslog im Client taucht dann zB so eine Meldung auf: Route addition failed. Schaut man sich mit route print die Routing Tabelle an, tauchen die neuen Routen auch nicht auf. Vergleiche bitte mal vor und nach der Verbindung mit route print die Routingtabelle. Eventuell musst du den Client bzw. die GUI (je nachdem) explizit als Admin ausführen.