É possível resolver isso usando NAT; simplesmente não é muito elegante.
Portanto, sob a suposição de que você não poderia resolver isso com redes internas com números de rede tão incomuns que nunca entram em conflito, aqui está o princípio:
Como a sub-rede local e a remota têm números de rede idênticos, o tráfego do seu cliente nunca perceberá que precisa passar pelo gateway de túnel para alcançar seu destino. E mesmo se imaginarmos que poderia, a situação seria a mesma para o host remoto, pois está prestes a enviar uma resposta.
Portanto, fique comigo e finja que, até o momento, não há problemas secundários enquanto escrevo que, para uma conectividade completa, você precisará do NAT nas duas extremidades dentro do túnel, a fim de diferenciar os hosts e permitir o roteamento.
Fazendo algumas redes aqui em cima:
- A rede do seu escritório usa 192.0.2.0/24
- Seu escritório remoto usa 192.0.2.0/24
- O gateway VPN da rede do escritório oculta os hosts 192.0.2.0/24 atrás do número de rede NAT 198.51.100.0/24
- O gateway VPN da rede do escritório remoto oculta os hosts 192.0.2.0/24 atrás do número da rede NAT 203.0.113.0/24
Portanto, dentro do túnel da VPN, os hosts do escritório agora são 198.51.100.xe os hosts do escritório remoto são 203.0.113.x. Além disso, vamos fingir que todos os hosts estão mapeados 1: 1 no NAT de seus respectivos gateways VPN. Um exemplo:
- O host de rede do escritório 192.0.2.5/24 é mapeado estaticamente como 198.51.100.5/24 no NAT do gateway vpn do escritório
- O host de rede do escritório remoto 192.0.2.5/24 é mapeado estaticamente como 203.0.113.5/24 no NAT do gateway vpn do escritório remoto
Portanto, quando o host 192.0.2.5/24 no escritório remoto deseja conectar-se ao host com o mesmo ip na rede do escritório, ele precisa fazer isso usando o endereço 198.51.100.5/24 como destino. O seguinte acontece:
- No escritório remoto, o host 198.51.100.5 é um destino remoto alcançado pela VPN e roteado para lá.
- No escritório remoto, o host 192.0.2.5 é mascarado como 203.0.113.5 quando o pacote passa na função NAT.
- No escritório, o host 198.51.100.5 é convertido para 192.0.2.5 quando o pacote passa na função NAT.
- No escritório, o tráfego de retorno para o host 203.0.113.5 passa pelo mesmo processo na direção reversa.
Portanto, embora exista uma solução, há vários problemas que devem ser abordados para que isso funcione na prática:
- O IP mascarado deve ser usado para conectividade remota; O DNS fica complexo. Isso ocorre porque os pontos de extremidade devem ter um endereço IP exclusivo, conforme exibido no host de conexão.
- Uma função NAT deve ser implementada nos dois extremos como parte da solução VPN.
- O mapeamento estatístico de hosts é essencial para a acessibilidade do outro lado.
- Se o tráfego for unidirecional, apenas a extremidade receptora precisará de mapeamento estático de todos os hosts envolvidos; o cliente pode se livrar da NAT dinamicamente, se desejar.
- Se o tráfego for bidirecional, as duas extremidades precisam de mapeamento estático de todos os hosts envolvidos.
- A conectividade com a Internet não deve ser prejudicada, independentemente da VPN dividida ou não dividida.
- Se você não pode mapear 1 para 1, fica confuso; escrituração cuidadosa é uma necessidade.
- Naturalmente, corre-se o risco de usar endereços NAT que também se tornam duplicados :-)
Portanto, resolver isso precisa de um design cuidadoso. Se o seu escritório remoto realmente é formado por guerreiros da estrada, você adiciona uma camada de problemas:
- eles nunca sabem de antemão quando acabam com IDs líquidos sobrepostos.
- o NAT do gateway do escritório remoto precisaria ser implementado em seus laptops.
- o gateway do escritório precisaria de duas VPNs, uma sem NAT e uma NAT, para cobrir os dois cenários. Caso contrário, no caso de alguém escolher uma das sub-redes que você escolheu para o método NAT, as coisas não funcionariam .
Dependendo do seu cliente VPN, você poderá selecionar automaticamente uma VPN ou outra, dependendo do endereço de rede do segmento local.
Observe que todas as menções ao NAT nesse contexto denotam uma função NAT que, por assim dizer, ocorre na perspectiva do túnel. Em termos processuais, o mapeamento estático de NAT deve ser feito antes que o pacote "entre" no túnel, ou seja, antes de ser encapsulado no pacote de transporte, que deve levá-lo pela Internet até o outro gateway VPN.
Isso significa que não se deve confundir os endereços IP públicos dos gateways VPN (e que, na prática, também podem ser NAT: ed, mas totalmente fora da perspectiva de transporte para o site remoto por VPN) com os endereços privados exclusivos usados como disfarces. para os endereços particulares duplicados. Se essa abstração é difícil de visualizar, é apresentada aqui uma ilustração de como o NAT pode ser fisicamente separado do gateway VPN para esse fim:
Uso do NAT em redes sobrepostas .
Condensar a mesma imagem a uma separação lógica dentro de uma máquina, capaz de executar a funcionalidade de gateway NAT e VPN, está simplesmente dando o mesmo exemplo um passo adiante, mas coloca mais ênfase nos recursos do software em questão. Hackear junto com, por exemplo, OpenVPN e iptables e postar a solução aqui seria um desafio digno.
Em termos de software, certamente é possível:
PIX / ASA 7.xe posterior: VPN IPsec de LAN para LAN com exemplo de configuração de redes sobrepostas
e:
Configurando um túnel IPSec entre roteadores com sub-redes de LAN duplicadas
Portanto, a implementação real depende de muitos fatores, dos sistemas operacionais envolvidos, do software associado e de suas possibilidades. Mas certamente é factível. Você precisaria pensar e experimentar um pouco.
Eu aprendi isso com a Cisco, como visto pelos links.