IPv4 работает, IPv6 зависает: проверяем AAAA и отдельный путь до сервиса

Сайт открывается у части сотрудников, а у других периодически ждёт несколько секунд. IPv4-проверка проходит, поэтому команда объявляет сеть исправной. Но у имени опубликована и AAAA-запись. Клиент может начать соединение по IPv6, столкнуться с проблемой и затем перейти к IPv4. Разные клиенты выполняют такой переход по-разному, из-за чего симптом выглядит случайным.

Сравните один запрос в двух семействах

dig api.example A
dig api.example AAAA
curl -4 --connect-timeout 5 --max-time 10 -v https://api.example/health
curl -6 --connect-timeout 5 --max-time 10 -v https://api.example/health

В выводе curl смотрите адрес назначения и этап остановки. Отсутствие подходящего AAAA, невозможность маршрутизации, отказ порта и ошибка сертификата требуют разных исправлений. Сам факт, что вызов с IPv6 завершился неуспешно, ещё не объясняет причину.

Обе команды должны обращаться к одному имени и пути. Запрос к буквальному IPv6 вместо имени меняет проверяемую TLS-идентичность. Тогда вы можете получить ошибку сертификата даже при полностью исправной IPv6-сети и потерять исходную гипотезу. В подробном выводе сохраняйте участок от разрешения имени до первого ответа.

Посмотрите IPv6-маршрут отдельно

ip -6 address show
ip -6 route show
ip -6 route get 2001:db8:20::80

Подставьте AAAA из ответа DNS. Префикс 2001:db8::/32 используется для примеров и не обозначает ваш рабочий узел. Для успешного соединения нужны пригодный исходный адрес, маршрут к назначению и обратный путь. Наличие link-local адреса на интерфейсе само по себе не означает доступ к публичному IPv6-сервису.

Если маршрут найден, а TCP не устанавливается, проверьте IPv6-правила доступа на обеих границах и наличие слушателя на сервере. IPv4-разрешение в межсетевом экране не обязательно распространяется на IPv6. Передайте владельцу сервиса конкретные данные: имя, AAAA, источник, порт и время попытки.

Если TCP установился и ошибка возникла при TLS, сравните конфигурации конечных точек. IPv4 и IPv6 могут вести на разные балансировщики. Старый сертификат на одном из них объясняет различие без неисправности протокола IPv6. Нужна проверка адреса, к которому клиент действительно подключился.

Для чтения результата полезны два контрастных примера. Сообщение Network is unreachable сразу после выбора IPv6-адреса направляет к локальному пути: проверьте, вернул ли route get пригодный маршрут и источник. Сообщение SSL certificate problem после установленного соединения означает, что транспорт уже дошёл до TLS-сервера. Здесь проверяйте сертификат именно IPv6-входа, а не добавляйте маршрут, который уже работает.

Если route get показывает ожидаемый шлюз, а curl останавливается на Trying до истечения connect-timeout, это третье наблюдение. Локальная таблица смогла выбрать путь, но TCP не завершился. Проверяйте прохождение SYN и обратного ответа на согласованной границе. Вывод о неисправности приложения из такого таймаута преждевременен: HTTP-запрос ещё не был передан.

Не превращайте обход в постоянную архитектуру

Принудительный IPv4 полезен для сравнения и временного восстановления отдельной операции. Глобальное отключение IPv6 на клиентских машинах скрывает неверно опубликованный адрес или неготовую серверную цепочку. Если сервис пока не обслуживает IPv6, владелец DNS должен согласовать публикацию AAAA с реальной доступностью.

После исправления проверяйте и внешний запрос, и путь от обычного рабочего места. Проверка из локальной сети сервера может обходить проблемную границу. Завершённый результат — обе семьи дают ожидаемый ответ либо DNS намеренно публикует только поддерживаемую семью. Запишите решение, чтобы следующая автоматизация не вернула прежнюю AAAA.

Продолжите разбор на собственном Linux-стенде. В программе курса Linux и Bash для DevOps-инженеров предусмотрена диагностика сети, DNS, портов и HTTP. Это подходящее продолжение для инженера, которому нужно объяснять различия между успешной ручной проверкой и поведением реального клиента.

Ещё по теме

• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения
• Сервис выходит в сеть с неожиданного адреса: читаем ip route get