Как уеб приложение на Azure достига локално чрез VPN

Изходящата заявка на уеб приложението оставя работник, когото никога не виждате, от източник, който не сте избрали, и защитната стена на офиса трябва да я приеме. Това е целият проблем в едно изречение. Регионалната VNet интеграция дава на заявката път към виртуална мрежа, а VPN от сайт към сайт я пренася оттам. Всичко, което се обърка след това, е свързано с обхвата на източника и кой маршрут действително е използван от пакета.

Какво всъщност изпраща работникът

Услугата за приложения изпълнява вашия код на сътрудници, които се намират извън мрежовия изглед на вашия абонамент. При активирана регионална интеграция изходящият трафик се предава на делегирана подмрежа във VNet в същия регион и пакетът се появява там, преди да продължи. Интегрирането не премества приложението във VNet и не променя входящия му адрес. Той само дава на изходящите потоци различен първи скок.

По подразбиране само частното адресно пространство поема по този път, така че обикновените интернет дестинации все още тръгват директно от работника. Маршрутизирането на всичко през VNet е отделна настройка и отделно решение, защото то също така изпраща вашите публични зависимости през тунела.

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

Интеграционната подмрежа е източникът, който трябва да разрешите

Офисът вижда диапазона от адреси на интегрираната подмрежа или каквото и да е, в което го преобразува вашето устройство, а не публичните изходящи адреси на приложението. Поставете този диапазон в селекторите за трафик на VPN на сайта и в правилото на локалната защитна стена. Ако тунелът е базиран на правила, селекторите, които го пропускат, изпускат пакета дори когато съществува маршрут.

Не позволявайте да наблюдавате нито един адрес на работник. Екземплярите се променят с мащабиране и поддръжка на платформата и правило, фиксирано към един адрес, се нарушава в най-лошия момент.

Поддържайте страната на местоназначението тясна: една услуга, един порт, една посока, с изрично разрешен път за връщане.

Връзката и транзитът през шлюза са изрични

Ако VPN шлюзът се намира в хъб VNet и интеграционната подмрежа в лъч, пътят се нуждае от транзит през шлюза, разрешен на пиринга на хъба и използването на отдалечен шлюз, активиран на върховия пиринг. Пиърингът сам по себе си пренася трафик между двете виртуални мрежи и нищо повече. Ефективните маршрути в интеграционната подмрежа са там, където потвърждавате, че следващият шлюз наистина е там.

Хъб-и-спицов дизайн, чиято таблица с маршрути изпраща 0.0.0.0/0 към защитна стена, е често срещан вариант и тази защитна стена след това се нуждае от собствено правило за локалния префикс.

Начертайте пътя на хартия, преди да отворите билет с екипа на мрежата, защото това спестява цял ден гадаене. Включете посоката на връщане в чертежа, тъй като това е половината хора, които забравят.

Входящата частна крайна точка е другата посока

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

По-старата документация описва необходимата за шлюз интеграция, изградена на VPN от точка до сайт, различна функция със собствени изисквания. Microsoft планира оттеглянето на тази функция за 31 март 2027 г. и вместо това препоръчва регионална интеграция.

Не копирайте наследена конфигурация от точка до сайт само защото стар пример я е използвал.

Проверете със собствения контекст на приложението

Тествайте от внедреното приложение, а не от вашия лаптоп и не от виртуална машина в същата VNet. Регистрирайте разрешения адрес, резултата от връзката и отговора на ниво приложение поотделно, тъй като повреда на DNS, изчакване на TCP и отхвърляне на удостоверяване точка при трима различни собственици. Ако преобразуването на имена е неуспешно, коригирайте частния DNS за VNet, преди да докоснете тунела.

Състоянието на зеления тунел само доказва, че шлюзът работи. Не казва нищо за селектори, правила на защитната стена или DNS.

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