AWS поддерживает подключение к внешним службам IPv4-only с узла IPv6-only с использованием NAT64. Есть ли эквивалент для обратного?
Для контекста, у меня есть кластер EKS, который в настоящее время использует только IPv4, все в частных подсетях. Связь с любым внешним IP осуществляется через шлюз NAT (обычно для веб-перехватчиков или подобных исходящих запросов). Теперь некоторые внешние службы переключаются на использование только IPv6. Есть ли способ подключиться к ним без миграции всего кластера на IPv6? Поскольку EKS не поддерживает сети с двойным стеком, миграция может оказаться довольно большим и рискованным проектом.
решение1
Нет, IPv4 источник IPv6 назначение не так просто. По сравнению с тем, чтобы пойти в другую сторону или родным IPv6.
DNS64 + NAT64, механизм перехода, используемый в сетях только IPv6 для подключения к v4, прост. Крошечный префикс v6 может содержать все адресное пространство v4. Fancy DNS генерирует записи AAAA в этом префиксе, когда в результате есть только запись A. А двойной стек NAT имеет простое преобразование 1 в 1 без сохранения состояния, которое выполняется быстро и не требует настройки.
Сравните с тем, чтобы пойти другим путем. Допустим, адрес удаленной службы — 2001:db8:114:6614:240e:6d9d:8a1d:59d3 Все 32-битное адресное пространство IPv4 может содержать только последние две группы цифр, часть 8a1d:59d3. Так что замысловатые трюки DNS и немодифицированные приложения не сработают. Теоретически, прокси-сервер с двойным стеком может завершить соединения v4 и сделать соединения v6 выходящими. Но как вы собираетесь передавать адреса v6, анализировать трафик приложений на предмет имен в DNS или TLS? И как поддерживать потоки, NAT с отслеживанием состояния?
Однако у Kubernetes есть свои собственные идеи о сетях, и EKS не является исключением. Хотя это не просто подключение NAT64,EKS имеет двухъярусную конструкцию.v6 назначается модулям, а также только хост-версия v4, которая несколько раз преобразуется в NAT в случае v4 в Интернет.
Обратите внимание, насколько прост v6 в приложении к v6 в Интернете, из выходного интернет-шлюза без NAT. Получение этого соединения с внешними ресурсами v6 является причиной для вашей организации сделать это. В дополнение к устранению проблем с размером подсетей для количества pod.
Внедрение этого в современный интернет — это проект, да. Самое первое, что есть вконтрольный список для IPv6 на EKSкластер должен быть создан с помощью v6.
Вы можете выполнить этот проект. Создайте второй кластер с этим новым дизайном. Запустите на нем новые приложения и перенесите другие, когда появится возможность обслуживания. Имейте план отката, если возникнет проблема, чтобы вернуться к тому, как было раньше. В самом худшем случае старый кластер можно будет перестроить, как он был. Это инфраструктура как код, в конце концов.
решение2
Эта опция довольно спрятана в документации, но можно сделать выход IPv6 из кластера IPv4 EKS. Это можно сделать с помощьюВКЛЮЧИТЬ_V6_EGRESSопция в дополнении vpc-cni.
Это настраивает каждый pod с адресом узла-частного в диапазоне "fd00::ac:00/118". Для внешних конечных точек pod затем выполняет NAT через узел.
Технически это не «IPv4 в IPv6 NAT», но это позволяет достичь цели выхода IPv6 на кластере IPv4 EKS.
Необходимые шаги:
- Назначьте блоки IPv6 на VPC и подсетях и включите "Автоматическое назначение адреса IPv6" на подсетях. Добавьте выходной интернет-шлюз и соответствующим образом настройте таблицы маршрутизации.
- Выполните ротацию всех узлов, чтобы каждому из них был назначен адрес IPv6.
- Убедитесь, что версия дополнения vpc-cni — 1.13+.
- Обновите дополнение vpc-cni, используя следующую конфигурацию:
{"env":{"ENABLE_V6_EGRESS":"true"},"init":{"env":{"ENABLE_V6_EGRESS":"true"}}}. Делайте это только после ротации всех узлов, в противном случае развертывание завершится неудачей.