Вопрос или проблема
Я сталкиваюсь с трудной ситуацией с интернет-ориентированным балансировщиком нагрузки (ALB). При подключении через AWS VPN Client Endpoint команда nslookup показывает публичный IP-адрес ALB. Однако получить доступ к экземпляру EC2 за ALB с использованием этого публичного IP-адреса невозможно, доступен только частный IP-адрес ALB.
Группа безопасности ALB настроена с входящими правилами, которые специально разрешают HTTP и HTTPS трафик от группы безопасности, связанной с нашей VPN конечной точкой.
Одна из теорий заключается в том, что трафик, направляемый на публичный IP, в конечном итоге проходит через NAT-шлюз, поскольку таблица маршрутизации указывает публичные IP на NAT Gateway. Могло ли это привести к тому, что не сохраняется ассоциация группы безопасности конечной точки VPN? Я добавил входящее правило в SG, разрешающее весь трафик только для тестирования (после этого удалил), и тогда действительно работал. Какое может быть лучшее решение для доступа к ALB с VPN конечной точки, используя его публичный IP?
Был бы признателен за любые идеи или советы по решению этой проблемы с подключением VPN к публичному ALB. Спасибо!
ПРИМЕЧАНИЕ: В конце концов, я настроил второй ALB, на этот раз внутренний, и создал частную хостинговую зону для разрешения. Тем не менее, я хочу узнать, почему интернет-ориентированный ALB не может быть доступен, когда используется публичный IP из VPC, даже при настройке NAT Gateway.
Ответ или решение
Для того чтобы решить проблему доступа к интернет-формирующему Application Load Balancer (ALB) изнутри VPC, необходимо рассмотреть несколько факторов, которые могут повлиять на поведение сети.
-
Особенности работы ALB и маршрутизация трафика: Интересный момент заключается в том, что при использовании публичного IP, запросы могут быть направлены в интернет, а затем обратно в ваш VPC. Это может привести к несанкционированной маршрутизации через NAT Gateway, что может вызывать проблемы с безопасностью и доступом.
-
Безопасные группы и маршруты: Вы правильно заметили, что необходимо убедиться, что правила в группах безопасности (SG) не блокируют трафик. Получение доступа к ALB по публичному IP может не сработать, если ваши существующие правила безопасности не позволяют трафику быть направленным на него. Убедитесь, что:
- Ваша SG для ALB разрешает входящие HTTP и HTTPS запросы с IP-адресов, идущих через ваш VPN.
- Необходимые исходящие правила настроены правильно, чтобы ALB мог возвращать ответ клиенту.
-
Влияние NAT Gateway: Если у вас настроен NAT Gateway для маршрутизации выходного трафика в интернет, дополнительно убедитесь, что он правильно сконфигурирован. При внутреннем обращении к публичному IP ALB ваш трафик может быть направлен через NAT Gateway, что останавливает его от корректного возвращения в ваш VPC.
-
Тестирование на уровне SG: Как вы уже сделали, протестируйте AlB с разрешением всех типов трафика на SG, это поможет вам понять, является ли это проблемой с настройками безопасности. Просто помните быть осторожными с открытием безопасности.
-
Использование Route 53 Private Hosted Zone: Как вы уже сделали, создание внутреннего ALB и связи с Private Hosted Zone — это вполне нормальное решение для доступа к сервисам внутри VPC без прохождения через интернет.
- Рекомендации: Если вам нужно сохранить внешний доступ к ALB из VPC, вы можете сделать следующее:
- Настройте ALB для поддержки маршрута для исходящего трафика, чтобы он возвращал трафик к источнику через NAT, если это вам необходимо.
- Но, если вы хотите избежать сложностей с маршрутизацией, а также со стремлением ограничить трафик, лучше использовать внутренние ресурсы (интранет), что вы уже протестировали, создав внутренняя ALB.
Следуя этим рекомендациям, вы сможете улучшить конфигурацию вашей сети и устранить милие проблемы доступа к интернет-формирующему ALB из VPC.