Azure P2S VPN не может разрешить имя частной конечной точки

Вы подключаете туннель point-to-site, пингуете частный адрес, открываете приложение и вместо этого получаете 403 или ошибку сертификата. Оба симптома указывают на DNS, но это разные неисправности: один означает, что клиент разрешил публичный адрес, другой — что он разрешил частный адрес и затем предложил имя, которое сертификат не покрывает. Пройдите проверки ниже по порядку и остановитесь на первом сбое, потому что запись в hosts или ответ из кэша могут заставить каждую следующую проверку пройти по неверной причине. Я держу этот порядок в текстовом файле рядом с профилями VPN, потому что исправление ничего не меняет в туннеле и меняет всё в том, что знает клиент.

Начните с адреса, который клиент действительно получает

Спросите резолвер напрямую, вместо того чтобы доверять приложению. В Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net показывает, какое представление получил клиент. Публичный ответ означает, что дальше ничто не достигнет конечной точки; частный адрес конечной точки означает, что DNS завершён и следующая проверка — само соединение.

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

Проверьте зону, её привязку и запись до туннеля

Три условия должны выполняться вместе: частная зона существует, она привязана к виртуальной сети, в которую входят в Azure шлюз VPN и клиенты, и в ней есть запись A для конечной точки, указывающая на частный адрес. Привяжите зону к посторонней сети, и шлюз продолжит разрешать публичную запись, пока всё в туннеле выглядит здоровым.

Имена зон принадлежат службам, а не частным связям вообще. App Service обычно использует privatelink.azurewebsites.net, у хранилища и SQL свои пространства имён, а заимствование зоны другой службы даёт зону, которая существует и не отвечает ничего полезного.

Дайте клиенту резолвер, до которого он действительно дотянется

168.63.129.16 отвечает с виртуальных машин Azure и не является DNS-сервером для ноутбука по другую сторону туннеля point-to-site. Клиенту нужен резолвер, доступный через туннель: входящая конечная точка Azure DNS Private Resolver, пересыльщик внутри виртуальной сети или записи DNS-сервера, переносимые в профиле клиента VPN, чтобы клиент спрашивал виртуальную сеть напрямую.

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

Если вы пересылаете, а не проталкиваете параметры, пересылайте пространство имён, которым владеет частная зона, privatelink.azurewebsites.net, а не всё azurewebsites.net. Условный пересыльщик, который проглатывает весь родительский суффикс, отправляет в Azure каждый поиск службы, включая те, что должны остаться локальными.

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

Когда адрес верен, проявляется вторая неисправность. Хранилище и App Service публикуют псевдоним privatelink, и этот псевдоним не обязательно является именем в сертификате. Загрузка AzCopy на privatelink.blob.core.windows.net не прошла проверку; та же загрузка на <account>.blob.core.windows.net/<container> разрешилась в частный адрес и прошла, поэтому осталась на частном пути без всякого обхода.

Правило действует в браузере и для App Service: подключайтесь по имени узла, которое покрывает сертификат, и позвольте DNS предоставить частный адрес. Не прибегайте к обходу проверки, потому что он превращает ошибку в именовании в регрессию безопасности. Успешный ping доказывает маршрут и ничего не говорит об имени внутри рукопожатия, поэтому это остаётся отдельными проверками.

Порядок из четырёх шагов, изолирующий каждый слой

1. Убедитесь, что клиент VPN имеет адрес из пула point-to-site и маршрут к частному адресу конечной точки.
2. Разрешите точное имя, которое использует приложение, и сравните ответ с адресом конечной точки.
3. Откройте TCP-соединение с конечной точкой на порту службы, затем прочитайте имя сертификата, предъявленного в этом соединении.
4. Только теперь проверяйте авторизацию, потому что работающий маршрут и действительный сертификат ещё не дают доступа к ресурсу.

Отказ в соединении при верном адресе указывает на группу безопасности сети или состояние подключения частной конечной точки, а не на DNS, поэтому проверьте их, прежде чем снова править параметры резолвера. Несовпадение имени TLS возвращает вас к имени узла в URL и subject сертификата. Держите вместе вывод разрешения, имя сертификата и точный URL; эти три значения объясняют большинство таких случаев, не касаясь шлюза.

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

Клиенты тоже кэшируют. Запись, которая публично ответила десять минут назад, продолжает отвечать и после исправления зоны, поэтому очистите кэш перед повторной проверкой. В Windows ipconfig /flushdns очищает кэш клиента; правила политики разрешения имён сохраняются, определяют, какой суффикс идёт к какому серверу, и могут продолжать отправлять пространство имён резолверу, который вы только что заменили.

Где место записи в hosts

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

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

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