also ich habe im Setup einen OpenVPN-Server, der im Subnetz 192.168.7.0/24 läuft. Der OpenVPN-Server bedient ein halbwegs komplexes Server-Setup, daher ist eine Änderung des Subnetzes nur als letzter Ausweg zu sehen (ich hoffe allerdings, dass ich nicht so weit komme)
das Problem ist, dass sich einige Benutzer beschweren, dass sie im Homeoffice einige Netzwerkressourcen nicht nutzen können, obwohl sie VPN eingeschaltet haben. Ein genauerer Blick zeigte jedoch, dass sie für ihr Heimnetzwerk dasselbe Subnetz verwenden wie für den OpenVPN-Server! Daher werden Anfragen intern geroutet, anstatt über das VPN gesendet zu werden.
Eine Umstellung auf IPv6 ist nicht möglich und die Verwendung von NAT für derartige Zwecke ist äußerst unsachgemäß.
Ich habe versucht, die VPN-Clients zu zwingen, den VPN-Server als Standard-GW zu verwenden, indem ich auf der Serverkonfigurationsseite „redirect-gateway def1“ oder/und „redirect-gateway local def1“ gedrückt habe, ohne Erfolg.
irgendwelche Ideen?
vielen Dank
Antwort1
Das Problem bei der Gateway-Umleitung besteht darin, dass in der Routing-Tabelle die spezifischeren Einträge die weniger spezifischen überschreiben. Daher ist das Pushen des Gateways normalerweise keine große Hilfe, da jeder Computer einen /24Link-Scope-Routeneintrag für das lokale Netzwerk enthält, der natürlich spezifischer ist als die angegebene Standardroute und daher stattdessen verwendet wird.
Wenn Sie das VPN-Subnetz wirklich nicht ändern möchten, können Sie am besten bestimmte Routen für die Ressourcen im VPN-Netzwerk pushen, da eine Route für einen einfachen Host den Link-Scope-Eintrag überschreibt.
Sie möchten vielleicht „schummeln“ und zwei /25Netzwerke senden (also 192.168.7.0/25und 192.168.7.128/25), die spezifischer sind als das lokale /24Netzwerk, und diese beiden decken fast das gesamte VPN-Subnetz ab (abzüglich der Hosts an der „Grenze“ – also Hosts 127und 128). In diesem Fall möchten Sie auch die Anweisungen redirect-localoder drücken redirect-local def1, um sicherzustellen, dass das Standard-Gateway und damit die Verbindung des Clients zum VPN-Server nicht verloren gehen.
Die beste Lösung ist meiner Meinung nach jedoch, das VPN-Subnetz in etwas „Hässliches“ zu ändern, das wahrscheinlich nicht mit Heimnetzwerken kollidiert (zum Beispiel richten viele Leute ihr Heimnetzwerk auf etwas wie ein 10.287.29.0/24). Das mag eine gewaltige Aufgabe sein, ist aber der „saubere“ Weg. Außerdem ist es der beste Weg, um sicherzustellen, dass Sie aufgrund überlappender Subnetze keine Überraschungen erleben.