Estamos enfrentando um problema estranho, aparentemente relacionado ao roteamento ou ao DNS.
Temos uma topologia "hub and spoke" utilizando equipamentos Unifi (UDMP's). Cada site se conecta via túnel IPSEC a uma instância AWS EC2 executando VyOS para lidar com o roteamento principal entre sites e outras infraestruturas na AWS.
No passado, quando tínhamos uma topologia mais híbrida com alguns servidores locais, cada site tinha outro túnel IPSEC conectado ao escritório principal, necessário para o antigo servidor VoIP, e tínhamos alguns servidores DNS locais.
Desde então, transferimos toda a infraestrutura para a AWS e esses segundos túneis IPSEC para o escritório principal não são mais necessários. Desativei a maioria dos túneis do site que conectam ao escritório principal e tudo funciona bem para os outros sites. Ainda tenho um site (site3) que está me causando problemas sempre que desativo o túnel.
O problema: sempre que desativo o túnel IPSEC entre o "site 3" e o escritório principal, as coisas funcionam por cerca de 10 minutos antes que as pessoas comecem a reclamar que "não têm internet". Determinei que eles provavelmente ainda estavam usando os antigos servidores DNS locais, então troquei seus servidores DNS primários para os servidores DNS na AWS, com o Google DNS como backup. Tudo bem, sem problemas, tudo funcionando. Desço pelo túnel novamente e começo a receber ligações. Desta vez, os usuários dizem que perderam suas unidades mapeadas (o servidor de arquivos na AWS).
O que é estranho é que tudo funciona bem (conectividade do site 3 com aws) quando o túnel IPSEC para o escritório principal está ativo. Quando eu o desligo, as coisas funcionam por cerca de 10 minutos e depois param de funcionar. Você poderia pensar que o site deles está roteando através do túnel até o escritório principal e depois até a AWS, mas esse não é o caso. Um traceroute de uma máquina cliente no site3 mostra 3 saltos para conectar-se às instâncias do EC2: para fora de sua WAN, para o IP do VyOS, para o IP do servidor. Uma olhada na tabela de roteamento na máquina cliente no site3 não mostra nenhuma entrada para a rede AWS, portanto, o tráfego é enviado para 0.0.0.0, seu gateway UDMP. Uma olhada na tabela de roteamento no site3 UDMP mostra 1 entrada para a rede aws VPC, 172.30.0.0/16, com o próximo salto sendo o roteador VyOS.
Um detalhe interessante é que, embora tudo esteja configurado para permitir ICMP/resposta ao ping, nem o UDMP nem o roteador vyos podem executar ping entre si ou em instâncias ec2... no entanto, os clientes na rede site3 podem executar ping em tudo.
Verifiquei as regras de segurança para as instâncias EC2 e todas as redes e IPs WAN necessários estão incluídos.
Fiquei sem ideias quando percebi que o site3 udmp está configurado com um IP WAN estático, mas também possui configurações definidas para "roteador" e endereços IP adicionais. Estes são os detalhes:
WAN IP=108.x.69.250
subnet mask: 255.255.255.248
Router: 108.x.69.249
Additional IP addresses: 108.x.69.251/32, 108.x.69.252/32, 108.x.69.253/32, 108.x.69.254/32, 108.x.69.255/32
Uma olhada nas regras de segurança para AWS/EC2 mostrou que, embora 108.x.69.250/32 seja permitido, nenhum dos outros IPs na sub-rede está incluído (roteador ISP de próximo salto ou IPS adicional). Alterei a entrada permitida de segurança da AWS para 108.x.69.248/29, mas isso é uma salva de palmas. Não estou muito confiante de que essa será a solução.
Alguém tem alguma opinião ou ideia? Não posso testar novamente antes do expediente, mas pensei que poderia ouvir a opinião de outra pessoa sobre a situação. Alguém tem experiência em trabalhar com UDMP com WAN estática, mas também com esses campos adicionais configurados para roteador e IPs adicionais?
Incluí um lindo diagrama da topologia para seu prazer de leitura!
Responder1
Acredito que adicionar IPs adicionais na rede WAN/29 ao grupo de acesso AWS foi o que corrigiu isso para mim.