Odchozí požadavek webové aplikace zanechá pracovníka, kterého nikdy nevidíte, ze zdroje, který jste si nezvolili, a kancelářský firewall jej musí přijmout. To je celý problém v jedné větě. Regionální integrace virtuálních sítí poskytuje požadavku cestu do virtuální sítě a síť VPN typu site-to-site jej odtud přenáší. Všechno, co se poté pokazí, je o tom, jaký zdrojový rozsah a jakou cestu paket skutečně použil.

Co pracovník skutečně posílá

App Service spouští váš kód u pracovníků, kteří sedí mimo zobrazení sítě vašeho předplatného. Když je povolena regionální integrace, odchozí provoz je předán do delegované podsítě ve virtuální síti ve stejné oblasti a paket se tam objeví, než bude pokračovat. Integrace nepřesune aplikaci do virtuální sítě a nezmění její příchozí adresu. Pouze dává odchozím tokům jiný první skok.

Ve výchozím nastavení prochází touto cestou pouze soukromý adresní prostor, takže běžné internetové cíle stále odcházejí přímo od pracovníka. Směrování všeho přes virtuální síť je samostatné nastavení a samostatné rozhodnutí, protože také posílá vaše veřejné závislosti přes tunel.

Konfigurační provoz, jako je načtení obrázku kontejneru při spuštění, se řídí svými vlastními pravidly směrování a může selhat, zatímco vaše volání API budou úspěšná.

Integrační podsíť je zdroj, který musíte povolit

Kancelář vidí rozsah adres integrační podsítě nebo cokoliv, do čeho to vaše zařízení přeloží, nikoli veřejné odchozí adresy aplikace. Vložte tento rozsah do selektorů provozu VPN na webu a do pravidla místní brány firewall. Pokud je tunel založen na zásadách, selektory, které jej vynechávají, zahodí paket, i když trasa existuje.

Nepovolte adresu jednoho pracovníka, kterou jste náhodou viděli. Instance se mění se škálováním a údržbou platformy a pravidlo připnuté na jednu adresu se v nejhorší chvíli poruší.

Zachovejte úzkou cílovou stranu: jedna služba, jeden port, jeden směr, s explicitně povolenou zpáteční cestou.

Peering a přenos brány jsou explicitní

Pokud je brána VPN umístěna ve virtuální síti rozbočovače a integrační podsíť v paprsku, cesta potřebuje, aby byl na partnerském vztahu hubu povolen přenos brány a na paprskovém partnerském vztahu povoleno použití vzdálené brány. Peering sám o sobě přenáší provoz mezi dvěma virtuálními sítěmi a nic víc. Efektivní trasy v integrační podsíti jsou tam, kde potvrzujete, že další skok brány tam skutečně je.

Obvyklou variantou je návrh hub-and-spoke, jehož směrovací tabulka posílá 0.0.0.0/0 firewallu, a tento firewall pak potřebuje vlastní pravidlo pro místní předponu.

Před otevřením tiketu s týmem sítě nakreslete cestu na papír, protože to ušetří den hádání. Zahrňte do výkresu směr návratu, protože to je polovina, na kterou lidé zapomínají.

Příchozí soukromý koncový bod je opačným směrem

Soukromý koncový bod umožňuje aplikaci dosažitelnou z virtuální sítě. Nedělá nic pro odchozí volání aplikace do kanceláře a týmy je pravidelně konfigurují, zatímco skutečný požadavek byl opačný.

Starší dokumentace popisuje integraci vyžadovanou bránou postavenou na VPN typu point-to-site, což je odlišná funkce s vlastními požadavky. Microsoft plánuje ukončení této funkce na 31. března 2027 a místo toho doporučuje regionální integraci.

Nekopírujte starší konfiguraci point-to-site jen proto, že ji používal starý příklad.

Ověřte pomocí vlastního kontextu aplikace

Testujte z nasazené aplikace, nikoli z notebooku a ne z virtuálního počítače ve stejné virtuální síti. Samostatně zaznamenejte vyřešenou adresu, výsledek připojení a odpověď na úrovni aplikace, protože selhání DNS, vypršení časového limitu TCP a odmítnutí ověření vedou ke třem různým vlastníkům. Pokud se překlad názvů nezdaří, opravte soukromý DNS pro virtuální síť, než se dotknete tunelu.

Stav zeleného tunelu pouze dokazuje, že brána je aktivní. Neříká nic o selektorech, pravidlech brány firewall nebo DNS.

Když požadavek konečně funguje, zapište zdrojový rozsah, cílový port a zónu DNS do runbooku aplikace. Další osoba, která to bude ladit, začne od vaší poznámky, nikoli od stavové stránky brány.

Související články