Azure «точка — сайт» подключается, но ни один частный ресурс не отвечает

Подключено — это состояние туннеля, а не утверждение о доступности. Клиент «точка — сайт» может завершить IKE, получить адрес и всё равно никуда не попасть, потому что шлюз передаёт трафик только для сетей, которые VNet уже знает. Выполните эти пять проверок по порядку и остановитесь на первой неудаче. Перескакивать вперёд — это способ час лечить проблему DNS как проблему межсетевого экрана.

Порядок важнее списка.

Проверка 1: решите, что туннель должен передавать

Azure VPN Gateway завершает туннель и передаёт трафик, принадлежащий VNet; это необщий выход в интернет. Если пользователи ожидают, что их просмотр пойдёт через Azure, проект неверен ещё до того, как в дело вступит любая настройка клиента. Включите split tunneling, чтобы локальный интернет оставался на локальном пути, а экземпляр NAT или туннель «сайт — сайт» используйте, когда действительно нужен фиксированный адрес выхода.

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

Проверка 2: сравните адресные пространства до сертификатов

Перекрытие оценивается по более широким диапазонам, поэтому две сети, которые на уровне подсети выглядят разными, всё равно конфликтуют, если их родительские блоки перекрываются. Подсеть шлюза должна быть выделенной и достаточно большой для SKU, а пул адресов клиента не должен конфликтовать с VNet или с чем-либо, доступным через peering. Измените план и разверните заново, потому что добавление маршрутов для компенсации создаёт туннель, который работает для одних назначений и необъяснимо не работает для других. Подготовка здесь громко падает, и это хороший случай.

Аутентификация — следующие ворота. Профили сертификата, RADIUS и Entra ID не взаимозаменяемы, и клиентский пакет для каждого отличается.

Проверка 3: разрешите частное имя изнутри

Клиент сохраняет собственный resolver, если только загруженный профиль не содержит DNS-серверы VNet, а этот список встраивается в момент загрузки. Добавьте forwarder внутри VNet, назначьте его DNS-сервером VNet, затем снова скачайте и импортируйте клиентский пакет. Повторное использование старого пакета проверяет только старый список resolver-ов.

Сначала проверьте адрес, потому что это одним шагом отделяет маршрутизацию от имён: Test-NetConnection 10.20.1.4 -Port 3389.

Если адрес отвечает, а имя нет, спросите resolver напрямую командой Resolve-DnsName files.corp.example -Server 10.20.0.4. Если не работает и то и другое, неисправность не в DNS, и вам стоит перестать менять настройки DNS. DNS платформы Azure по адресу 168.63.129.16 отвечает только изнутри VNet, поэтому клиент снаружи не может использовать этот адрес как resolver.

Проверка 4: проверьте службу за туннелем

Здоровый туннель и закрытый порт со стороны клиента выглядят одинаково. Проверьте межсетевой экран гостя, затем группу безопасности сети на подсети или NIC, затем то, слушает ли служба частный адрес, а не только loopback. Разрешите пул клиентов как источник вместо открытия правила в интернет и помните, что SMB к Azure Files требует, чтобы путь частной конечной точки шёл через туннель. Когда ресурс отвечает по IP, но не по имени, вернитесь к проверке 3, а не трогайте шлюз.

Одна таблица разделяет уровни во время работы:

Проверка 5: зафиксируйте профиль до эскалации

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

Для небольшой команды устойчивый проект — это один VNet, один DNS-forwarder и документированный клиент с split tunneling. Если требование — фиксированный публичный выход, завершите туннель «сайт — сайт» на межсетевом экране, который вы контролируете, и направьте интернет-трафик туда, вместо того чтобы просить шлюз «точка — сайт» делать то, для чего он никогда не создавался.