Peering în Azure sau VPN de la VNet la VNet? Decide înainte de rutare

Azure vă oferă cel puțin două moduri de a conecta două rețele virtuale, iar acestea nu sunt setări interschimbabile pe același obiect. Peering-ul unește VNet-urile pe coloana vertebrală a Microsoft fără gateway; un VPN de la VNet la VNet pune o relație IPsec între două gateway-uri pe care le implementați, le dimensionați și le monitorizați. Decizia se reduce la trei condiții, iar dacă nu puteți răspunde tuturor trei înainte de a adăuga o rută, sunteți pe punctul de a construi un ocol pentru un model pe care nu l-ați ales niciodată.

Trei condiții care decid modelul

Prima este dacă ceva din cerință are nevoie de o frontieră IPsec care vă aparține și pe care puteți indica. A doua este dacă spațiile de adresare sunt curate și cele două VNet-uri trebuie doar să vorbească între ele. A treia este cine deține orice cale tranzitivă și factura gateway-ului. Răspundeți în această ordine, pentru că prima poate elimina peering-ul oricât de atrăgătoare ar părea a doua.

Ceea ce au în comun ambele modele este o regulă strictă de adresare: spațiile de adresare ale VNet-urilor nu trebuie să se suprapună. Nici peering-ul, nici un VPN de la VNet la VNet nu sunt o modalitate acceptată de a face două intervale identice neambigue, iar o suprapunere cere un proiect de mapare sau o reproiectare, nu alt tip de conexiune.

Condiția 1: aveți nevoie de o frontieră IPsec care vă aparține?

Peering-ul transportă traficul pe coloana vertebrală privată a Azure și nu necesită un gateway VPN pentru conexiunea peered în sine. Aceasta este o afirmație despre transport, nu o afirmație despre criptare pe care să o dați unui auditor ca «rulăm IPsec». Dacă cerința numește un tunel configurat de client, o politică IKE anume sau o frontieră care se termină pe echipament pe care îl controlați, peering-ul nu o satisface, oricât de privată ar fi coloana vertebrală.

Un VPN de la VNet la VNet oferă acea frontieră: două gateway-uri, o relație IPsec/IKE, chei partajate și întreaga suprafață operațională care vine cu ele. Moșteniți starea tunelului, capacitatea gateway-ului, limitele SKU și monitorizarea care dovedește că tunelul este activ. Acesta este răspunsul corect atunci când cerința se referă exact la acea frontieră, descrisă în prezentarea generală a peering-ului ca un tip de conexiune distinct.

Fiți la fel de atent în direcția opusă. «Avem nevoie de criptare între VNet-uri» este adesea satisfăcut de TLS-ul propriu al sarcinii de lucru, iar atunci un gateway este un cost fără cerință în spate. Scrieți propoziția pe care o va citi auditorul înainte de a alege mecanismul.

Condiția 2: topologia este directă sau ceva trebuie să tranziteze?

Peering-ul nu este tranzitiv. Două VNet-uri peered la un hub nu sunt prin asta conectate între ele, iar o rută care pare să funcționeze într-o direcție este de obicei un peering care a atins Connected doar pe o parte. Ambele părți trebuie să existe și ambele trebuie să arate Connected, iar acesta este primul lucru pe care îl verificați când traficul dispare în tăcere.

Dacă cerința este accesul la rețeaua locală printr-un hub, tranzitul gateway-ului este un proiect separat cu roluri specifice: hub-ul deține gateway-ul, peering-ul spoke permite tranzitul gateway-ului, iar spoke trebuie să permită traficul redirecționat. Acestea sunt proprietăți ale peering-ului, nu consecințe automate ale conectării VNet-urilor:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Tabelul de rute efectiv este răspunsul onest la «există calea?». Arată tipul următorului salt pe care platforma îl va folosi efectiv, așa că un peering care pare configurat dar nu este conectat apare ca o rută lipsă sau greșită, nu ca un mister.

Condiția 3: cine deține calea tranzitivă și factura?

Fiecare salt suplimentar are un proprietar. Cu peering, un VNet nou înseamnă o nouă pereche de peering pe ambele părți și, pentru tranzit, un hub care continuă să redirecționeze trafic și un tabel de rute care continuă să indice spre el. Cu un VPN, un VNet nou înseamnă un alt gateway sau o altă conexiune pe unul existent, cu propriul plafon de capacitate de urmărit.

Costul urmează aceeași formă, dar nu aceleași poziții: tarifele de peering sunt conexiune și transfer de date, în timp ce un VPN adaugă ore de gateway și propriile tarife de transfer. Comparați totalul pentru topologia pe care o veți rula efectiv un an, inclusiv al doilea tunel și monitorizarea, nu prețul unei conexiuni astăzi. Includeți munca pe care nimeni nu o facturează: cineva trebuie să rotească cheile, să urmărească starea tunelului și să răspundă la alertă la trei dimineața când un gateway repornește. Acea poziție decide de obicei dezbaterea, pentru că este singura care nu apare niciodată într-o ofertă.

Orice ați alege, testați trei fluxuri: cel dorit, unul refuzat care trebuie să rămână refuzat și cazul de recuperare în care gateway-ul hub-ului sau un peering este căzut. Un model care explică doar calea fericită nu a fost verificat, a fost demonstrat.

Verificați alegerea față de propria afirmație

Scrieți o propoziție care numește modelul, frontiera și proprietarul, apoi verificați că starea implementată îi corespunde. Pentru peering aceasta înseamnă ambele stări de peering Connected, ruta efectivă arătând următorul salt de peering pentru prefixul destinație și niciun gateway pe cale. Pentru un VPN de la VNet la VNet înseamnă ambele conexiuni Connected, chei și politici potrivite pe ambele gateway-uri și o rută al cărei următor salt este gateway-ul de rețea virtuală.

Dacă verificările contrazic propoziția, corectați mai întâi propoziția. Cea mai mare parte a confuziei în aceste proiecte vine dintr-un hibrid pe care nimeni nu l-a descris: un peering pentru subrețeaua sarcinii de lucru, un VPN pentru un serviciu vechi și un tabel de rute care preferă în tăcere unul dintre ele.