De ce adăugarea unui prefix Azure VPN întrerupe conexiunea

Un prefix adăugat la obiectul Azure greșit produce o conexiune care raportează Connected și nu transmite nimic, iar acesta este cel mai scump tip de eroare din acest stack. Sunt implicate trei resurse și doar una dintre ele deține spațiul de adrese de la distanță: gateway-ul de rețea virtuală, gateway-ul de rețea locală care descrie partea îndepărtată și conexiunea care le unește. Prefixul aparține gateway-ului de rețea locală, conexiunea trebuie reconstruită pentru ca modificarea să intre în vigoare, iar gateway-ul în sine rămâne de obicei neatins. Ordinea nu este negociabilă, iar portalul arată doar o parte din ea.

Trei obiecte, dintre care unul ține prefixul

Spațiul de adrese al rețelei virtuale răspunde la o altă întrebare: ce trăiește în interiorul Azure. Adăugarea unui prefix de la distanță acolo nu direcționează traficul către el, doar lărgește spațiul pe care platforma crede că îl deține, ceea ce poate intra în conflict cu intervalul real de la distanță. Gateway-ul de rețea locală este obiectul care ține prefixele de la distanță, iar conexiunea face referire la ambele gateway-uri plus o cheie partajată în prealabil.

Există și o a treia rezervare de reținut. GatewaySubnet găzduiește instanțele gestionate ale gateway-ului, trebuie să poarte exact acel nume, iar pentru SKU-urile care nu sunt Basic se așteaptă să fie cel puțin /27.

Nimic altceva nu aparține acelei subrețele, iar o modificare de prefix nu are niciun motiv să o atingă. Un prefix care lipsește din gateway-ul de rețea locală este inaccesibil indiferent ce spune starea conexiunii, deoarece gateway-ul oferă doar prefixele despre care a fost informat atunci când negociază tunelul. De aceea simptomul este asimetric: tunelul este sus, asocierea de securitate este în regulă și o subrețea nu apare niciodată în selectoarele de trafic. Dacă lipsește un singur interval de la distanță în timp ce vecinii funcționează, nu mai priviți tunelul și citiți gateway-ul de rețea locală.

De ce este eliminată tocmai conexiunea

Obiectul conexiunii fixează configurația negociată pe toată durata sa de viață. De aceea procedura documentată elimină mai întâi conexiunea, actualizează gateway-ul de rețea locală și apoi recreează conexiunea cu aceeași cheie partajată. Instanțele gateway-ului nu sunt reconstruite pentru o modificare doar a prefixului, ceea ce limitează întreruperea la demontarea conexiunii în locul unei reimplementări a gateway-ului.

Această ștergere este întreruperea, așa că tratați-o ca pe o modificare planificată cu început și sfârșit așteptat în loc de o editare rapidă. În PowerShell secvența este scurtă: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, apoi Set-AzLocalNetworkGateway cu noul -AddressPrefix tablou, apoi New-AzVirtualNetworkGatewayConnection cu aceeași -SharedKey și aceleași gateway-uri. Reutilizarea cheii contează, pentru că partea îndepărtată nu este reconfigurată, iar o cheie nouă înseamnă coordonare cu cel care deține dispozitivul de la distanță. Dacă dispozitivul este administrat de altă echipă, conveniți fereastra cu ea înainte de a elimina ceva.

Când trebuie reconstruit gateway-ul în sine

Un al doilea răspuns care circulă în jurul acestei probleme spune că gateway-ul trebuie recreat și cheia schimbată din nou. Acest lucru este corect pentru un alt set de operații: schimbarea tipului de gateway sau a SKU-ului, trecerea între punct-la-site și site-la-site, sau repararea unui gateway a cărui configurație proprie este greșită. Astfel de modificări schimbă într-adevăr resursa gateway, așa că reconstrucția este cu adevărat necesară.

Un gateway creat pentru punct-la-site nu poate primi pur și simplu o conexiune site-la-site. Configurația punct-la-site trebuie eliminată și gateway-ul recreat, ceea ce produce și o cheie partajată nouă și un pachet client nou.

Pachetul punct-la-site merită o notă proprie pentru că expiră. Portalul generează un fișier cu durată scurtă de viață, așa că abordarea practică este să îl descărcați o dată și să îl distribuiți împreună cu certificatul client în loc să trimiteți utilizatorilor un link de portal care va fi mort până când vor face clic. Pentru întrebarea despre prefix, nimic din toate acestea nu se aplică. Păstrarea celor două proceduri separate este toată disciplina: prefixele sunt o modificare la nivelul conexiunii, iar proprietățile gateway-ului sunt o modificare la nivelul gateway-ului.

Citiți starea, nu insigna portalului

Citiți starea din resursă în loc de insigna din portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 returnează ConnectionStatus împreună cu contoare de octeți de intrare și ieșire, iar contoarele sunt cele care separă un tunel conectat care nu transportă nimic de unul care nu s-a stabilit niciodată.

Contoarele care încetează să crească la mijlocul unui transfer indică traseul, nu autentificarea. Contoarele care nu se mișcă deloc indică setul de prefixe sau cheia partajată.

Temporizatoarele explică o clasă de deconectări atribuite greșit VPN-ului. Balansatorul de încărcare al Azure închide fluxurile inactive după timeout-ul configurat, patru minute implicit când au fost scrise aceste note și configurabil în sus, așa că un server OpenVPN pe o VM fără keepalive poate cădea la fiecare câteva minute în timp ce tot restul pare sănătos. Un gateway pe care platforma îl repornește ciclic poate de asemenea întrerupe o conexiune VNet către o Web App, iar acea defecțiune este de partea platformei și nu într-o configurație de client. Indiciul este dacă deconectarea urmează un interval fix sau o modificare pe care ați făcut-o.

Păstrați cele trei obiecte și valorile lor într-o singură înregistrare: spațiul de adrese al rețelei virtuale, lista de prefixe a gateway-ului de rețea locală și referința la cheia partajată a conexiunii. articolul PowerShell pentru site-la-site documentează comenzile gateway-ului de rețea locală și ordinea căreia îi aparțin. Compararea unei modificări de prefix cu memoria este modul în care un tunel funcțional este reconstruit de două ori.

Apoi verificați în ordinea în care ați modificat: gateway-ul de rețea locală arată noua listă de prefixe, conexiunea este din nou Connected, iar contoarele se mișcă atunci când trimiteți trafic către un host din noul interval. Dacă al treilea pas eșuează în timp ce primele două trec, partea îndepărtată nu a acceptat noul selector de trafic și dispozitivul de la distanță are nevoie de intrarea de faza 2 corespunzătoare. Aceasta este o conversație cu celălalt capăt al tunelului, nu o altă modificare în Azure.