Cum ajunge o aplicație web Azure la sediu printr-un VPN

Solicitarea de ieșire a aplicației web lasă un lucrător pe care nu-l vedeți niciodată, dintr-o sursă pe care nu ați ales-o, iar firewall-ul de birou trebuie să o accepte. Aceasta este toată problema într-o singură propoziție. Integrarea VNet regională oferă cererii o cale către o rețea virtuală, iar VPN-ul de la site la site o transportă de acolo. Tot ce merge prost după aceea se referă la intervalul de sursă și la ce rută a folosit efectiv pachetul.

Ce trimite efectiv lucrătorul

App Service rulează codul dvs. pe lucrătorii care se află în afara vizualizării rețelei abonamentului dvs. Cu integrarea regională activată, traficul de ieșire este transmis unei subrețele delegate într-o rețea virtuală din aceeași regiune, iar pachetul apare acolo înainte de a continua. Integrarea nu mută aplicația în rețeaua virtuală și nu îi schimbă adresa de intrare. Oferă doar fluxurilor de ieșire un prim hop diferit.

În mod prestabilit, numai spațiul de adresă privată ia această cale, așa că destinațiile obișnuite de internet pleacă în continuare direct de la lucrător. Rutarea totul prin rețeaua virtuală este o setare separată și o decizie separată, deoarece trimite, de asemenea, dependențele dvs. publice peste tunel.

Traficul de configurare, cum ar fi extragerea unei imagini de container la pornire, urmează propriile reguli de rutare și poate eșua în timp ce apelurile dvs. API reușesc.

Subrețeaua de integrare este sursa pe care trebuie să o permiteți

Biroul vede intervalul de adrese a subrețelei de integrare sau orice în care dispozitivul dvs. îl traduce, nu adresele publice de ieșire ale aplicației. Introduceți intervalul respectiv în selectoarele de trafic ale VPN-ului site-ului și în regula firewall-ului local. Dacă tunelul este bazat pe politici, selectorii care îl omit aruncă pachetul chiar și atunci când există o rută.

Nu permiteți nicio adresă de lucrător pe care ați observat-o. Instanțele se schimbă odată cu scalarea și întreținerea platformei, iar o regulă fixată pe o singură adresă se întrerupe în cel mai rău moment.

Păstrați partea de destinație îngustă: un serviciu, un port, o direcție, cu calea de întoarcere permisă în mod explicit.

Peering-ul și tranzitul gateway sunt explicite

Dacă gateway-ul VPN se află într-o rețea virtuală hub și subrețeaua de integrare într-o spiță, calea trebuie permisă tranzitul gateway-ului pe peering-ul hub și utilizarea gateway-ului de la distanță activată pe peering-ul spoke. Peeringul în sine transportă trafic între cele două rețele virtuale și nimic mai mult. Rutele eficiente de pe subrețeaua de integrare sunt acolo unde confirmați că gateway-ul următor hop este într-adevăr acolo.

Un design hub-and-spoke al cărui tabel de rute trimite 0.0.0.0/0 la un firewall este o variantă comună, iar acel firewall are nevoie de propria sa regulă pentru prefixul local.

Desenați calea pe hârtie înainte de a deschide un bilet cu echipa de rețea, deoarece economisește o zi de ghicire. Includeți direcția de întoarcere în desen, deoarece aceasta este jumătatea pe care oamenii o uită.

Punctul final privat de intrare este cealaltă direcție

Un punct final privat face ca aplicația să fie accesibilă din interiorul unei rețele virtuale. Nu face nimic pentru apelul de ieșire al aplicației către birou, iar echipele configurează în mod regulat unul, în timp ce cerința reală era inversă.

Documentația mai veche descrie integrarea necesară pentru gateway construită pe VPN punct-la-site, o caracteristică diferită cu propriile cerințe. Microsoft programează retragerea acestei caracteristici pentru 31 martie 2027 și recomandă integrarea regională în schimb.

Nu copiați o configurație moștenită punct-la-site doar pentru că a folosit-o un exemplu vechi.

Verificați cu propriul context al aplicației

Testați din aplicația implementată, nu de pe laptop și nu de pe o VM din aceeași rețea virtuală. Înregistrați separat adresa rezolvată, rezultatul conexiunii și răspunsul la nivel de aplicație, deoarece o eroare DNS, un timeout TCP și un punct de respingere a autentificării la trei proprietari diferiți. Dacă rezoluția numelui eșuează, remediați DNS privat pentru rețeaua virtuală înainte de a atinge tunelul.

O stare de tunel verde dovedește doar că poarta de acces este activată. Nu spune nimic despre selectoare, reguli de firewall sau DNS.

Când solicitarea funcționează în sfârșit, scrieți intervalul sursă, portul de destinație și zona DNS în runbook-ul aplicației. Următoarea persoană care va depana acest lucru va începe din nota dvs., nu de pe pagina de stare a gateway-ului.