Tenho um projeto que consiste em configurar um novo firewall de borda para lidar com alguns serviços de um fornecedor terceirizado.
Uma parte disso seria estabelecer uma conexão site a site com um fornecedor.
O que aconteceria se ambos os lados tivessem as mesmas sub-redes para o tráfego interessante? O Site A anuncia 10.10.10/24 e o mesmo para o Site B? Eu precisaria fazer NAT no tráfego de entrada do Site B ao atingir meu firewall?
O espaço de endereçamento sobreposto entre ambos os pontos finais causará um problema de encaminhamento. Se eles forem a mesma rede, as rotas locais terão prioridade sobre o túnel.
A solução é traduzir o tráfego antes de enviá-lo pelo túnel.
O Site B não sabe que o NAT está sendo usado para evitar sobreposição de espaço de endereçamento.
Embora existam soluções para sobreposição de espaços de endereçamento, para fornecedores terceirizados com os quais você conecta via VPN, eles quase certamente fornecerão um bloco NAT para sua rede acessar seus serviços. Esta é a solução que vejo mais frequentemente implantada.
O Cliente A recebe 10.10.10.1 para sobrecarregar o NAT para, o Cliente B recebe 10.10.10.2, etc.
Basicamente, isso é fácil de fazer no Cisco ASA e Firepower, pois você pode fazer NAT de origem e destino de ambos os lados (acho que o Palos também suporta isso, não tenho muito contato com Palos, portanto meu conhecimento é limitado), o outro lado nem precisa saber sobre sua rede interna, pois você incluirá o intervalo de IPs NATeados na zona de criptografia.
A única desvantagem é que você precisa acessar o outro lado usando o endereço NAT de destino, no seu caso, ao invés de alcançar o outro lado usando 10.10.10.0/24, talvez seja necessário usar um sub-rede NAT de destino como 192.168.1.0/24.
Se seu firewall ou concentrador VPN não suportar NAT de origem e destino, então você precisará NATear o tráfego de origem e incluir isso na zona de criptografia, e o outro lado precisará fazer o mesmo.
IPv6 se possível, caso contrário temos um /25 de espaço de IPs públicos do ARIN reservado para SNAT para túneis VPN de fornecedores. Como é nosso espaço, podemos garantir que seja globalmente único.
Ele funciona muito bem, se você tiver espaço para isso.
NAT em todos os fornecedores, mantenha uma boa documentação, as pessoas esquecerão.
Provavelmente você terá que fazer NAT para outro endereço.
Como outros disseram, NAT é a chave combinada com VPN site a site baseada em rota (em oposição a baseada em política).
Ótimas respostas neste tópico, certifique-se de considerar cada uma.
Uma coisa que gostaria de acrescentar - se você tiver servidores atrás de NAT ou precisar de conectividade ponto a ponto, então precisará fazer NAT estático nesses endereços IP. O mais fácil seria usar um intervalo de tamanhos iguais, exemplo: se você NATear o tráfego de A para B, o tráfego vindo do site A 10.10.10/24 será NATeado para 192.168.1/24, então cada endereço no intervalo 10.10.10/24 mapeia 1-para-1 para 192.168.1/24, mantendo a conectividade ponto a ponto. Pense nisso como substituir 10.10.10/24 por 192.168.1/24 para o tráfego de A para B.
Se os tamanhos das sub-redes NAT não coincidirem, como NAT de 10.10.10/24 para 192.168.1/30, então você precisa garantir que algumas portas estejam encaminhadas, ou alguns IPs permaneçam estáticos. Existem várias maneiras de fazer isso. Pense nisso como um roteador doméstico - lá você recebe um IP público e, se precisar expor um servidor, precisa fazer encaminhamento de porta para seu servidor. Em ambientes corporativos de NAT, você também pode reservar 1 (ou mais) IPs do intervalo NAT e atribuí-los ao encaminhamento de porta ou tarefas semelhantes, usando o restante do intervalo NAT para outros encaminhamentos.
Nós fazemos NAT de origem para IPs públicos em todas as conexões VPN de terceiros e exigimos que façam o mesmo conosco. Assim, todos os nossos domínios de criptografia estão entre alguns IPs públicos em cada extremidade. Como geralmente fornecemos ou consumimos um serviço, em uma extremidade é apenas NAT de origem de saída e o outro lado (geralmente o nosso) tem uma lista de PATs para serviços internos. Os PATs podem ser um incômodo às vezes, mas é uma dor gerenciável em relação a sobreposições ou conflitos de espaço de IP, até mesmo potencialmente entre terceiros externos.
Obrigado a todos pelas respostas! Isso me ajuda bastante.
Como alguém que faz isso diariamente, normalmente pedimos aos nossos fornecedores que façam NAT na conexão, pois a maioria quer usar um bloco /16 da AWS.
Isso poderia ser feito com Mikrotik, então acredito que outros fornecedores também tenham essa funcionalidade.
Existe uma “ação” nas configurações de NAT chamada “netmap” que pode ser usada para mapear estaticamente toda a sub-rede para outro intervalo…
NAT é sua única escolha.
Também eliminaria a parte “tráfego interessante” e faria apenas VPN IPsec baseada em rota (VTI).
Sim, você terá que fazer NAT.
Vejo muitas respostas aqui que parecem não levar em conta que os endereços exatos estão em uso de ambos os lados do túnel e que o tráfego precisa fluir em duas direções. Isso significa que um único dispositivo de roteamento não pode completar a tarefa, a menos que seja particionado em sistemas lógicos ou roteadores virtuais. Você não pode dizer a um roteador que o servidor do outro lado 10.10.10.1 é acessível pelo túnel e atribuir 10.11.10.1 como endereço DNAT se a estação local 10.10.10.1 deve acessá-lo. Pode haver apenas uma entrada na tabela de roteamento correspondente a 10.10.10.1. Considere também como o tráfego de retorno é tratado, especialmente se você não puder manipular as tabelas de roteamento dos dispositivos na outra extremidade.
Você precisa de um estágio de roteamento duplo:
Origem: 10.10.10.0/24 quer alcançar um servidor do outro lado do túnel com IP 10.10.10.1 (o mesmo que ele próprio), mas deve alcançá-lo via IP falso 10.11.10.1
Roteador NAT 1 faz NAT de origem no IP de origem para, digamos, 10.255.10.1
Roteador NAT 2 faz NAT de destino, traduzindo o IP de destino para 10.10.10.1
O servidor de destino 10.10.10.1 recebe o tráfego com 10.255.10.1 como origem e pode devolver o tráfego
Em um Juniper SRX e muitos outros firewalls, isso pode ser feito usando uma instância de roteamento separada para a segunda etapa de NAT. Se você tiver controle sobre os dois pontos finais do IPsec, pode usá-los para cada função, mas se tiver vários clientes com espaço de endereçamento que potencialmente se sobrepõem, pode querer configurar uma função genérica para isso, de modo que os recursos do cliente respectivo possam ser acessados via endereços como 10.11.a.b, onde a é o número que indica o cliente e b o recurso/servidor que deseja alcançar. Assim, será possível endereçar facilmente 256 recursos em 256 clientes. Expandir além disso é simples.
Esta é a resposta - também sim, o Palo suporta isso. Muito fácil de implementar.
A explicação é perfeita, mas você também pode fazer isso com um SonicWall. A maioria dos firewalls comerciais suporta isso, não precisa ser equipamento de nível empresarial.
Então, seria um NAT 1:1 entre a sub-rede do túnel e a sub-rede de destino?
Isso mesmo, mapeamento 1:1 entre as sub-redes reais e mapeadas.