.png)
Ich habe ein etwas seltsames Setup für einen VPN-Server mit OS X Mountain Lion. Er wird im Wesentlichen als Brücke verwendet, um die Firewall meines Unternehmens zu unserer Extranet-Verbindung zu umgehen - bestimmte Dinge, die unser Team tun muss, erfordern uneingeschränkten Zugriff nach außen, und die Änderung der IT-Richtlinien, um Datenverkehr durch die Hauptfirewall zuzulassen, ist einfach keine Option.
Die Extranet-Verbindung wird über einen Wireless-N-Router (nennen wir ihn Wi-Fi X) bereitgestellt. Mein Mac Mini-Server ist mit der Verbindung zu diesem Router als primäre Verbindung konfiguriert, sodass über den Router uneingeschränkter Zugriff auf das Internet möglich ist. Verbindungen zu diesem Gerät im unmittelbaren Subnetz sind über den LAN-Port möglich, außerhalb des Subnetzes sind die Dinge jedoch weniger zuverlässig.
Ich konnte den VPN-Server so konfigurieren, dass er den Clients im Bereich 192.168.11.150-192.168.11.200 über PPTP und L2TP IP-Adressen bereitstellt. Außerdem kann ich mithilfe des Standard-VPN-Clients von Mac OS X in den Systemeinstellungen über das VPN eine Verbindung zum Extranet herstellen. Allerdings gibt eine lokale Adresse (nennen wir sie internal.company.com) – wenig überraschend – nichts zurück.
Ich habe versucht, die Einschränkung des VPN-Servers zu umgehen, indem ich in den VPN-Einstellungen Routen eingerichtet habe. Unser Unternehmen verwendet für den gesamten internen Datenverkehr 13.xxx statt 10.xxx, daher sah die Routing-Tabelle ungefähr so aus:
IP Address ---------- Subnet Mask ---------- Configuration
0.0.0.0 248.0.0.0 Private
8.0.0.0 252.0.0.0 Private
12.0.0.0 255.0.0.0 Private
13.0.0.0 255.0.0.0 Public
14.0.0.0 254.0.0.0 Private
16.0.0.0 240.0.0.0 Private
32.0.0.0 224.0.0.0 Private
64.0.0.0 192.0.0.0 Private
128.0.0.0 128.0.0.0 Private
Ich war der Meinung, dass, wenn hier nichts eingegeben wurde, der gesamte Datenverkehr über das VPN geleitet wird. Wenn etwas eingegeben wurde, würde nur der Datenverkehr, der ausdrücklich für die Weiterleitung über das VPN gekennzeichnet ist, über das VPN geleitet, und auf den restlichen Datenverkehr müsste der Client über seine eigene Standardverbindung zugreifen. Aus diesem Grund musste ich jedes Subnetz außer 13.xxx ausdrücklich als privat markieren.
Ich vermute, dass der VPN-Server, da ich ihn von außerhalb des lokalen Subnetzes nicht erreichen kann, keine Verbindung zum Haupt-DNS-Server herstellt und daher im größeren Netzwerk nicht erreichbar ist. Ich denke, dass eingegebene Hostnamen wie internal.company.com nicht an den Client zurückgeschickt werden, um sie aufzulösen, da der Server keine Ahnung hat, dass die IP-Adresse im öffentlichen Bereich liegt, da ich vermute (wahrscheinlich sollte ich einen Ping-Test durchführen, habe aber gerade keinen Zugriff darauf), dass er den DNS-Server nicht erreichen kann, um etwas über diesen Hostnamen herauszufinden.
Mir scheint, dass alle meine Optionen zur Lösung dieses Problems auf die gleiche Art von Lösung hinauslaufen:
Finden Sie heraus, wie Sie den DNS mit der sekundären Verbindung auf dem Server erreichen. Ich denke, wenn ich [etwas] tun kann, damit mein Server das erkennt, sollte er auch mein lokales Gateway überprüfen (sagen wir, Server-IP == 13.100.100.50 und Gateway-IP == 13.100.100.1). Von dort aus kann mir die Gateway-IP sagen, dass ich den DNS-Server unter 13.1.1.1 suchen soll, und mir Informationen über mein internes Netzwerk geben. Ich bin sehr verwirrt über diesen Pfad – ich bin mir wirklich nicht sicher, ob das überhaupt Sinn ergibt.
Ich habe darüber nachgedacht, dies clientseitig zu tun, aber das macht auch keinen Sinn, da dies jede einzelne clientseitige Einrichtung zeitaufwändiger machen würde. Außerdem scheint es logischer, das Problem auf dem Server zu lösen – ich könnte meine Routing-Tabelle entweder ganz loswerden oder sie behalten – ich denke, der einzige Unterschied wäre, dass der interne Datenverkehr auch über den Server laufen würde – wahrscheinlich eine unnötige Belastung für ihn.
Gibt es da draußen Hilfe? Oder bin ich überfordert? Forward-Proxy oder transparenter Proxy sind für mich auch eine Option, obwohl ich keine Ahnung habe, wie ich sie einrichte. (Ich weiß, Google ist mein Freund.)
Antwort1
Naja, ich probier es mal aus:
Ich bin mir nicht sicher, wie ich nur einen Teil des Datenverkehrs durchlassen kann. Ich kann Ihr Problem lösen, aber dazu müssten Sie Ihr Setup ein wenig ändern. Ich gehe davon aus, dass Ihr Mac über zwei Netzwerkschnittstellen verfügt, nennen wir sie eth0 und eth1 :-)
Wir gehen davon aus, dass eth0 mit Ihrem Arbeitsnetzwerk verbunden ist und eine interne (Arbeitsnetzwerk-)Adresse von 13.1.1.6, Subnetz 255.0.0.0 hat.
der Einfachheit halber gehen wir außerdem davon aus, dass eth1 mit Ihrem WiFi X verbunden ist und eine Adresse (eth1 <---> WiFi X-Netzwerk) von 192.168.1.10, Subnetz 255.0.0.0 hat.
Ich habe VPN-Server unter BSD und Linux eingerichtet, aber nicht unter Mac. Das Konzept ist jedoch dasselbe. Sie haben Optionen. Ich liste eine auf:
1)Stellen Sie sicher, dass die Routing-Tabelle auf dem Mac folgenden Eintrag enthält:
$>sudo route add 13.0.0.0/8 eth0
Dadurch wird sichergestellt, dass der gesamte Datenverkehr, der über die WiFi X- oder VPN-Schnittstelle eingeht und für das Netzwerk Ihres Unternehmens (das 13-Netzwerk) bestimmt ist, dort ankommt. Ohne diese Verbindung weiß der Mac (der die Brücke bereitstellt) nicht, wie er den Datenverkehr zwischen den beiden Schnittstellen weiterleiten soll, und standardmäßig versucht er, ihn über die Standardschnittstelle zu senden, also über das von Ihnen angegebene WiFi X.
Ich würde Ihre obigen Schritte mit der VPN-Routingtabelle rückgängig machen und Folgendes versuchen, falls es (hoffentlich) noch nicht vorhanden ist.
Wenn das oben genannte nicht funktioniert, aktualisieren Sie bitte die Routing-Tabelle und die IP-Adressliste Ihres VPN-Servers oder aktualisieren Sie mit einem beliebigen Fix, den Sie gefunden haben. Ich hoffe, dies weist Sie in die richtige Richtung.