Servidor VPN Mac OS X 10.8: omitir la VPN para el tráfico LAN (enrutar el tráfico LAN a una conexión secundaria)


10

Tengo una configuración un tanto extraña para un servidor VPN con OS X Mountain Lion. Básicamente se está utilizando como un puente para evitar el firewall de mi empresa a nuestra conexión de extranet; ciertas cosas que nuestro equipo debe hacer requieren acceso sin restricciones al exterior, y cambiar las políticas de TI para permitir el tráfico a través del firewall principal no es una opción.

La conexión de extranet se proporciona a través de un enrutador Wireless-N (llamémoslo Wi-Fi X). Mi servidor Mac Mini está configurado con la conexión a este enrutador como la conexión principal, por lo tanto, el acceso sin restricciones a Internet a través del enrutador. Las conexiones a este dispositivo en la subred inmediata son posibles a través del puerto LAN, pero fuera de la subred las cosas son menos confiables.

Pude configurar el servidor VPN para proporcionar direcciones IP a clientes en el rango 192.168.11.150-192.168.11.200 usando PPTP y L2TP, y puedo conectarme a la extranet a través de la VPN usando la VPN estándar de Mac OS X cliente en Preferencias del sistema, sin embargo, como era de esperar, una dirección local (llamémosla internal.company.com) no devuelve nada.

Intenté evitar la limitación del servidor VPN configurando rutas en la configuración de VPN. Nuestra empresa utiliza 13.xxx para todo el tráfico interno, en lugar de 10.xxx, por lo que la tabla de enrutamiento se parecía a esto:

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

Tenía la impresión de que si no se ingresaba nada aquí, todo el tráfico se enrutaba a través de la VPN. Con algo ingresado, solo el tráfico marcado específicamente para pasar por la VPN pasaría a través de la VPN, y todo el resto del tráfico dependería del cliente para acceder utilizando su propia conexión predeterminada. Es por eso que tuve que marcar específicamente cada subred, excepto 13.xxx como Privada.

Sospecho que, dado que no puedo acceder al servidor VPN desde fuera de la subred local, no se está conectando al servidor DNS principal y, por lo tanto, no se puede acceder a la red más grande. Estoy pensando que ingresar nombres de host como internal.company.com no se devuelve al cliente para que lo resuelva, porque el servidor no tiene idea de que la dirección IP cae en el rango público, ya que sospecho (probablemente debería probarlo, pero no tengo acceso a él en este momento) que no puede llegar al servidor DNS para averiguar nada sobre ese nombre de host.

Me parece que todas mis opciones para resolver esto se reducen al mismo tipo de solución:

Descubre cómo llegar al DNS con la conexión secundaria en el servidor. Estoy pensando que si puedo hacer [algo] para que mi servidor reconozca que también debería verificar mi puerta de enlace local (digamos IP del servidor == 13.100.100.50 y Puerta de enlace IP == 13.100.100.1). Desde allí, Gateway IP puede decirme que busque el servidor DNS en 13.1.1.1 y me brinde información sobre mi red interna. Estoy muy confundido acerca de este camino, realmente no estoy seguro de si tengo sentido.

Pensé en intentar hacer este lado del cliente, pero eso tampoco tiene sentido, ya que eso agregaría tiempo a cada configuración del lado del cliente. Además, parece más lógico resolverlo en el servidor: podría deshacerme de mi tabla de enrutamiento por completo o conservarlo. Creo que la única diferencia sería que el tráfico interno también pasaría por el servidor, probablemente una carga innecesaria para eso.

¿Alguna ayuda por ahí? ¿O estoy sobre mi cabeza? El proxy directo o el proxy transparente también es una opción para mí, aunque no tengo idea de cómo configurar ninguno de los dos. (Lo sé, Google es mi amigo).


tal vez esta otra publicación pueda ser de ayuda: superuser.com/questions/453766/…
Lorenzo Von Matterhorn

Respuestas:


2

Bueno, le doy una oportunidad:

No estoy seguro de cómo conseguir que pase un poco de tráfico. Puedo resolver su problema, pero esto requeriría un pequeño cambio en su configuración. Supongo que su Mac tiene dos interfaces de red, llamémoslas eth0 y eth1 :-)

asumiremos que eth0 está conectado a su red de trabajo y tiene una dirección interna (red de trabajo) de 13.1.1.6, subred 255.0.0.0.

también asumiremos que eth1 está conectado a su WiFi X y tiene una dirección (eth1 <---> WiFi X network) de 192.168.1.10, subred 255.0.0.0, para simplificar las cosas.

He configurado servidores VPN en BSD y Linux, pero no en Mac, sin embargo, el concepto seguirá siendo el mismo, tiene opciones, enumeraré una:

1) Asegúrese de que la tabla de enrutamiento en Mac tenga una entrada de la siguiente manera:

$>sudo route add 13.0.0.0/8 eth0

Lo que esto hará es asegurarse de que cualquier tráfico que ingrese a través de la interfaz WiFi X o VPN que esté destinada a la red de su empresa (la red 13) llegue allí. Sin esto, la Mac (que proporciona el puente) realmente no tiene forma de saber cómo enrutar el tráfico entre las dos interfaces, y por defecto intentará enviarlo desde cualquier interfaz que sea la predeterminada, que es WiFi X que usted indicó.

Deshacería lo que le hiciste a la tabla de enrutamiento VPN anterior e intentaría esto si no está (con suerte) ya allí.

Si lo anterior no lo hace, actualice con la tabla de enrutamiento de su servidor VPN y la lista de direcciones IP, o actualice con cualquier solución que haya encontrado. Espero que esto te señale en la dirección correcta.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.