Solución:
Solución 1:
Si necesita una solución temporal sucia para una o varias ips de servidor conocidas, 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 route delete.
Solucion 2:
Es posible resolver esto usando NAT; simplemente no es muy elegante.
Entonces, bajo el supuesto de que no podría resolver esto al tener redes internas que tienen números de red tan poco comunes como para que nunca entren 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í arriba:
- La red de su oficina utiliza 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 con NAT 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. Además, supongamos que todos los hosts están asignados 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 NAT de la oficina
- El host de red de su oficina remota 192.0.2.5/24 está asignado estáticamente como 203.0.113.5/24 en la puerta de enlace vpn NAT de la oficina remota
Entonces, cuando el host 192.0.2.5/24 en la oficina remota quiere 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 al que se accede a través de la VPN y se enruta allí.
- En la oficina remota, el host 192.0.2.5 se hace pasar por 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 existe 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; El DNS se vuelve complejo. Esto se debe a que los puntos finales deben tener una dirección IP única, 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.
- El mapeo estático de hosts es imprescindible para la accesibilidad desde 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 con NAT dinámicamente si lo desea.
- Si el tráfico es bidireccional, ambos extremos necesitan un mapeo estático de todos los hosts involucrados.
- La conectividad a Internet no debe verse afectada independientemente de la VPN dividida o no dividida.
- Si no puede mapear 1 a 1, se complica; una contabilidad cuidadosa es una necesidad.
- Naturalmente, se corre el riesgo de utilizar direcciones NAT que también resultan ser duplicadas 🙂
Entonces, resolver esto requiere un diseño cuidadoso. Si su oficina remota realmente consta de guerreros de la carretera, agrega una capa de problemas en eso:
- nunca saben de antemano cuándo terminan en identificadores de red superpuestos.
- 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 el 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, es posible que pueda 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 de NAT que, por así decirlo, tiene lugar dentro de la perspectiva del túnel. En cuanto al proceso, el mapeo NAT estático debe realizarse antes de que el paquete “entre” en el 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 no se deben 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 completamente fuera de la perspectiva del transporte al sitio remoto a través de VPN) con las direcciones privadas únicas que se utilizan como mascaradas. para las direcciones privadas duplicadas. Si esta abstracción es difícil de imaginar, aquí se hace una ilustración de cómo NAT se puede separar físicamente de la puerta de enlace VPN para este propósito:
Uso de NAT en redes superpuestas.
Condensar la misma imagen en una separación lógica dentro de una máquina, capaz de realizar las funciones 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.
En cuanto al software, ciertamente es posible:
PIX / ASA 7.xy posterior: VPN IPsec de 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
Por lo tanto, la implementación real depende de muchos factores, los sistemas operativos involucrados, el software asociado y sus posibilidades no menos importante. Pero ciertamente es factible. Necesitarías pensar y experimentar un poco.
Aprendí esto de Cisco como lo ven los enlaces.
Solución 3:
sí, esto es lo peor. para mí, sucedió todo el tiempo desde las 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 utilice una red inalámbrica como esa.
así que la respuesta es “arreglar” el wap para usar una red interna diferente (es decir, 10.255.255.0/24) y luego darle una concesión de diferencia (es decir, ip en un rango que puede enrutar de regreso a corp vpn), o si no tiene No puedo obtener administrador en wap, solo vaya a Starbucks. o 20 minutos de conducción 🙂
si esto es solo en un entorno de laboratorio, simplemente use diferentes rangos.
Solución 4:
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
Solución 5:
Estoy en una Mac con El Capitán. Si bien las sugerencias anteriores no funcionaron para mí, me llevaron a una solución de trabajo:
- antes de iniciar VPN, ejecute
ifconfig -
inicie la VPN, haga
ifconfigy observe cuál es la nueva interfaz. En mi caso fue ppp0 con una dirección IP de 192.168.42.74ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00 -
escribir:
sudo route add 192.168.1.79 192.168.42.74
Probé primero con un ping y 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ó.