Serveur VPN Mac OS X 10.8: contournez le VPN pour le trafic LAN (routage du trafic LAN vers une connexion secondaire)


10

J'ai un peu une configuration étrange pour un serveur VPN avec OS X Mountain Lion. Il est essentiellement utilisé comme pont pour contourner le pare-feu de mon entreprise à notre connexion extranet - certaines choses que notre équipe doit faire nécessitent un accès sans entrave à l'extérieur, et la modification des politiques informatiques pour autoriser le trafic via le pare-feu principal n'est tout simplement pas une option.

La connexion extranet est fournie via un routeur sans fil N (appelons-le Wi-Fi X). Mon serveur Mac Mini est configuré avec la connexion à ce routeur comme connexion principale, donc un accès illimité à Internet via le routeur. Les connexions à cet appareil sur le sous-réseau immédiat sont possibles via le port LAN, mais en dehors du sous-réseau, les choses sont moins fiables.

J'ai pu configurer le serveur VPN pour fournir des adresses IP aux clients dans la plage 192.168.11.150-192.168.11.200 en utilisant PPTP et L2TP, et je suis en mesure de me connecter à l'extranet via le VPN en utilisant le VPN Mac OS X standard client dans les Préférences Système, mais sans surprise, une adresse locale (appelons-la internal.company.com) ne renvoie rien.

J'ai essayé de contourner la limitation du serveur VPN en configurant des itinéraires dans les paramètres VPN. Notre société utilise 13.xxx pour tout le trafic interne, au lieu de 10.xxx, donc la table de routage ressemblait à ceci:

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

J'avais l'impression que si rien n'était entré ici, tout le trafic était acheminé via le VPN. Avec quelque chose entré, seul le trafic spécifiquement marqué pour passer par le VPN passerait par le VPN, et tout autre trafic serait au client d'accéder à l'aide de sa propre connexion par défaut. C'est pourquoi j'ai dû marquer spécifiquement chaque sous-réseau sauf 13.xxx comme privé.

Ma suspicion est que, puisque je ne peux pas atteindre le serveur VPN depuis l'extérieur du sous-réseau local, il ne se connecte pas au serveur DNS principal et ne peut donc pas être atteint sur le plus grand réseau. Je pense que la saisie de noms d'hôte comme internal.company.com n'est pas renvoyée au client pour résolution, car le serveur n'a aucune idée que l'adresse IP tombe dans la plage publique, car je soupçonne (devrait probablement tester ping mais n'y avez pas accès pour l'instant) qu'il ne peut pas atteindre le serveur DNS pour trouver quoi que ce soit sur ce nom d'hôte.

Il me semble que toutes mes options pour résoudre tout cela se résument au même type de solution:

Découvrez comment atteindre le DNS avec la connexion secondaire sur le serveur. Je pense que si je peux faire [quelque chose] pour que mon serveur reconnaisse qu'il doit également vérifier ma passerelle locale (disons IP du serveur == 13.100.100.50 et IP de la passerelle == 13.100.100.1). À partir de là, Gateway IP peut me dire d'aller trouver le serveur DNS au 13.1.1.1 et de me donner des informations sur mon réseau interne. Je suis très confus à propos de ce chemin - je ne sais vraiment pas si j'ai du sens.

J'ai pensé à essayer de faire ce côté client, mais cela n'a pas de sens non plus, car cela ajouterait du temps à chaque configuration côté client. De plus, il semble juste plus logique de le résoudre sur le serveur - je pourrais soit me débarrasser complètement de ma table de routage, soit le conserver - je pense que la seule différence serait que le trafic interne passerait également par le serveur - probablement une charge inutile pour il.

Une aide là-bas? Ou suis-je au-dessus de ma tête? Le proxy direct ou le proxy transparent est également une option pour moi, bien que je ne sache pas comment configurer l'un ou l'autre. (Je sais, Google est mon ami.)


peut-être que cet autre article peut être utile: superuser.com/questions/453766/…
Lorenzo Von Matterhorn

Réponses:


2

Eh bien, je donne un coup de feu:

Je ne sais pas comment obtenir uniquement du trafic, je peux résoudre votre problème, mais cela prendrait un peu de changement dans votre configuration. Je suppose que votre Mac possède deux interfaces réseau, appelons-les eth0 et eth1 :-)

nous supposerons que eth0 est connecté à votre réseau de travail et possède une adresse interne (réseau de travail) de 13.1.1.6, sous-réseau 255.0.0.0.

nous supposerons également que eth1 est connecté à votre WiFi X et a une adresse (réseau eth1 <---> WiFi X) de 192.168.1.10, sous-réseau 255.0.0.0, pour simplifier les choses.

J'ai configuré des serveurs VPN sur BSD et Linux, mais pas sur Mac, mais le concept sera toujours le même, vous avez des options, je vais en énumérer une:

1) Assurez-vous que la table de routage sur le Mac a une entrée comme suit:

$>sudo route add 13.0.0.0/8 eth0

Cela vous permettra de vous assurer que tout trafic entrant sur l'interface WiFi X ou VPN destiné au réseau de votre entreprise (le réseau 13) y parviendra. Sans cela, le Mac (qui fournit le pont) n'a vraiment aucun moyen de savoir comment acheminer le trafic entre les deux interfaces, et par défaut, il essaiera de l'envoyer à partir de l'interface par défaut, c'est-à-dire WiFi X, vous avez déclaré.

Je voudrais annuler ce que vous avez fait à la table de routage VPN ci-dessus et essayer ceci si ce n'est pas (espérons-le) déjà là.

Si ce qui précède ne le fait pas, veuillez mettre à jour avec la table de routage et la liste d'adresses IP de votre serveur VPN, ou mettre à jour avec tout correctif que vous avez rencontré. J'espère que cela vous indique la bonne direction.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.