Как веб-приложение Azure достигает локальной среды через VPN

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

Что на самом деле отправляет исполнитель

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

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

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

Подсеть интеграции — это источник, который вы должны разрешить

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

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

Держите сторону назначения узкой: одна служба, один порт, одно направление, с явно разрешенным обратным путем.

Пиринг и транзит шлюза указаны явно

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

Распространенным вариантом является звездообразная схема, в которой таблица маршрутов отправляет 0.0.0.0/0 на брандмауэр, и тогда этому брандмауэру требуется собственное правило для локального префикса.

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

Входящая частная конечная точка — в другом направлении

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

В старой документации описывается интеграция, необходимая для шлюза, основанная на VPN типа «точка-сеть» — другой функции со своими собственными требованиями. Microsoft планирует прекратить поддержку этой функции 31 марта 2027 года и вместо этого рекомендует региональную интеграцию.

Не копируйте устаревшую конфигурацию «точка-сеть» только потому, что она использовалась в старом примере.

Проверьте контекст приложения

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

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

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