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.