Почему частная конечная точка по-прежнему отвечает публичным адресом

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

Начните с резолвера клиента

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

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

Прочитайте, чем на самом деле является ответ

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

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

Запись в hosts доказывает путь, а затем лжёт

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

Оно не помогает второй учётной записи, второй конечной точке или коллеге и ломается без предупреждения, когда конечная точка создаётся заново по новому адресу.

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

Свяжите зону и выдайте резолвер

Два условия должны выполняться одновременно. Частная зона должна быть связана с виртуальной сетью, где находится конечная точка, а клиент должен отправлять запросы на сервер, который умеет читать эту зону. Входящая конечная точка DNS Private Resolver предоставляет такой адрес внутри сети и отвечает на запросы, приходящие через туннель. Поместите этот адрес в профиль VPN и добавьте частный суффикс, который клиент должен применять.

Уже существующий локальный резолвер может достичь того же результата через условную пересылку, направленную на зону.

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

Проверяйте имя, порт и идентичность по порядку

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

Частный ответ, за которым следует тайм-аут, указывает на маршрут или межсетевой экран. Публичный ответ указывает на резолвер. Завершённое соединение, возвращающее ошибку идентичности, относится к службе.

Ещё один отказ входит в этот список. Межсетевой экран службы, разрешающий адрес клиента, перестаёт совпадать, когда пул после переподключения отдаёт этот адрес другой сессии. Читайте адрес вызывающего, записанный службой, а не тот, который клиент считает своим. Эти два расходятся чаще, чем люди ожидают. Руководство по Azure DNS Private Resolver описывает связь зоны и схему пересылки.