Kako spletna aplikacija Azure doseže lokalno uporabo prek VPN-ja

Izhodna zahteva spletne aplikacije pusti delavca, ki ga nikoli ne vidite, iz vira, ki ga niste izbrali, in požarni zid v pisarni jo mora sprejeti. To je celoten problem v enem stavku. Regionalna integracija VNet daje zahtevi pot v navidezno omrežje, VPN od mesta do mesta pa jo prenese od tam. Vse, kar gre pozneje narobe, je povezano z izvornim obsegom in katero potjo je paket dejansko uporabil.

Kaj delavec dejansko pošilja

App Service izvaja vašo kodo na delavcih, ki so zunaj omrežnega pogleda vaše naročnine. Ko je omogočena regionalna integracija, je odhodni promet predan delegiranemu podomrežju v omrežju VNet v isti regiji in paket se tam prikaže, preden se nadaljuje. Integracija ne premakne aplikacije v VNet in ne spremeni njenega vhodnega naslova. Samo odhodnim tokovom daje drugačen prvi skok.

Privzeto gre samo za zasebni naslovni prostor po tej poti, tako da običajni internetni cilji še vedno odidejo neposredno od delavca. Usmerjanje vsega prek omrežja VNet je ločena nastavitev in ločena odločitev, saj pošilja tudi vaše javne odvisnosti čez tunel.

Konfiguracijski promet, kot je vlečenje slike vsebnika ob zagonu, sledi lastnim pravilom usmerjanja in lahko spodleti, medtem ko vaši klici API-ja uspejo.

Integracijsko podomrežje je vir, ki ga morate dovoliti

Pisarna vidi obseg naslovov integracijskega podomrežja ali kar koli, v kar ga vaša naprava prevede, ne pa javnih odhodnih naslovov aplikacije. Ta obseg vnesite v izbirnike prometa VPN spletnega mesta in v pravilo požarnega zidu na mestu uporabe. Če predor temelji na pravilniku, izbirniki, ki ga izpustijo, izpustijo paket, tudi če pot obstaja.

Ne dovolite, da bi opazili en naslov delavca. Primerki se spreminjajo s skaliranjem in vzdrževanjem platforme, pravilo, pripeto na en naslov, pa se prekine v najslabšem trenutku.

Ciljna stran naj bo ozka: ena storitev, ena vrata, ena smer, povratna pot pa je izrecno dovoljena.

Vzvrstitev in tranzit prehoda sta eksplicitna

Če je prehod VPN v zvezdišču VNet in integracijsko podomrežje v razdelilniku, mora pot omogočiti tranzit prehoda na enakovrednem zvezdišču in uporabo oddaljenega prehoda omogočiti na enakovrednem povezovanju. Peering samo po sebi prenaša promet med obema VNets in nič več. Učinkovite poti v integracijskem podomrežju so tam, kjer potrdite, da je naslednji prehod res tam.

Načrt zvezdišča in kraka, katerega tabela usmerjanja pošlje 0.0.0.0/0 požarnemu zidu, je pogosta različica, ta požarni zid pa nato potrebuje lastno pravilo za lokalno predpono.

Narišite pot na papir, preden odprete vozovnico z omrežno ekipo, saj si tako prihranite dan ugibanja. V risbo vključite povratno smer, saj to polovica ljudi pozabi.

Vhodna zasebna končna točka je druga smer

Zasebna končna točka omogoča dosegljivost aplikacije znotraj VNeta. Ne naredi ničesar za odhodni klic aplikacije v pisarno in ekipe ga redno konfigurirajo, medtem ko je bila dejanska zahteva obratna.

Starejša dokumentacija opisuje integracijo, potrebno za prehod, zgrajeno na VPN od točke do mesta, ki je drugačna funkcija s svojimi zahtevami. Microsoft načrtuje umik te funkcije za 31. marec 2027 in namesto tega priporoča regionalno integracijo.

Ne kopirajte podedovane konfiguracije od točke do mesta samo zato, ker jo je uporabljal stari primer.

Preverite z lastnim kontekstom aplikacije

Preizkusite iz uvedene aplikacije, ne iz prenosnega računalnika in ne iz VM v istem VNetu. Ločeno zabeležite razrešen naslov, rezultat povezave in odziv na ravni aplikacije, ker so napaka DNS, časovna omejitev TCP in zavrnitev preverjanja pristnosti pri treh različnih lastnikih. Če razrešitev imena ne uspe, popravite zasebni DNS za VNet, preden se dotaknete tunela.

Zeleno stanje tunela samo dokazuje, da prehod deluje. Nič ne pove o izbirnikih, pravilih požarnega zidu ali DNS.

Ko zahteva končno deluje, zapišite izvorni obseg, ciljna vrata in cono DNS v runbook aplikacije. Naslednja oseba, ki bo to odpravila, bo začela z vašo opombo namesto s strani s stanjem prehoda.