Traficul de retur al Azure P2S VPN funcționează doar într-o singură direcție

Pictograma tunelului este verde, NSG pare permisiv, rutele efective par corecte și totuși VM-ul nu poate deschide o conexiune înapoi către clientul conectat. Presupunerea obișnuită este că un tunel point-to-site funcțional este simetric: dacă clientul ajunge la VM, VM-ul ajunge la client. Acea presupunere este eroarea de raționament, nu de configurare. Un tunel poate transporta o direcție a unui flux nesolicitat și o poate elimina pe cealaltă, iar remedierea depinde de nivelul care o elimină.

Mit: un tunel conectat este un tunel bidirecțional

Un tunel VPN este o cale de politică, nu un cablu. Fiecare direcție este comparată cu selectori, rute și filtre, iar oricare dintre ele poate permite o direcție blocând-o pe cealaltă.

În practică asimetria este suficient de frecventă încât direcția să facă parte din primul test, nu din ultimul. Clientul inițiază, gateway-ul urmărește fluxul, iar răspunsul urmează starea care a fost creată. Un VM care începe un flux nou nu are o astfel de stare, așa că depinde de faptul că ruta de retur este explicit rutabilă și permisă. Când acea rută lipsește, încercarea de conexiune moare înainte ca vreo aplicație să o vadă.

Testați direcția înainte de a testa accesibilitatea

Alegeți o adresă de client, o adresă de VM și un protocol. Conectați-vă din client și notați rezultatul; apoi porniți același test din VM și notați-l și pe acela. Dacă primul reușește și al doilea eșuează, pool-ul de clienți, asocierea gateway-ului și ruta de la client la VNet funcționează toate.

Următorul pas sunt dovezile, nu mai multe reguli. Verificați NSG-ul din subnetul VM-ului în ambele direcții, citiți rutele efective pe NIC-ul VM-ului și capturați pachete pe VM în timp ce clientul trimite trafic. O cerere care sosește fără răspuns este o problemă de filtru sau de rută de retur; o cerere care nu sosește niciodată este o problemă de cale. Nu tratați un ping eșuat ca dovadă că VM-ul este inaccesibil, deoarece politica ICMP poate elimina răspunsul în timp ce TCP funcționează.

Ruta de retur IKEv2 point-to-site este suspectul obișnuit

În raportul Azure din spatele acestui articol, un client putea ajunge la VM-uri prin IKEv2, dar ICMP-ul de intrare de la VM la client eșua până când tipul de tunel al gateway-ului a fost comutat pe OpenVPN. Autorul raportului susține că Microsoft a confirmat o limitare în ruta IKEv2 point-to-site, unde traficul de retur de la un VM la client nu este rutat simetric decât dacă clientul a inițiat sesiunea. IKEv2 se bazează pe selectori de trafic, iar gateway-ul nu a respectat direcția de retur în acel caz.

Asta nu face din OpenVPN tipul de tunel mai bun în general. Face din tipul de tunel o variabilă în matricea de test pentru această încărcare de lucru.

Schimbarea tipului de tunel este o modificare de serviciu, nu un comutator. Fiecare client are nevoie de un profil compatibil, iar gateway-ul poate avea nevoie de un certificat sau de o configurație de autentificare diferite. Reproduceți comportamentul unidirecțional cu un client de test și un VM de test, schimbați tipul conform unui calendar aprobat și apoi repetați aceleași teste de direcție. Dacă comportamentul supraviețuiește schimbării, tipul de tunel nu a fost cauza și ați restrâns problema fără a atinge producția.

Mit: descoperirea prin broadcast traversează marginea VNet-ului

O a doua presupunere eșuează dintr-un motiv nelegat. O rețea virtuală Azure nu transportă trafic broadcast, așa că un VM nu poate primi cadre broadcast dintr-o rețea locală printr-o conexiune site-to-site sau point-to-site. Aplicațiile care găsesc parteneri prin broadcast, cum ar fi navigarea veche prin fișiere sau unele protocoale de descoperire a dispozitivelor, nu vor vedea niciodată partea îndepărtată, indiferent cum sunt scrise rutele.

Înlocuiți descoperirea prin broadcast cu nume DNS, un serviciu de director sau o listă explicită de parteneri. Dacă aplicația nu are alternativă unicast, designul are nevoie de un alt mecanism de descoperire, nu de un tunel mai larg.

Ce trebuie schimbat și cum se demonstrează

Dacă testul de direcție eșuează doar pe IKEv2, notați tipul de tunel al gateway-ului, pool-ul de adrese de clienți și testul ICMP sau TCP exact, apoi evaluați un profil OpenVPN aprobat pentru clienții afectați. Dacă eșuează pe orice tip de tunel, lucrați ruta de retur: adresa clientului trebuie să fie rutabilă din subnetul VM-ului, orice rută definită de utilizator trebuie să indice un următor hop valid, iar firewall-ul clientului trebuie să accepte fluxul de intrare. Atașați dovezile NSG și ale rutelor la tichet.

Verificați cu aplicația, nu cu ping. Un schimb ICMP reușit după o modificare nu spune nimic despre portul serviciului, autentificarea acestuia sau rezolvarea numelor. Repetați testul după o reconectare, deoarece un client care primește o altă adresă din pool poate schimba rezultatul. Apoi repetați-l încă o dată după ce clientul adoarme și se trezește, deoarece într-o sesiune reluată comportamentul unidirecțional reapare adesea.