VPN de la site la site în Azure cu un partener în spatele NAT: listă de verificare

Faceți aceste verificări în ordine și opriți-vă la prima care eșuează. Majoritatea rapoartelor că Azure nu acceptă un dispozitiv în spatele NAT se dovedesc a fi o adresă de partener la care Azure nu ajunge, sau un tunel care nu pornește niciodată din partea corectă. Transportul exterior și rutarea interioară sunt două probleme diferite, iar amestecarea lor costă o după-amiază. Fiecare pas de mai jos produce o observație pe care o puteți preda altcuiva.

Pasul 1: confirmați că partenerul este într-adevăr în spatele NAT

Comparați adresa de pe interfața WAN a dispozitivului cu adresa pe care Azure o vede pentru el. Dacă diferă, ceva traduce, iar acel traducător face acum parte din designul dumneavoastră VPN. Întrebați furnizorul dacă maparea este statică sau partajată, deoarece o mapare partajată schimbă ceea ce puteți presupune. Un dispozitiv cu adresă WAN privată și fără redirecționare este un caz diferit de unul aflat în spatele unui NAT de nivel de operator cu o mapare publică stabilă.

Dacă cele două adrese coincid, opriți-vă aici: NAT nu este problema dumneavoastră, iar restul listei nu va ajuta.

Notați ambele adrese și modelul traducătorului în tichet. Acea singură linie evită următoarea rundă de întrebări despre de ce partenerul configurat nu răspunde.

Pasul 2: stabiliți cine inițiază

Întrebările frecvente despre Azure VPN Gateway menționează suportul NAT-T și adaugă că dispozitivul local ar trebui să inițieze tunelul IPsec atunci când se află în spatele NAT. Aceasta corespunde modului în care funcționează traducerea cu stare, deoarece traducătorul păstrează o mapare pentru că dispozitivul interior a trimis primul pachet. Dacă se așteaptă ca Azure să inițieze și nu sosește nimic care să creeze acea mapare, tunelul nu pornește niciodată.

Configurați partenerul astfel încât o eroare de tip doar-răspuns să fie evidentă, și verificați dacă dispozitivul reîncearcă singur sau are nevoie de un declanșator. Unele dispozitive ridică un tunel doar când apare trafic interesant, ceea ce este în regulă până când traficul interesant este o sondă de stare care nu vine niciodată.

Urmăriți schimbul IKE pe dispozitiv în timpul unei inițieri manuale; liniștea de acolo este un răspuns de rutare sau de firewall, nu un răspuns al Azure.

Pasul 3: stabiliți corect adresa partenerului

Azure are nevoie de o adresă publică accesibilă pentru partener în obiectul de gateway de rețea locală, de obicei adresa publică a traducătorului, nu adresa interioară a dispozitivului. Identitatea cu care se autentifică dispozitivul este un câmp separat și poate diferi în mod legitim de adresa la care apelează Azure. Țineți-le separate, deoarece schimbarea lor produce o eroare de autentificare care arată exact ca o problemă NAT.

Dacă adresa publică se schimbă, acel obiect trebuie să se schimbe odată cu ea. Un nume care se rezolvă la o adresă învechită este mai rău decât o adresă statică pe care trebuie să o actualizați manual.

Notați toate trei valorile: adresa locală a dispozitivului, adresa publică tradusă și identitatea partenerului configurată.

Pasul 4: deschideți doar porturile de care are nevoie NAT-T

NAT-T transportă ESP în interiorul UDP, iar RFC 3948 descrie acea încapsulare cu portul 4500 folosit după negocierea inițială pe portul 500. Firewall-ul dumneavoastră și traducătorul trebuie ambele să permită schimbul și traficul său de retur. Permiterea unui port TCP nelegat nu dovedește nimic despre această cale, iar o regulă care permite ieșirea dar nu răspunsul va eșua în continuare.

Redirecționarea statică a unui port de intrare nu este necesară automat când partenerul inițiază și traducătorul păstrează stare. Devine necesară când maparea este instabilă sau când ceva de pe cale expiră agresiv starea.

Capturați o dată pe ambele părți ale traducătorului; diferența de încapsulare este vizibilă imediat.

Pasul 5: separați transportul exterior de rutarea interioară

Un tunel care se stabilește și nu transportă nimic este o problemă de rutare, nu de NAT-T. Site-urile au în continuare nevoie de selectori de trafic compatibili, spații de adrese potrivite, reguli de acces și o cale de retur pentru rețelele aplicațiilor. Nimic din toate acestea nu este oferit de un schimb IKE reușit.

Dacă cele două site-uri folosesc intervale private suprapuse, traducerea în interiorul tunelului este un design separat cu regulile sale. Nu renumerotați o subrețea doar pentru că gateway-ul exterior se află întâmplător în spatele unui router de acasă.

Clasificați defecțiunea după etapă înainte de a schimba ceva, și păstrați această clasificare în tichet, astfel încât următoarea persoană să înceapă de unde v-ați oprit.