У нас возникла странная проблема, по-видимому, связанная с маршрутизацией или DNS.
У нас есть топология «hub and spin» с использованием оборудования Unifi (UDMP). Каждый сайт подключается через туннель IPSEC к экземпляру AWS EC2, работающему под управлением VyOS, для обработки базовой маршрутизации между сайтами и другой инфраструктурой в AWS.
Раньше, когда у нас была более гибридная топология с несколькими локальными серверами, на каждом сайте был свой туннель IPSEC, соединяющийся с главным офисом, необходимый для старого сервера VoIP, и у нас было несколько локальных DNS-серверов.
С тех пор мы перенесли всю инфраструктуру в AWS, и эти вторые туннели IPSEC в главный офис больше не нужны. Я отключил большую часть туннелей сайта, соединяющих его с главным офисом, и все работает нормально для этих других сайтов. У меня остался один сайт (site3), который создает мне проблемы всякий раз, когда я отключаю их туннель.
Проблема: Всякий раз, когда я отключаю туннель IPSEC между «сайтом 3» и главным офисом, все работает, может быть, минут 10, прежде чем люди начинают жаловаться, что у них «нет интернета». Я определил, что они, вероятно, все еще используют старые локальные DNS-серверы, поэтому я переключил их основные DNS-серверы на DNS-серверы в AWS, используя Google DNS в качестве резервного. Отлично, никаких проблем, все работает. Я снова отключаю туннель, и мне начинают звонить. На этот раз пользователи говорят, что потеряли свои сопоставленные диски (файловый сервер в AWS).
Странно то, что все работает нормально (подключение сайта 3 к aws), когда их туннель IPSEC к главному офису работает. Когда я его отключаю, все работает, может быть, минут 10, а затем перестает работать. Можно подумать, что их сайт маршрутизирует через туннель в главный офис, а затем вверх к AWS, но это не так. Трассировка маршрута с клиентской машины на сайте 3 показывает 3 перехода для подключения к экземплярам EC2: из их WAN, к IP-адресу VyOS, к IP-адресу сервера. Просмотр таблицы маршрутизации на клиентской машине на сайте 3 не показывает записи для сети AWS, поэтому трафик отправляется на 0.0.0.0, их шлюз UDMP. Просмотр таблицы маршрутизации на сайте 3 UDMP показывает 1 запись для сети aws VPC, 172.30.0.0/16, со следующим переходом на маршрутизатор VyOS.
Интересная деталь: хотя все настроено на разрешение ICMP/ответа на пинг, ни маршрутизатор UDMP, ни маршрутизатор vyos не могут пинговать друг друга или экземпляры ec2... однако клиенты в сети site3 могут пинговать все.
Я проверил правила безопасности для экземпляров EC2, и все необходимые сети и IP-адреса WAN включены.
У меня не было идей, когда я заметил, что site3 udmp настроен на статический WAN IP, но также имеет настройки конфигурации, установленные для "маршрутизатора", и дополнительные IP-адреса. Вот подробности:
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
Просмотр правил безопасности для AWS/EC2 показал, что хотя 108.x.69.250/32 разрешен, ни один из других IP-адресов в подсети не включен (маршрутизатор следующего перехода ISP или дополнительный IPS). Я изменил разрешенную запись безопасности AWS на 108.x.69.248/29, однако это беда. Я не слишком уверен, что это будет исправлением.
У кого-нибудь есть мысли или идеи? Я не смогу снова протестировать до окончания рабочего дня, но я подумал, что, возможно, услышу чье-то мнение о ситуации. У кого-нибудь есть опыт работы с UDMP со статическим WAN, но также с этими дополнительными полями, настроенными для маршрутизатора и дополнительных IP-адресов?
Я включил прекрасную схему топологии для вашего удовольствия!
решение1
Я считаю, что добавление дополнительных IP-адресов в сети WAN /29 в группу доступа AWS решило эту проблему.