Conexión a un servidor remoto a través de una VPN cuando la dirección de subred de la red local entra en conflicto con una red remota

Esta es una pregunta canónica sobre la resolución de conflictos de subred IPv4 entre la red local de un cliente VPN y una a través del enlace VPN de esta.

Después de conectarse a una ubicación remota a través de OpenVPN, los clientes intentan acceder a un servidor en una red que existe en una subred como 192.0.2.0/24. Sin embargo, a veces, la red en la LAN del cliente tiene la misma dirección de subred: 192.0.2.0/24. Los clientes no pueden conectarse al servidor remoto escribiendo su IP debido a este conflicto. Ni siquiera pueden acceder a Internet público mientras están conectados a la VPN.

El problema es que esta subred 192.0.2.0/24 necesita ser enrutada por la VPN, pero también debe enrutarse como la LAN del cliente.

¿Alguien sabe cómo mitigar este problema? Tengo acceso al servidor OpenVPN.

Es posible resolver esto usando NAT; Simplemente no es muy elegante.

Entonces, bajo el supuesto de que no podría resolver esto teniendo redes internas que tengan números de red tan poco comunes como para nunca entrar en conflicto, este es el principio:

Como tanto la subred local como la remota tienen números de red idénticos, el tráfico de su cliente nunca se dará cuenta de que tiene que pasar por la puerta de enlace del túnel para llegar a su destino. E incluso si imaginamos que podría, la situación sería la misma para el host remoto que está a punto de enviar una respuesta.

Así que quédate conmigo y finge que, hasta el momento, no hay problemas secundarios mientras escribo que para una conectividad completa, necesitarías NAT en ambos extremos dentro del túnel para diferenciar los hosts y permitir el enrutamiento.

Haciendo algunas redes aquí:

• La red de su oficina usa 192.0.2.0/24
• Su oficina remota usa 192.0.2.0/24
• La puerta de enlace VPN de la red de su oficina oculta 192.0.2.0/24 hosts detrás del número de red NATed 198.51.100.0/24
• La puerta de enlace VPN de la red de su oficina remota oculta 192.0.2.0/24 hosts detrás del número de red NATed 203.0.113.0/24

Entonces, dentro del túnel VPN, los hosts de la oficina ahora son 198.51.100.xy los hosts de la oficina remota son 203.0.113.x. Supongamos, además, que todos los hosts están mapeados 1: 1 en el NAT de sus respectivas puertas de enlace VPN. Un ejemplo:

• El host de red de su oficina 192.0.2.5/24 está asignado estáticamente como 198.51.100.5/24 en la puerta de enlace vpn de la oficina NAT.
• El host de red de su oficina remota 192.0.2.5/24 se asigna estáticamente como 203.0.113.5/24 en la puerta de enlace de VPN de la oficina remota NAT

Entonces, cuando el host 192.0.2.5/24 en la oficina remota desea conectarse al host con la misma ip en la red de la oficina, debe hacerlo utilizando la dirección 198.51.100.5/24 como destino. Sucede lo siguiente:

• En la oficina remota, el host 198.51.100.5 es un destino remoto alcanzado a través de la VPN y enrutado allí.
• En la oficina remota, el host 192.0.2.5 se enmascara como 203.0.113.5 cuando el paquete pasa la función NAT.
• En la oficina, el host 198.51.100.5 se traduce a 192.0.2.5 cuando el paquete pasa la función NAT.
• En la oficina, el tráfico de retorno al host 203.0.113.5 pasa por el mismo proceso en la dirección inversa.

Entonces, si bien hay una solución, hay una serie de problemas que deben abordarse para que esto funcione en la práctica:

• La IP enmascarada debe usarse para conectividad remota; DNS se vuelve complejo. Esto se debe a que los puntos finales deben tener una dirección IP única, tal como se ve desde el host de conexión.
• Se debe implementar una función NAT en ambos extremos como parte de la solución VPN.
• La asignación estática de hosts es imprescindible para alcanzar el otro extremo.
• Si el tráfico es unidireccional, solo el extremo receptor necesita un mapeo estático de todos los hosts involucrados; el cliente puede salirse con la suya dinámica si es deseable.
• Si el tráfico es bidireccional, ambos extremos necesitan una asignación estática de todos los hosts involucrados.
• La conectividad a Internet no debe verse afectada independientemente de la VPN dividida o no dividida.
• Si no puede asignar 1 a 1, se vuelve desordenado; Una cuidadosa contabilidad es una necesidad.
• Naturalmente, uno corre el riesgo de usar direcciones NAT que también resultan ser duplicados :-)

Entonces resolver esto necesita un diseño cuidadoso. Si su oficina remota realmente consiste en guerreros de la carretera, agrega una capa de problemas en eso:

• nunca saben de antemano cuándo terminan en superposición de identificadores de red.
• la puerta de enlace de la oficina remota NAT debería implementarse en sus computadoras portátiles.
• la puerta de enlace de la oficina necesitaría dos VPN, una sin NAT y otra con NAT, para cubrir ambos escenarios. De lo contrario, en caso de que alguien eligiera una de las subredes que eligió para el método NAT, las cosas no funcionarían .

Dependiendo de su cliente VPN, puede seleccionar automáticamente una VPN u otra dependiendo de la dirección de red del segmento local.

Observe que toda mención de NAT en este contexto denota una función NAT que, por así decirlo, tiene lugar dentro de la perspectiva del túnel. En el proceso, la asignación de NAT estática se debe realizar antes de que el paquete "ingrese" al túnel, es decir, antes de que se encapsule en el paquete de transporte que lo llevará a través de Internet a la otra puerta de enlace VPN.

Esto significa que uno no debe confundir las direcciones IP públicas de las puertas de enlace VPN (y que en la práctica también pueden ser NAT: ed, pero luego totalmente fuera de la perspectiva del transporte al sitio remoto a través de VPN) con las direcciones privadas únicas utilizadas como enmascarados para las direcciones privadas duplicadas. Si esta abstracción es difícil de imaginar, aquí se hace una ilustración de cómo NAT puede separarse físicamente de la puerta de enlace VPN:
Usar NAT en redes superpuestas .

Condensar la misma imagen a una separación lógica dentro de una máquina, capaz de realizar la funcionalidad de puerta de enlace NAT y VPN, es simplemente llevar el mismo ejemplo un paso más allá, pero pone mayor énfasis en las capacidades del software en cuestión. Hackearlo junto con, por ejemplo, OpenVPN e iptables y publicar la solución aquí sería un desafío digno.

Por software, ciertamente es posible:
PIX / ASA 7.xy posterior: VPN IPsec LAN a LAN con ejemplo de configuración de redes superpuestas
y:
Configuración de un túnel IPSec entre enrutadores con subredes LAN duplicadas

La implementación real, por lo tanto, depende de muchos factores, los sistemas operativos involucrados, el software asociado y sus posibilidades, como mínimo. Pero ciertamente es factible. Tendría que pensar y experimentar un poco.

Aprendí esto de Cisco como lo ven los enlaces.

Si necesita una solución temporal sucia para un único servidor o un puñado de servidores conocidos, la solución más simple debería ser la opción de enrutamiento estático del lado del cliente.

En mi caso, agregué mi servidor de destino deseado (192.168.1.100) a mi tabla de enrutamiento en mi cliente Linux a través de:

route add 192.168.1.100 dev tun0

Luego, elimine esta ruta estática con el comando de eliminación de ruta.

Sí, esto es lo peor. para mí sucedió todo el tiempo desde habitaciones de hotel, antes de que los administradores de VPN se dieran cuenta de que deberían usar rangos de IP más oscuros. 10.0.0.0/24 y 10.1.1.1/24 son los peores. si puede ayudarlo, nunca use una red inalámbrica como esa.

por lo tanto, la respuesta es "arreglar" el wap para usar una red interna diferente (es decir, 10.255.255.0/24) y luego darle un contrato de arrendamiento diferencial (es decir, ip en un rango que puede enrutar de nuevo a corp vpn), o si no tiene / no puedo obtener administrador en wap, solo ve a starbucks. o 20 minutos de Wardriving :)

si esto es solo en una configuración de laboratorio, solo use diferentes rangos.

Estoy en una Mac con El Capitan. Si bien las sugerencias anteriores no funcionaron para mí, me llevaron a una solución que funciona:

1. antes de iniciar VPN, ejecute ifconfig

2. Inicie la VPN, haga ifconfigy observe cuál es la nueva interfaz. En mi caso, era ppp0 con una dirección IP de 192.168.42.74

   ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
       inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00
   

3. escribir:

   sudo route add 192.168.1.79  192.168.42.74
   

Primero probé con a pingy luego probé que funcionaba accediendo al servidor git.

Cuando intenté usar dev ppp0 para el final del comando de ruta como se mencionó anteriormente, se quejó.

Tengo una solución simple que estoy usando en un espacio de trabajo compartido que tiene un rango de IP en conflicto (10.x)

Me conecté a la red con mi teléfono móvil, luego compartí la conexión de red a través de Bluetooth con mi computadora portátil. Ahora puedo usar la VPN para mi empleador remoto.

Estoy seguro de que esto funcionará igual a través de USB si necesita una conexión más rápida.

Si solo necesita presionar algunas de una o dos direcciones IP, agregue la declaración de ruta a su archivo de configuración ovpn de esta manera:

ruta 192.168.1.10 255.255.255.255

ruta 192.168.1.11 255.255.255.255

Agregará una ruta solo para esos IP cuando conecte su VPN y la eliminará cuando se desconecte.

Trabajó para mí en Windows de todos modos.

La respuesta de Aydin K. es para Linux. Si desea la misma funcionalidad para Windows, puede escribir

route ADD 192.168.1.10 <IP of tunnel adapter>

o

route ADD 192.168.1.10 IF <interface id>

puede obtener la identificación de la interfaz con el comando:

route print

Solo como recordatorio: ¡todo este problema se debe a años de escasez de direcciones IPv4 y al uso extensivo del rango de IP privado detrás de NAT para solucionar esta escasez!

La solución ideal y definitiva para este problema es bastante sencilla (aunque puede, y lo hará, lleva un tiempo desplegarse globalmente): IPv6 ...

En un mundo IPv6, no hay escasez pública de IP (y no habrá un evento en unas pocas décadas). Por lo tanto, no hay razón para no tener una IP pública en todos y cada uno de los dispositivos de cada red. Y si necesita aislamiento de red, siga filtrando con un firewall, pero sin NAT feo ...