Kako Azure Web aplikacija dolazi do lokalne lokacije putem VPN-a

Izlazni zahtjev Web aplikacije ostavlja radnika kojeg nikada ne vidite iz izvora koji niste odabrali, a uredski firewall ga mora prihvatiti. To je cijeli problem u jednoj rečenici. Regionalna VNet integracija daje zahtjevu putanju do virtuelne mreže, a od lokacije do lokacije VPN ga prenosi. Sve što nakon toga krene po zlu odnosi se na to koji izvorni opseg i koju rutu je paket zapravo koristio.

Šta radnik zapravo šalje

App Service pokreće vaš kod na radnicima koji se nalaze izvan mrežnog prikaza vaše pretplate. Sa omogućenom regionalnom integracijom, izlazni saobraćaj se predaje delegiranoj podmreži u VNet-u u istoj regiji, a paket se tamo pojavljuje prije nego što nastavi. Integracija ne premešta aplikaciju u VNet i ne menja njenu ulaznu adresu. Odlaznim tokovima daje samo drugačiji prvi skok.

Podrazumevano samo privatni adresni prostor zauzima taj put, tako da obične internetske destinacije i dalje napuštaju direktno od radnika. Usmjeravanje svega kroz VNet je zasebna postavka i posebna odluka, jer također šalje vaše javne ovisnosti preko tunela.

Konfiguracijski promet, kao što je povlačenje slike kontejnera pri pokretanju, slijedi svoja vlastita pravila rutiranja i može propasti dok vaši API pozivi budu uspješni.

Podmreža integracije je izvor koji morate dozvoliti

Kancelarija vidi raspon adresa integracijske podmreže, ili kako god to vaš uređaj prevede, a ne javne izlazne adrese aplikacije. Stavite taj raspon u selektore prometa VPN-a na web lokaciji i u pravilo lokalnog zaštitnog zida. Ako je tunel baziran na politici, selektori koji ga izostavljaju ispuštaju paket čak i kada ruta postoji.

Ne dozvolite ni jednu adresu radnika koju ste slučajno primijetili. Instance se mijenjaju skaliranjem i održavanjem platforme, a pravilo zakačeno na jednu adresu prekida se u najgorem trenutku.

Neka odredišna strana bude uska: jedna usluga, jedan port, jedan smjer, s eksplicitno dozvoljenim povratnim putem.

Peering i gateway tranzit su eksplicitni

Ako se VPN gateway nalazi u čvorištu VNet, a integracijska podmreža u spojenoj mreži, putanja treba dozvoliti tranzit gateway-a na čvorištu peering i korištenje udaljenog gateway-a omogućeno na spojenom peeringu. Peering samo po sebi nosi saobraćaj između dve VNet mreže i ništa više. Efektivne rute na integracijskoj podmreži su mjesto gdje potvrđujete da je pristupnik sljedeći skok zaista tu.

Dizajn čvorišta čija tabela ruta šalje 0.0.0.0/0 zaštitnom zidu je uobičajena varijanta, a tom zaštitnom zidu tada je potrebno vlastito pravilo za lokalni prefiks.

Nacrtajte putanju na papiru prije otvaranja tiketa s timom mreže, jer štedi dan nagađanja. Uključite smjer povratka u crtež, jer to je polovina koju ljudi zaboravljaju.

Ulazna privatna krajnja tačka je drugi smjer

Privatna krajnja tačka čini aplikaciju dostupnom iz VNeta. Ne radi ništa za odlazni poziv aplikacije u ured, a timovi ga redovno konfiguriraju dok je stvarni zahtjev bio obrnut.

Starija dokumentacija opisuje integraciju potrebnu za gateway, izgrađenu na VPN-u od tačke do mjesta, različitu značajku sa vlastitim zahtjevima. Microsoft zakazuje povlačenje te funkcije za 31. mart 2027. i umjesto toga preporučuje regionalnu integraciju.

Ne kopirajte naslijeđenu konfiguraciju point-to-site samo zato što je to koristio stari primjer.

Provjerite vlastitim kontekstom aplikacije

Testirajte iz implementirane aplikacije, ne sa svog laptopa i ne sa VM-a u istoj VNet. Zabilježite odvojeno razriješenu adresu, rezultat veze i odgovor na nivou aplikacije, jer DNS neuspjeh, TCP timeout i točka odbijanja autentifikacije kod tri različita vlasnika. Ako razlučivanje imena ne uspije, popravite privatni DNS za VNet prije nego dodirnete tunel.

Status zelenog tunela samo dokazuje da je gateway podignut. Ne govori ništa o selektorima, pravilima zaštitnog zida ili DNS-u.

Kada zahtjev konačno proradi, upišite izvorni raspon, odredišni port i DNS zonu u runbook aplikacije. Sljedeća osoba koja će ovo otkloniti počet će od vaše bilješke umjesto od stranice statusa gatewaya.