Туннель поднят, так почему приватное имя всё ещё не разрешается?

В соединении всё выглядит правильно: туннель поднят, консоль показывает приватную конечную точку, но каждый запрос завершается неудачей при разрешении имён. Естественный шаг — винить туннель, который обычно оказывается невиновен. Запрос отправляется на сервер, который ничего не знает о приватной зоне. Никакое изменение маршрутизации не изменит этот ответ, потому что проблема в том, кого спросили.

Какой резолвер получил запрос?

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

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

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

Используйте адрес, на который облачная сеть действительно отвечает

Облачные сети обычно отвечают на приватные имена по зарезервированному адресу, смещённому на два от основания диапазона, поэтому сеть, начинающаяся с 10.0.0.0, отвечает на 10.0.0.2. Некоторые провайдеры также публикуют локальный для соединения резолвер, который работает без знания диапазона, что помогает, когда сеть построил кто-то другой. Спросите адрес-кандидат напрямую, прежде чем передавать его кому-либо. Адрес, который не является резолвером, выглядит точно как отбрасывание межсетевым экраном, потому что запрос просто никогда не получает ответа.

Если прямой запрос отвечает изнутри сети, но не через туннель, резолвер в порядке, а путь между двумя точками — нет. Этот результат переносит расследование на маршруты, пересылку и правила доступа, а не на профиль клиента.

Туннель не несёт пространство имён

Пакеты проходят; имена — нет. Каждой стороне нужно сказать, какое пространство имён принадлежит другой, и это отдельный объект, которым владеет тот, кто держит зону. Обычная форма — пересылка для одного пространства имён, направленная на резолвер, доступный через туннель.

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

Пройдите границы по порядку

Проверьте резолвер, установленный на активном соединении, затем прямой запрос к этому резолверу, затем тот же запрос с дальней стороны и наконец приложение, использующее то же имя. Каждый шаг изолирует одну границу, поэтому сбой подсказывает, где смотреть, вместо того чтобы начинать расследование заново. Ответ, который работает, пока приложение терпит неудачу, указывает на доверие сертификату или политику API, а не на DNS. Эти неисправности реальны, и никакое изменение резолвера их не исправит.

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

Держите цепочку там, где следующий человек сможет её найти

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

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