Are un Azure VNet conectat prin peering nevoie de propria poartă VPN?

Apare un VNet spoke nou, hub-ul are deja o poartă site-to-site funcțională, iar întrebarea evidentă este dacă trebuie să plătiți pentru o a doua poartă. De obicei nu: tranzitul porții permite spoke-ului să folosească poarta hub-ului prin peering. Trei condiții decid dacă acest lucru va funcționa și niciuna nu este vizibilă pe insigna de stare a peering-ului. Conectivitatea peering-ului și permisiunea de a folosi poarta altcuiva sunt setări separate, așa că două VM care se pot deja pinga nu demonstrează nimic despre calea VPN.

Prima condiție: poarta și lipsa uneia în spoke

Azure acceptă tranzitul porții pentru SKU-uri VPN Gateway altele decât Basic, iar atât peering-ul regional, cât și cel global îl pot transporta. Spoke-ul consumă o poartă care nu îi aparține, deci nu poate avea una proprie: dacă în spoke există deja o poartă sau este deja selectată o opțiune de poartă la distanță, setarea de tranzit dorită va fi indisponibilă sau ineficientă. Verificați acest lucru înainte de a depana ceva, pentru că bifa dezactivată este simptomul, nu defectul. Citiți mai întâi SKU-ul și poarta existentă, apoi uitați-vă la setările de peering.

Nu ștergeți o poartă spoke existentă pentru a face opțiunea să apară până când nu știți de ce depinde. Ordinea migrării contează mai mult decât bifa.

A doua condiție: o setare în fiecare direcție de peering

Un peering înseamnă două obiecte, câte unul pe fiecare VNet, iar setările de tranzit se află pe laturi diferite ale acelei perechi. Peering-ul hub-ului spre spoke trebuie să permită porții hub-ului să deservească spoke-ul; peering-ul spoke-ului spre hub trebuie să accepte poarta hub-ului. ghidul de tranzit al porții de la Microsoft le numește pe direcție, iar aceasta este singura modalitate de a le ține corecte:

Un control etichetat remote își schimbă sensul în funcție de peering-ul cărui VNet îl editați, așa că citiți direcția, nu cuvântul. Setați ambele părți, salvați și confirmați că peering-ul raportează conectarea în ambele locuri.

A treia condiție: spațiul de adrese și limitele permisiunilor

Tranzitul nu poate face ca același prefix de destinație să însemne două rețele, așa că intervalele hub-ului, ale spoke-ului și ale rețelei locale trebuie să fie disjuncte înainte ca ceva din toate acestea să funcționeze. VNet-urile pot fi și în abonamente diferite sau în chiriași diferiți; aceasta nu este o interdicție, dar identitatea care creează sau actualizează fiecare peering are nevoie de permisiunile necesare pe acea rețea. Modificările între abonamente eșuează adesea din cauza permisiunilor, iar eroarea este ușor de citit greșit ca o problemă de topologie.

Notați intervalele și proprietarii înainte de modificare. Ghicirea oricăruia dintre ele produce un peering care se conectează și nu rutează nimic.

Verificați cu rute efective, nu cu starea peering-ului

Uitați-vă la rutele efective de pe interfața de rețea a unei încărcări de lucru din spoke și găsiți prefixul local real. Verificați tabelul de rute al subrețelei și dacă propagarea rutelor porții este dezactivată, deoarece o rută definită de utilizator sau un dispozitiv de inspecție poate suprascrie calea sugerată de marcajele peering-ului. Apoi confirmați direcția opusă: rețeaua locală trebuie să știe cum să ajungă la prefixul spoke-ului prin conexiunea site-to-site, fie prin anunțuri învățate, fie printr-o rută explicită și o intrare de rețea protejată corespunzătoare pe dispozitivul clientului. Dacă prefixul lipsește pe oricare dintre laturi, marcajele peering-ului nu sunt ceea ce trebuie schimbat.

Testați un serviciu dintr-o încărcare de lucru din spoke și urmăriți răspunsul. Un test de la poarta VPN sau de la un VM din hub exercită un alt prefix sursă și o altă cale.

Dacă topologia deservește și clienți punct-la-site, validați separat rutele lor instalate. Pachetele clientului Windows pot necesita regenerare după o modificare de topologie, iar aceasta este o sarcină de rutare pe partea clientului, nu o dovadă că partajarea porții a eșuat.

Ce nu acordă partajarea unei porți

Tranzitul porții este o comoditate de rutare, nu o autorizare. Grupurile de securitate a rețelei, filtrele locale și regulile la nivel de serviciu decid în continuare la ce poate ajunge o încărcare de lucru din spoke, așa că activați serviciul concret de la sursă la destinație în loc să presupuneți că tunelul partajat permite tot ce se află în spatele lui.

Peering-ul nu este nici tranzitiv așa cum speră oamenii. Adăugarea unui alt spoke, sau a unui endpoint privat, introduce propriile cerințe de rutare și acces pe care setarea de tranzit existentă nu le acoperă.