Temos conexões VPN site a site usando o Gateway VPN do Azure e vários dispositivos de rede locais nos respectivos locais dos clientes. Estamos tentando integrar uma nova conexão, mas temos um conflito de intervalo de IP com uma rede do outro lado. O diagrama abaixo, embora seja uma interpretação vaga do lado do cliente, já que não tenho todos os detalhes do lado deles, provavelmente explica melhor, mas aqui estão os fatos:
Conflito de intervalo de IP em qualquer extremidade do túnel Azure VPN S2S
- A Rede A (192.168.1.0/24) fica atrás do nosso Gateway VPN do Azure e é de nossa responsabilidade.
- A Rede B (192.168.2.0/24) é uma rede alvo para pacotes originados da Rede A, é de responsabilidade do nosso cliente e está hospedada em uma nuvem privada.
- A rede C (192.168.1.0/24) é outra rede dentro da nuvem privada que não é relevante para o nosso tráfego, exceto que representa um conflito de intervalo de IP dentro da nuvem privada do cliente.
O suporte do Azure indicou que a única solução é re-IPar uma das redes conflitantes, pois os intervalos conflitantes não são suportados neste momento. Segundo eles, o NAT não é uma solução viável em nenhuma das pontas do túnel. A adição de uma nova sub-rede por trás do Gateway VPN do Azure e o encaminhamento/NAT do tráfego para a Rede A também não são suportados.
Por causa das consequências do re-IP da Rede A, não queremos re-IPá-la. Não é novidade que o cliente também não deseja re-IPar sua rede, a Rede C. Talvez eu esteja apenas em negação, mas alguém já se deparou com esse cenário e conseguiu contorná-lo ou resolvê-lo?semre-IP'ing? Nesse caso, qualquer documentação ou configuração que suporte a solução que possa ser referenciada seria muito apreciada.
Agradecemos antecipadamente por qualquer ajuda.
Responder1
- roteamento específico
Você escreveu que está interessado em roteamento entre as redes A e B, o que não é conflitante... Caso a SonicWall esteja roteando entre essas "redes internas de clientes" e seja possível não usar IPs específicos na rede C, você pode fazer o roteamento através a rede não para 192.168.1.0/24 inteiro, mas para IPs específicos como /32. Na decisão de roteamento, "a melhor partida vence". Nesse caso, o tráfego específico seria roteado de B para A corretamente, enquanto o restante seria passado para a rede C...
Dependendo do tipo de VPN, pode ser mais fácil ou mais difícil (se possível) configurar no SonicWall, mas tecnicamente esse poderia ser o caminho sem NAT. Na pior das hipóteses, você pode fazer com que um dispositivo adicional termine a VPN para o Azure e no SonicWall tenha uma regra de rota estática para direcionar esses IPs para esse nó adicional.
Dessa forma, o lado do Azure nunca será acessível a partir de C, mas não seria o problema com base no que você escreveu.
- NAT
Como você escreveu, o Azure VPN GW não oferece esse recurso, a única opção seria fazer isso do outro lado do túnel - SonicWall Appliance. Do lado B, C, você pode endereçar sites "remotos" como qualquer faixa de IP não usada (por exemplo, 172.16.0.0/24) e, uma vez que chegue ao SonicWall, poderá ser roteado para VPN, enquanto antes de sair do nó, será dNATado/mapeado para 192.168.1.0/24 enquanto, por exemplo, mantém o valor do último octeto ou faz um mapa 1:1 listando todos os IPs necessários). Dessa forma, para o tráfego VPN, o IP remoto no lado do Azure seria 192.168.0.0/24 "adequado" e o lado do Azure não teria ideia sobre o NAT.
Caso você não possa fazer isso no SonicWall por algum motivo, pode-se colocar outro dispositivo capaz de fazê-lo / sob gerenciamento próprio que encerraria o túnel VPN e da rede local seria o destino para o tráfego 172.16.0.0/24 (rota no roteador local).
As únicas coisas problemáticas seriam os casos em que você usa resposta DNS com endereços 192.168.1.0/24 e certificados usando IP para identificação. No caso de coisas de DNS, você precisa de uma zona DNS local com valores "atualizados" para que os clientes entrem em contato com endpoints "corretos".