Paano Naaabot ng Azure Web App ang Nasa Nasasakupan Sa pamamagitan ng VPN

Ang papalabas na kahilingan ng Web App ay nag-iiwan sa isang manggagawang hindi mo nakikita, mula sa isang pinagmulan na hindi mo pinili, at kailangang tanggapin ito ng firewall ng opisina. Iyan ang buong problema sa isang pangungusap. Ang pagsasama-sama ng rehiyonal na VNet ay nagbibigay sa kahilingan ng landas patungo sa isang virtual network, at dinadala ito ng site-to-site na VPN mula doon. Lahat ng mali pagkatapos ay tungkol sa kung aling hanay ng pinagmulan at kung aling ruta ang aktwal na ginamit ng packet.

Ano ang aktwal na ipinapadala ng manggagawa

Pinapatakbo ng Serbisyo ng App ang iyong code sa mga manggagawa na nakaupo sa labas ng view ng network ng iyong subscription. Nang pinagana ang rehiyonal na integration, ibibigay ang papalabas na trapiko sa isang itinalagang subnet sa isang VNet sa parehong rehiyon, at lalabas ang packet doon bago ito magpatuloy. Hindi inililipat ng integration ang app sa VNet at hindi binabago ang papasok na address nito. Nagbibigay lamang ito ng mga papalabas na daloy ng ibang first hop.

Bilang default, pribadong address space lang ang dumadaan sa landas na iyon, kaya ang mga ordinaryong destinasyon sa internet ay direktang umaalis pa rin mula sa manggagawa. Ang pagruruta ng lahat sa pamamagitan ng VNet ay isang hiwalay na setting at isang hiwalay na desisyon, dahil ipinapadala din nito ang iyong mga pampublikong dependency sa buong tunnel.

Ang trapiko ng configuration, gaya ng paghatak ng imahe ng container sa startup, ay sumusunod sa sarili nitong mga panuntunan sa pagruruta at maaaring mabigo habang nagtatagumpay ang iyong mga tawag sa API.

Ang subnet ng integrasyon ang pinagmulang dapat mong payagan

Nakikita ng opisina ang hanay ng address ng subnet ng integrasyon, o anuman ang pagsasalin nito ng iyong appliance, hindi ang mga pampublikong papalabas na address ng app. Ilagay ang hanay na iyon sa mga tagapili ng trapiko ng VPN ng site at sa panuntunan sa firewall na nasa nasasakupan. Kung ang tunnel ay nakabatay sa patakaran, mga tagapili na nag-aalis dito ay nag-drop sa packet kahit na may ruta.

Huwag payagan ang isang address ng manggagawa na iyong naobserbahan. Nagbabago ang mga instance sa pag-scale at pagpapanatili ng platform, at ang isang panuntunang naka-pin sa isang address ay masisira sa pinakamasamang sandali.

Panatilihing makitid ang gilid ng patutunguhan: isang serbisyo, isang port, isang direksyon, na tahasang pinapayagan ang daanan sa pagbabalik.

Ang peering at gateway transit ay tahasan

Kung ang VPN gateway ay nasa isang hub na VNet at ang subnet ng integrasyon sa isang spoke, ang path ay nangangailangan ng gateway transit na pinapayagan sa hub peering at remote na paggamit ng gateway na naka-enable sa spoke peering. Ang pagsilip mismo ay nagdadala ng trapiko sa pagitan ng dalawang VNet at wala nang iba pa. Ang mga epektibong ruta sa subnet ng integrasyon ay kung saan mo kinukumpirma na ang gateway next hop ay talagang naroon.

Ang isang hub-and-spoke na disenyo na ang talahanayan ng ruta ay nagpapadala ng 0.0.0.0/0 sa isang firewall ay isang karaniwang variant, at ang firewall na iyon ay nangangailangan ng sarili nitong panuntunan para sa on-premise na prefix.

Iguhit ang landas sa papel bago magbukas ng ticket kasama ang network team, dahil nakakatipid ito ng isang araw ng paghula. Isama ang direksyon sa pagbabalik sa drawing, dahil iyon ang nakakalimutan ng kalahating tao.

Ang papasok na pribadong endpoint ay ang kabilang direksyon

Ang isang pribadong endpoint ay ginagawang maabot ang app mula sa loob ng isang VNet. Wala itong ginagawa para sa papalabas na tawag ng app sa opisina, at ang mga team ay regular na nagko-configure ng isa habang ang aktwal na kinakailangan ay ang kabaligtaran.

Inilalarawan ng mas lumang dokumentasyon ang kinakailangang pagsasama ng gateway na binuo sa point-to-site na VPN, isang kakaibang feature na may sarili nitong mga kinakailangan. Iniiskedyul ng Microsoft ang pagreretiro ng tampok na iyon para sa Marso 31, 2027, at sa halip ay inirerekomenda ang pagsasama-sama ng rehiyon.

Huwag kumopya ng legacy na point-to-site na configuration dahil lang ginamit ito ng isang lumang halimbawa.

I-verify gamit ang sariling konteksto ng app

Pagsubok mula sa naka-deploy na app, hindi mula sa iyong laptop at hindi mula sa isang VM sa parehong VNet. I-log ang nalutas na address, ang resulta ng koneksyon at ang tugon sa antas ng aplikasyon nang hiwalay, dahil isang pagkabigo ng DNS, isang timeout ng TCP at isang punto ng pagtanggi sa pagpapatotoo sa tatlong magkakaibang may-ari. Kung nabigo ang resolution ng pangalan, ayusin ang pribadong DNS para sa VNet bago hawakan ang tunnel.

Ang isang berdeng tunnel status ay nagpapatunay lamang na ang gateway ay nasa itaas. Wala itong sinasabi tungkol sa mga tagapili, panuntunan sa firewall o DNS.

Kapag sa wakas ay gumana ang kahilingan, isulat ang hanay ng pinagmulan, ang destination port at ang DNS zone sa runbook ng app. Ang susunod na taong magde-debug nito ay magsisimula sa iyong tala sa halip na mula sa page ng status ng gateway.