Estamos experimentando un problema extraño, aparentemente relacionado con el enrutamiento o el DNS.
Contamos con una topología de "eje y radio" utilizando equipos Unifi (UDMP). Cada sitio se conecta a través de un túnel IPSEC a una instancia AWS EC2 que ejecuta VyOS para manejar el enrutamiento principal entre sitios y otra infraestructura en AWS.
En el pasado, cuando teníamos una topología más híbrida con algunos servidores locales, cada sitio tenía otro túnel IPSEC conectado a la oficina principal, necesario para el antiguo servidor VoIP, y teníamos algunos servidores DNS locales.
Desde entonces, trasladamos toda la infraestructura a AWS y estos segundos túneles IPSEC a la oficina principal ya no son necesarios. He derribado la mayoría de los túneles del sitio que conectan con la oficina principal y todo funciona bien para esos otros sitios. Me queda un sitio (sitio3) que me da problemas cada vez que bajo su túnel.
El problema: cada vez que desmonto el túnel IPSEC entre el "sitio 3" y la oficina principal, las cosas funcionan durante unos 10 minutos antes de que la gente empiece a quejarse de que "no tienen Internet". Determiné que probablemente todavía estaban usando los antiguos servidores DNS locales, así que cambié sus servidores DNS principales a los servidores DNS en AWS, con Google DNS como respaldo. Bien, no hay problema, todo funciona. Vuelvo a bajar por el túnel y empiezo a recibir llamadas. Esta vez los usuarios dicen que perdieron sus unidades asignadas (el servidor de archivos en AWS).
Lo extraño es que todo funciona bien (la conectividad del sitio 3 a AWS) cuando su túnel IPSEC a la oficina principal está activo. Cuando lo quito, todo funciona durante unos 10 minutos aproximadamente y luego deja de funcionar. Se podría pensar que su sitio atraviesa el túnel hasta la oficina principal y luego hasta AWS, pero este no es el caso. Un traceroute desde una máquina cliente en el sitio 3 muestra 3 saltos para conectarse a instancias EC2: fuera de su WAN, a la IP de VyOS y a la IP del servidor. Una mirada a la tabla de enrutamiento en la máquina cliente en el sitio 3 muestra que no hay entradas para la red de AWS, por lo que el tráfico se envía a 0.0.0.0, su puerta de enlace UDMP. Una mirada a la tabla de enrutamiento en el sitio 3 UDMP muestra 1 entrada para la red AWS VPC, 172.30.0.0/16, siendo el siguiente salto el enrutador VyOS.
Un detalle interesante es que aunque todo está configurado para permitir ICMP/responder al ping, ni el UDMP ni el enrutador vyos pueden hacer ping entre sí o a las instancias ec2... sin embargo, los clientes en la red del sitio3 pueden hacer ping a todo.
Verifiqué las reglas de seguridad para las instancias EC2 y se incluyen todas las redes e IP WAN requeridas.
Me quedé sin ideas cuando noté que site3 udmp está configurado con una IP WAN estática, pero también tiene ajustes de configuración establecidos para "enrutador" y direcciones IP adicionales. Estos son los detalles:
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
Una mirada a las reglas de seguridad para AWS/EC2 mostró que, si bien 108.x.69.250/32 está permitido, ninguna de las otras IP en la subred está incluida (enrutador ISP del siguiente salto o IPS adicional). Cambié la entrada permitida de seguridad de AWS a 108.x.69.248/29, sin embargo, esto es un granizo. No estoy muy seguro de que esta sea la solución.
¿Alguien tiene alguna idea o pensamiento? No puedo volver a realizar la prueba hasta después de horas, pero pensé que podría conocer la opinión de otra persona sobre la situación. ¿Alguien tiene experiencia trabajando con UDMP con WAN estática pero también con estos campos adicionales configurados para enrutador e IP adicionales?
¡He incluido un hermoso diagrama de la topología para que disfrutes leyendo!
Respuesta1
Creo que agregar las IP adicionales en la red WAN/29 al grupo de acceso de AWS es lo que solucionó este problema.