Проверка IP-потока Azure сообщает «разрешено», но VPN всё равно не работает

Туннель «сайт — сайт» подключён, виртуальная машина здорова, но локальный клиент ничего не получает. Вы открываете Network Watcher, запускаете проверку IP-потока, и она говорит Access allowed, поэтому заявку закрывают как проблему VPN. Этот результат означает не то, чем кажется, потому что проверка IP-потока оценивает правила безопасности для описанного вами потока и никогда не проверяет, есть ли у Azure маршрут к вашему локальному префиксу.

Вопрос фильтрации и вопрос маршрутизации разделены, и Network Watcher отвечает на них разными инструментами. Понимание того, какой именно вопрос вы задали, — большая часть диагностики.

Что на самом деле решает проверка IP-потока

Проверка IP-потока принимает виртуальную машину, сетевой интерфейс, направление, значения пятёрки и протокол, а затем сообщает решение правила NSG и администратора безопасности для этого потока. Она работает по TCP и UDP, поэтому не является тестером правил ICMP, и заблокированный ping ничего не доказывает о вашей службе. Дайте ей реальный поток, а не догадку. Входящее соединение из локальной среды к порту базы данных — это другое описание, чем исходящее соединение, которое инициирует виртуальная машина.

Если шлюз транслирует адреса, используйте адрес источника, который достигает оцениваемой границы, а не тот, что в конфигурации клиента. Читайте результат и таким, каков он есть. Access allowed означает, что уровень фильтрации пропустил бы пакет, если бы он пришёл, и не более.

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

Что добавляют следующий переход и действующие маршруты

Следующий переход отвечает на вопрос пересылки: для этого назначения какой тип следующего перехода выбирает Azure, по какому адресу, из какой таблицы маршрутов. Действующие маршруты перечисляют то, что NIC действительно имеет. Запустите оба, и вы получите путь на стороне Azure, который зелёная проверка IP-потока оставляет пустым.

Обзор проверки IP-потока от Microsoft прямо указывает область фильтрации, а страницы о следующем переходе и диагностике маршрутов охватывают сторону пересылки. Цитируйте правильную страницу, когда записываете вывод.

Команды достаточно короткие, чтобы запускать их из оболочки. az network nic show-effective-route-table перечисляет маршруты, применённые к интерфейсу. az network watcher show-next-hop с источником и назначением возвращает выбранный переход. Сравните нужный вам префикс с этой таблицей, затем подтвердите, какая запись побеждает.

Пройдите обратный путь от NIC виртуальной машины

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

Если ожидаемого маршрута нет, проверьте удалённые префиксы, которые предоставляет конфигурация шлюза, схему подключения VNet и любые параметры распространения маршрутов. Объект локального сетевого шлюза описывает локальную сторону; его наличие не доказывает, что каждый нужный префикс присутствует и предпочтителен на NIC. Это разные факты, и только один из них виден в сводке портала.

Читайте тип следующего перехода, а не копируйте пример

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

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

Перейдите к границе, которая всё ещё не работает

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

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