С тех пор как встал вопрос о переходе на IPv6, в индустрии то и дело слышатся жалобы: «IPv6 — это слишком трудно!» Однако при ближайшем рассмотрении выясняется, что корень проблемы не в самой технологии, а в том, как мы её внедряем и обслуживаем.
Недавно на одном немецком Mastodon-аккаунте появилась ситуация, где у домена есть запись AAAA (IPv6), но реальная связь по IPv6 не работает. При этом пользователи не замечали проблем, потому что браузеры используют алгоритм Happy Eyeballs (HE), позволяющий «параллельно» проверять IPv4 и IPv6 и выбирать тот протокол, который отвечает быстрее (или отвечает вообще).
Рассмотрим, что из всего этого следует и какие «подводные камни» могут ждать нас при переходе на IPv6.
Откуда берётся репутация «трудности» IPv6?
🔧 Старые привычки
Многие системы и практики были настроены годами под IPv4. При попытке «быстро прикрутить» IPv6 возникает хаос: нет нужных правил на файерволе, нет мониторинга для IPv6, а иногда — неверная маршрутизация.
🛠️ Неучтённые маршруты
Пример, описанный в оригинальной заметке: у компании был VPN-туннель, в котором IPv4 трафик шёл по VPN и проходил сквозь «белый список» сервера, а IPv6 шёл напрямую «мимо» VPN, и, соответственно, не получал доступа. Механизм Happy Eyeballs маскировал проблему: подключение выглядело то успешным, то неудачным.
⚙️ Отсутствие внешнего мониторинга
Порой у организаций не настроен мониторинг IPv6-сервисов. Если бы браузеры не «обходили» проблему через IPv4, то колл-центры поддержки ломились бы от звонков, а так всё выглядит «как будто всё хорошо».
Happy Eyeballs: спасение или скрытая ловушка?
«Счастливые глазные яблоки» — звучит странно, но так называется алгоритм, благодаря которому большинство современных браузеров не «показывают» пользователю проблемы с IPv6.
👀 Как это работает?
Браузер параллельно делает запрос по IPv4 и IPv6. Если IPv6 тупит или вообще не отвечает, браузер просто переходит на IPv4. Пользователь видит загрузку страницы и не понимает, что сайт фактически «отказался» от IPv6.
👀 Скрытый побочный эффект
Если какая-то организация «притворяется», что поддерживает IPv6 (ведь прописана AAAA-запись), но на самом деле соединение не работает — всё равно пользователи не жалуются. А значит, внутри компании никто не бьёт тревогу, и проблемы нарастут как снежный ком, пока не придёт время кризиса (например, когда IPv4 всё же кончится или будут изменения в конфигурациях).
Практика: проверка соединений и поиск причин
Чтобы понять, что идёт не так, можно выполнить:
✅ curl -4 https://example.com — запрос по IPv4
✅ curl -6 https://example.com — запрос по IPv6
Если по IPv6 вы видите что-то вроде «Couldn’t connect to server», значит, IPv6 не работает, несмотря на записи AAAA.
Также важны инструменты диагностики маршрутизации:
🔎 TCP-трассировка (traceroute -T) или tcp traceroute часто помогают там, где обычный ICMP (tracert в Windows) или UDP (по умолчанию в traceroute Linux) блокируется.
В примере из статьи IPv6-трафик обрывался «на один хоп раньше», что может означать неверную маршрутизацию или блокировку трафика на файерволе.
Почему важно не быть «наполовину» с IPv6
Если компания или проект решает «давайте мы включим IPv6, чтобы казаться современными», но не проверяет и не поддерживает его, то:
🚩 Люди делают вывод, что «IPv6 страшен и сложен»
Хотя на деле проблема часто в банальном недонастроенном файерволе или отсутствии автоматизации.
🚩 Нет нормального мониторинга
Что по IPv4 работает, то кажется «OK». А что по IPv6 упало — остаётся незамеченным.
🚩 У разработчиков/DevOps нет чёткого понимания
Они считают, что раз браузер «не жалуется», значит всё хорошо. А на самом деле пользователи просто тихо откатываются на IPv4.
Технический взгляд автора
Лично я вижу, что внедрение IPv6 часто требует:
🤖 Автоматизации — писать скрипты, которые будут проверять оба протокола, и ранжировать сервисы по доступности.
🔒 Корректных правил файервола — не забывайте, что после включения IPv6 у вас фактически «две сетевые плоскости», и правила нужны для обеих.
✅ Постоянного мониторинга — любые сервисы, имеющие AAAA-записи, должны контролироваться так же, как и IPv4. Иначе рискуете упустить серьёзный сбой.
Если всё это сделать, то «IPv6 — это не боль, а приятное расширение возможностей интернета».
Ссылки на первоисточники и дополнительную информацию
- Автор также упоминает ссылку на GitHub, который не поддерживает IPv6 (по состоянию на момент написания, в статье отмечено, что у GitHub нет записи AAAA).
Таким образом, ключевой посыл: либо делать IPv6 «по-честному» (включая настройку, мониторинг, корректную маршрутизацию), либо не делать вовсе. Иначе вместо продвижения новой технологии вы закрепляете за ней репутацию «сложной и ненадёжной». А ведь IPv6 — это не «страшное зло», а наоборот, жизненно необходимый шаг вперёд в условиях исчерпания IPv4-адресов.