Ошибка подключения к сервисам аутентификации: проверка сети, DNS и TLS

Если сервис аутентификации недоступен на этапе соединения, проверяйте цепочку в фиксированном порядке: DNS-резолвинг hostname, маршрут до IP-адреса, TCP-порт, TLS-рукопожатие и HTTP-ответ IdP. Такая последовательность помогает быстро определить границу сбоя и не тратить время на проверку токенов или MFA, пока клиент не установил защищенное соединение.

Сначала зафиксируйте точное время ошибки, имя endpoint, клиентскую машину или pod, используемый proxy или VPN и текст сообщения. Прокси и VPN могут скрывать IP-адрес, но DNS-запросы иногда продолжают уходить напрямую через провайдера. Такое расхождение называют DNS leak. Проверка DNS, WebRTC и IPv6 через DNS Leak Test помогает понять, проходит ли подключение по ожидаемому маршруту.

Если hostname не разрешается, ищите причину в DNS. Если имя разрешается, но TCP-соединение не устанавливается, проверяйте маршрутизацию, firewall, ACL и security group. Если TCP работает, а TLS handshake завершается ошибкой, проверяйте сертификат, SNI, цепочку доверия, CA bundle и системное время. HTTP-коды 401 и 403 появляются после успешного TLS и относятся к авторизации, политике доступа или настройкам приложения.

Что проверить в первые 10 минут при ошибке подключения

Короткий алгоритм локализации сбоя

Пройдите пять уровней и переходите дальше только после подтверждения предыдущего:

Hostname. Выполните DNS-запрос к имени сервиса. Ответ с ожидаемым IP переводит проверку к маршрутизации. NXDOMAIN, SERVFAIL, timeout или неожиданный адрес требуют отдельного разбора DNS.
Маршрут. Проверьте, куда система отправляет трафик к полученному IP. Для приватного IdP пакет должен идти через корпоративный интерфейс или VPN, если так задана архитектура.
TCP-порт. Проверьте порт 443 или другой порт из конфигурации. Успешное TCP-соединение означает, что базовый сетевой путь работает.
TLS. Убедитесь, что клиент принимает сертификат, имя хоста совпадает с SAN, сервер получает правильный SNI, а цепочка доверия строится до установленного CA.
HTTP и IdP. Полученный HTTP-ответ подтверждает, что запрос достиг сервиса. После этого проверяйте issuer, redirect URI, токены, MFA, учетную запись и права приложения.

Результат проверки	Следующий уровень
Имя не разрешается	Локальный resolver, корпоративный DNS, VPN-DNS, split DNS и кэш
Имя разрешается, TCP timeout	Маршрут, firewall, ACL, NAT, security group и proxy
Connection refused	Сервис, балансировщик, порт или правило доступа на удаленной стороне
TCP работает, TLS handshake не завершен	Сертификат, SNI, CA bundle, время и TLS-параметры
HTTP 401 или 403	Учетные данные, токен, MFA, политика доступа и конфигурация приложения

Какие данные собрать до изменения конфигурации

Не меняйте DNS, proxy или firewall сразу после появления общей ошибки. Сначала сохраните исходные признаки сбоя. Они нужны для сравнения после исправления и для передачи задачи сетевой команде или владельцу IdP.

Время ошибки в UTC и локальном часовом поясе, частоту повторения и первый момент появления.
Hostname IdP, порт, issuer и имя приложения, которое отправляет запрос.
Источник запроса: рабочая станция, сервер, контейнер, Kubernetes-под, браузер, CLI или фоновый процесс.
Состояние proxy и VPN, включая активный интерфейс, split-tunnel или full-tunnel режим.
Результаты dig, nslookup, curl -v, nc или Test-NetConnection.
Фрагменты журналов приложения, reverse proxy, балансировщика и firewall с одинаковыми временными метками.

date -u
dig idp-host A
dig idp-host AAAA
nc -vz idp-host 443
curl -v --connect-timeout 5 https://idp-host/
openssl s_client -connect idp-host:443 -servername idp-host

Опция -k у curl допускается только как временная проверка сетевого пути, если нужно отделить TCP от проверки сертификата. Оставлять отключенную проверку TLS в рабочей конфигурации нельзя.

Проверка сети, прокси и VPN перед диагностикой DNS

Диагностику запускайте из того же окружения, где возникает ошибка. Рабочая станция, сервер, Docker-контейнер и Kubernetes-под могут использовать разные DNS-серверы, proxy-переменные, таблицы маршрутизации и правила egress.

Проверка активного сетевого маршрута

На Linux проверьте интерфейсы, шлюз по умолчанию и маршрут к hostname:

ip addr
ip route
ip route get idp-host
resolvectl status

В Windows используйте команды:

Get-NetIPConfiguration
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-DnsClientServerAddress

В выводе ищите активный default route и интерфейс, через который должен проходить трафик. При full-tunnel весь внешний трафик обычно уходит через VPN-шлюз. При split-tunnel через VPN направляются только выбранные сети или домены. Если IdP находится в приватной сети, отсутствие маршрута к этой сети объясняет timeout даже при корректном DNS-ответе.

Сравните результат через корпоративную сеть, мобильную сеть и VPN, если такие проверки разрешены политикой безопасности. Различие между каналами быстро показывает, находится ли проблема на клиенте, в конкретном сегменте или на общей границе сети. Для отдельного разбора туннелей пригодится пошаговая диагностика VPN.

Проверка настроек прокси

Проверьте proxy на трех уровнях: переменные окружения, настройки самого приложения или SDK и конфигурация reverse proxy. Браузер может работать через корпоративный proxy, а CLI-программа при этом отправляет запрос напрямую. Обратная ситуация тоже встречается.

env | grep -i proxy
printenv NO_PROXY
Get-ChildItem Env:*proxy*

Проверьте регистр имен переменных: многие программы читают и HTTP_PROXY, и http_proxy, но поведение зависит от языка, библиотеки и версии SDK.

HTTP_PROXY и HTTPS_PROXY могут указывать на недоступный или перегруженный proxy.
В NO_PROXY может отсутствовать внутренний домен IdP, из-за чего запрос ошибочно уходит во внешний proxy.
В NO_PROXY может быть указан домен, но не IP-адрес, к которому приложение подключается после резолвинга.
Proxy может разрешать браузерный трафик, но блокировать CLI, сервисный аккаунт или исходящий запрос из pod.
HTTPS-запрос через HTTP proxy обычно использует CONNECT. Ошибка на этом этапе видна в подробном выводе curl и журнале proxy.

Не добавляйте домен в NO_PROXY автоматически. Для внешнего IdP корпоративная политика может требовать обязательный proxy, журналирование и TLS-инспекцию. Сначала определите ожидаемый маршрут, затем сравните его с фактическим.

Проверка DNS-утечки через VPN или прокси

DNS leak возникает, когда DNS-запросы идут в обход VPN или proxy через DNS-сервер интернет-провайдера. В результате сервис может видеть реальный DNS и примерное местоположение пользователя, даже если внешний IP скрыт. Некоторые VPN и proxy меняют только маршрут IP-трафика и не перехватывают DNS.

Для проверки сравните DNS-серверы при отключенном и включенном VPN, а затем проверьте DNS Leak Test. Инструмент показывает DNS-серверы, WebRTC и IPv6, поэтому помогает обнаружить расхождение между заявленным и фактическим маршрутом.

Если DNS при активном VPN остается сервером провайдера, проверьте настройки DNS внутри VPN-клиента и режим split-tunnel.
Если браузер раскрывает адрес через WebRTC, проверьте политики браузера и корпоративные расширения.
Если активен IPv6, а VPN защищает только IPv4, запросы могут идти по отдельному маршруту.
Если IPv6 в среде не используется, временно исключите его из теста и отдельно исправьте сетевую конфигурацию.

DNS-утечка не объясняет каждую ошибку подключения. Это одна из проверок сетевого пути, особенно при работе через VPN, proxy и публичные сети.

Ошибка DNS при подключении к сервису аутентификации

Проверка резолвинга hostname

Проверьте имя IdP через resolver, который использует проблемное окружение. Не ограничивайтесь запросом с личного компьютера: сервер или pod может получать другой ответ.

dig idp-host A +noall +answer
dig idp-host AAAA +noall +answer
nslookup idp-host
Resolve-DnsName idp-host

Разделяйте результаты по типу:

NXDOMAIN означает, что resolver не знает такого имени. Проверьте домен, search domain и наличие записи.
SERVFAIL указывает на ошибку обработки запроса или делегирования. Ищите проблему на DNS-сервере, в DNSSEC или в цепочке резолвинга.
Timeout означает, что ответ не пришел вовремя. Проверьте доступность DNS-сервера, firewall и маршрут через VPN.
Неожиданный IP часто связан с split DNS, устаревшей записью, ошибкой балансировщика или подключением к публичной зоне вместо внутренней.

Если политика разрешает такое сравнение, выполните запрос через корпоративный resolver и через публичный DNS. Расхождение ответов не означает, что публичный ответ правильный. Для внутреннего IdP приватный адрес может быть ожидаемым результатом.

Сравнение DNS-ответов из разных окружений

Сравните файл /etc/resolv.conf, состояние systemd-resolved, search domain, DNS policy Kubernetes и настройки Docker. В pod проверьте тот же hostname и тот же тип записи, что использует приложение.

cat /etc/resolv.conf
resolvectl status
docker exec container-name getent hosts idp-host
kubectl exec pod-name -- cat /etc/resolv.conf
kubectl exec pod-name -- getent hosts idp-host

Для Kubernetes проверьте DNS policy, namespace, NetworkPolicy и доступ pod к сервису DNS. Для Docker сопоставьте настройки сети контейнера с сетью хоста. Практические команды для такой проверки собраны в руководстве по сетевой диагностике Docker и Kubernetes.

Частые расхождения выглядят так:

Рабочая станция получает внутренний IP, а pod получает публичный адрес.
Сервер использует корпоративный resolver, а контейнер унаследовал недоступный DNS-шлюз.
Клиент резолвит короткое имя через search domain, а приложение использует полное имя без нужной DNS-зоны.
После миграции осталась старая запись с коротким TTL, и часть клиентов еще обращается к прежнему адресу.

Проверка записей A, AAAA и IPv6-маршрута

Записи A и AAAA проверяйте раздельно. Клиент может выбрать IPv6 первым, получить корректный AAAA-ответ и зависнуть на маршруте, который в среде не настроен.

dig idp-host A +short
dig idp-host AAAA +short
curl -4 -v --connect-timeout 5 https://idp-host/
curl -6 -v --connect-timeout 5 https://idp-host/

Если IPv4 работает, а IPv6 завершается timeout, проверьте IPv6-шлюз, firewall, VPN и правила egress. Временно исключить IPv6 из теста допустимо для локализации причины. Такое действие не заменяет настройку полноценной поддержки IPv6, если протокол нужен рабочей среде.

При подключении по IPv6 отдельно проверьте, что сертификат выпущен для hostname, а не для конкретного адреса. TLS-клиент должен использовать имя сервиса и передавать его через SNI.

Очистка DNS-кэша и проверка TTL

Проверьте TTL ответа и время последнего изменения записи:

dig idp-host A +noall +answer
dig idp-host AAAA +noall +answer

Кэш может находиться на рабочей станции, в systemd-resolved, локальном DNS-сервисе, Docker DNS или CoreDNS Kubernetes. В Windows очистите локальный кэш командой:

ipconfig /flushdns

После очистки повторите запрос именно из проблемного окружения и сравните IP, TTL и время ответа. Если результат снова неверный, причина находится в DNS-конфигурации или upstream-resolver, а не в локальном кэше.

Маршрутизация, порты и firewall после успешного DNS-ответа

Успешный DNS-ответ подтверждает только получение IP-адреса. Он не говорит, что пакет достиг сервиса и что порт принимает соединения.

Проверка TCP-порта сервиса

Для Linux используйте nc или подробный curl:

nc -vz idp-host 443
curl -v --connect-timeout 5 https://idp-host/

В Windows подойдет PowerShell:

Test-NetConnection idp-host -Port 443

Симптом	Вероятная область поиска
Timeout	Маршрут, firewall, ACL, security group, NAT или недоступный proxy
Connection refused	IP достижим, но порт закрыт, сервис не слушает порт или балансировщик отклоняет соединение
Успешное TCP-соединение	Переход к TLS и проверке сертификата
Reset после начала TLS	Proxy, TLS-инспекция, балансировщик или серверная политика шифрования

Не подменяйте проверку порта командой ping. ICMP может быть запрещен, тогда как TCP 443 работает. Для IdP проверяйте именно порт, который указан в конфигурации клиента.

Проверка firewall и сетевых ACL

Проверьте исходящие правила на клиенте или хосте, сетевые ACL, NAT, облачную security group, firewall балансировщика и ограничения по IP-адресам. Если IdP использует несколько адресов, один адрес может быть разрешен, а другой заблокирован после обновления DNS.

На границе сети сопоставьте время попытки с журналом firewall. Для короткой локальной проверки трафика с нужными правами можно использовать:

tcpdump -ni any host idp-ip and port 443

Если SYN-пакет не выходит с клиента, ищите локальное правило или маршрут. Если SYN уходит, но ответа нет, проверяйте обратный путь, ACL, NAT и удаленный firewall. Если TCP устанавливается, а сбой возникает позже, переносите расследование на TLS.

Проблемы маршрутизации часто проявляются после изменений VPN, балансировщика или облачной сети. Для отдельного разбора таблиц маршрутов и трассировки пригодится руководство по диагностике маршрутизации.

Проверка из контейнера или Kubernetes-пода

Повторите DNS- и TCP-проверки из контейнера или pod, где работает интеграция. Проверка с хоста не заменяет проверку приложения: контейнер может использовать другой resolver, proxy, network namespace и egress-маршрут.

docker exec container-name getent hosts idp-host
docker exec container-name nc -vz idp-host 443
kubectl exec pod-name -- getent hosts idp-host
kubectl exec pod-name -- nc -vz idp-host 443
kubectl get pod pod-name -o wide

В Kubernetes проверьте NetworkPolicy, DNS policy, egress-шлюз, service mesh и переменные proxy. В Docker проверьте выбранную network, правила хоста и маршрут контейнера. Если требуется чистый внешний egress для сравнения, тестовый VDS или Kubernetes-контур можно разместить в Timeweb Cloud, сохранив те же hostname, порт и TLS-параметры.

Проверка TLS-рукопожатия и сертификата IdP

TLS начинается после успешного TCP-соединения. Ошибка handshake, certificate verify failed или hostname mismatch относится к защищенному каналу. Проверка токена, MFA и роли пользователя на этом этапе преждевременна.

Проверка сертификата и имени хоста

Запустите TLS-проверку с явным SNI:

openssl s_client -connect idp-host:443 -servername idp-host -showcerts
curl -v https://idp-host/

Проверьте следующие поля:

SAN. В расширении Subject Alternative Name должно присутствовать имя, по которому подключается клиент.
Срок действия. Дата начала и окончания сертификата должна включать текущее системное время.
Цепочка. Сервер должен передавать промежуточные сертификаты, необходимые клиенту для построения цепочки.
SNI. Для виртуального хоста сервер выбирает сертификат по имени из TLS ClientHello. Поэтому команда без -servername может показать другой сертификат.
Фактический адрес. Подключение к IP при сохранении hostname для TLS помогает отделить проблему DNS от проблемы сертификата.

Не подставляйте IP-адрес вместо hostname в рабочей конфигурации, если сертификат выпущен на доменное имя. Такое изменение часто убирает DNS из цепочки, но создает ошибку проверки имени.

Проверка доверенного хранилища CA

Один и тот же сертификат может приниматься на рабочей станции и отклоняться в контейнере. Сравните CA bundle на клиенте, сервере, минимальном образе и pod.

В Debian и Ubuntu проверьте наличие пакета ca-certificates и файл /etc/ssl/certs/ca-certificates.crt.
В системах семейства RHEL проверьте пакет ca-certificates и системное хранилище CA.
В минимальных контейнерных образах корневые сертификаты могут отсутствовать полностью.
При TLS-инспекции proxy клиенту нужен корпоративный корневой сертификат, которым подписывается промежуточный сертификат proxy.
Устаревшее хранилище CA может не доверять новой цепочке, даже если сертификат IdP корректен.

Устанавливайте корпоративный CA только из проверенного внутреннего источника и фиксируйте его владельца. Не отключайте проверку сертификатов через переменные SDK или параметры curl ради восстановления доступа.

Проверка системного времени и версии TLS

Проверьте часы и синхронизацию:

timedatectl
chronyc tracking
w32tm /query /status

Сдвиг времени ломает проверку срока действия сертификата и может нарушить работу токенов с ограниченным временем жизни. Сопоставьте время клиента, сервера, proxy и IdP в UTC.

Если сертификат и время корректны, проверьте поддерживаемые версии TLS и криптографические параметры клиента. Для изолированного теста можно явно указать версию TLS в openssl s_client, затем сравнить результат с настройками приложения или SDK. Принудительное включение устаревших протоколов не подходит как постоянное исправление.

Как отличить TLS-ошибку от ошибки авторизации

Признак	Что он означает
Нет HTTP-ответа, handshake failed	Соединение остановилось на TLS-уровне
certificate verify failed	Проблема с цепочкой доверия, CA bundle, сроком или сертификатом proxy
hostname mismatch	Имя endpoint не совпадает с SAN сертификата
HTTP 401	Запрос дошел до IdP, но учетные данные или токен не приняты
HTTP 403	Доступ запрещен политикой, ролью, IP-ограничением или настройками приложения

Когда клиент получает HTTP-ответ от IdP, сетевой путь и TLS уже подтверждены для этой попытки. Дальше переходите к OAuth или OIDC, issuer, redirect URI, сроку действия токена, MFA и политике доступа.

Как определить: проблема у клиента, в инфраструктуре или на стороне IdP

Сравнение нескольких источников подключения

Проведите одну и ту же проверку из нескольких источников и записывайте результаты в одной таблице.

Источник	Что сравнить	Как трактовать результат
Одна рабочая станция	DNS, proxy, браузер и CLI	Сбой только в одном клиенте указывает на локальную конфигурацию
Несколько рабочих станций	Один hostname и порт	Общий сбой повышает вероятность проблемы сети, DNS или IdP
Серверный сегмент	Маршрут, egress и firewall	Разница с рабочими станциями показывает сегментацию сети
Контейнер или pod	Resolver, proxy и NetworkPolicy	Сбой только в pod указывает на изоляцию приложения
Альтернативная сеть	Прямой канал, VPN или мобильная сеть	Разница локализует проблему у провайдера, VPN или корпоративного периметра

Если одинаковая ошибка воспроизводится с разных сетей, клиентов и окружений, повышается вероятность сбоя IdP, общей DNS-зоны или центрального firewall. Если один клиент получает 401, а другие подключаются, ищите его учетные данные, токен, время или локальный proxy.

Проверка журналов приложения, proxy и балансировщика

Сопоставляйте записи по UTC и корреляционному идентификатору. Ищите конкретные сообщения:

timeout, upstream timed out и context deadline exceeded указывают на задержку или отсутствие ответа.
connection refused означает отказ на TCP-уровне.
connection reset показывает, что соединение было закрыто одной из сторон.
DNS failure и temporary failure in name resolution указывают на resolver или DNS-маршрут.
certificate verify failed, SSL_do_handshake() failed и unknown ca требуют проверки TLS.
HTTP 401, 403, 429 и 5xx нужно сопоставить с журналом IdP, чтобы отличить политику доступа от перегрузки или сбоя сервиса.

Проверяйте журналы reverse proxy и балансировщика на границе инфраструктуры. Запись о входящем запросе в proxy подтверждает, что трафик дошел до этой точки, но не доказывает успешный обмен с IdP.

Проверка состояния IdP и endpoint

Проверьте status page поставщика, discovery-документ, health endpoint и актуальность issuer. Если status page показывает инцидент, сохраните время начала сбоя и локальные результаты проверок для эскалации.

Не путайте недоступность endpoint с блокировкой пользователя. Заблокированный аккаунт, ошибка MFA или отказ по conditional access обычно возвращают HTTP-ответ. Полностью недоступный endpoint не позволяет выполнить такой этап авторизации.

Проверьте, что приложение обращается к актуальному домену IdP и использует корректный redirect URI. После миграции старый endpoint может продолжать разрешаться, но уже не принимать запросы нужного клиента.

Когда сетевую диагностику можно завершить

Сетевой путь подтвержден, если одновременно выполняются четыре условия:

Hostname стабильно разрешается в ожидаемый IP-адрес.
Маршрут проходит через предусмотренный интерфейс, VPN или proxy.
TCP-соединение с нужным портом устанавливается.
TLS проверяет сертификат, имя, цепочку доверия и системное время, после чего IdP возвращает HTTP-ответ.

После этого прекращайте повторять DNS- и сетевые тесты. Переходите к OAuth или OIDC, учетным данным, MFA, redirect URI, scope, ролям и политике доступа.

Что зафиксировать после восстановления доступа

Инвентаризация сервисов и зависимостей

Запишите сведения, которые позволят повторить диагностику без поиска по чатам и личным заметкам:

Название IdP, endpoint, issuer и приложения, которые от него зависят.
DNS-зоны, записи A и AAAA, TTL, приватные и публичные адреса.
Порты, маршруты, VPN, proxy, egress-шлюзы, NAT, firewall, ACL и security group.
Сертификаты, цепочки доверия, CA bundle, дату окончания и владельца продления.
Окружения, где работает интеграция: рабочие станции, серверы, контейнеры и Kubernetes-поды.
Технического владельца, резервного ответственного и контакт поставщика.

Такой перечень соответствует базовой логике инвентаризации активов, ПО, аккаунтов и данных, которую используют CIS Controls v8.1 и NIST Cybersecurity Framework 2.0. Без списка зависимостей повторный инцидент снова начинается с вопроса, кто отвечает за DNS, сертификат или аккаунт.

Резервное восстановление доступа

Проверьте корпоративное владение учетными записями и наличие нескольких администраторов. Для критичного сервиса восстановление не должно зависеть от личной почты или телефона одного сотрудника.

Используйте групповой адрес, контролируемый компанией.
Назначьте минимум двух ответственных администраторов.
Зафиксируйте резервный процесс восстановления и периодически проверяйте его.
Храните сведения о подписках, доменах, сертификатах и интеграциях в общей базе знаний.
После увольнения или смены подрядчика сразу меняйте владельцев, токены и резервные контакты.

Документируйте не только способ входа, но и порядок действий при потере доступа. Проверка восстановления должна проходить в контролируемое время, чтобы не обнаружить нерабочий резервный канал во время аварии.

MFA и контроль привилегированных аккаунтов

После устранения сетевой ошибки не ослабляйте защиту ради скорости. Для внешнего, удаленного и административного доступа используйте MFA. Для привилегированных аккаунтов выбирайте устойчивые к фишингу варианты, например аппаратные ключи или passkey, если IdP их поддерживает.

Отделяйте обычные и административные учетные записи.
Ограничивайте резервные методы MFA и храните их под контролем компании.
Проверяйте, что резервный администратор может пройти MFA без личного устройства уволенного сотрудника.
Не отключайте проверку TLS, MFA или conditional access как постоянный способ устранения сбоя.

Финальная запись об инциденте должна содержать симптом, время, источник запроса, подтвержденный уровень сбоя, исправленную настройку и шаг, который подтвердил восстановление. Такой формат превращает разовую диагностику в рабочую инструкцию для следующего специалиста.