Verificarea fluxului IP din Azure spune permis, dar VPN-ul tot eșuează

Tunelul site-to-site este conectat, VM-ul este sănătos, dar clientul local nu primește nimic. Deschideți Network Watcher, rulați verificarea fluxului IP și aceasta spune Access allowed, așa că tichetul este închis ca problemă de VPN. Rezultatul nu înseamnă ceea ce pare, pentru că verificarea fluxului IP evaluează regulile de securitate pentru fluxul descris și nu testează niciodată dacă Azure are o rută către prefixul dvs. local.

Întrebarea de filtrare și întrebarea de rutare sunt separate, iar Network Watcher le răspunde cu instrumente diferite. Să știți pe care ați pus-o este cea mai mare parte a diagnosticului.

Ce decide de fapt verificarea fluxului IP

Verificarea fluxului IP ia un VM, o interfață de rețea, o direcție, valorile cvintuplului și un protocol, apoi raportează decizia regulii NSG și a administratorului de securitate pentru acel flux. Funcționează pe TCP și UDP, deci nu este un tester de reguli ICMP, iar un ping blocat nu dovedește nimic despre serviciul dvs. Dați-i fluxul real în loc de o presupunere. O conexiune de intrare din mediul local către un port de bază de date este o descriere diferită de o conexiune de ieșire inițiată de VM.

Dacă gateway-ul traduce adrese, folosiți adresa sursă care ajunge la granița pe care o evaluați, nu cea din configurația clientului. Citiți rezultatul și pentru ceea ce este. Access allowed înseamnă că stratul de filtrare ar permite pachetul dacă ar ajunge, și nimic mai mult.

Ce nu poate spune este ruta pe care a ales-o Azure, dacă firewall-ul invitatului permite portul sau dacă ceva ascultă. Acelea trăiesc în alte straturi.

Ce adaugă următorul salt și rutele efective

Următorul salt răspunde la o întrebare de forwarding: pentru această destinație, ce tip de următor salt alege Azure, la ce adresă, din ce tabelă de rute. Rutele efective listează ce are NIC-ul de fapt. Rulați ambele și obțineți calea din partea Azure pe care o verificare verde a fluxului IP o lasă goală.

Prezentarea generală verificării fluxului IP de la Microsoft indică direct domeniul de filtrare, în timp ce paginile despre următorul salt și diagnosticarea rutelor acoperă partea de forwarding. Citați pagina corectă când scrieți constatarea.

Comenzile sunt destul de scurte pentru a fi rulate dintr-un shell. az network nic show-effective-route-table listează rutele aplicate interfeței. az network watcher show-next-hop cu sursă și destinație returnează saltul selectat. Comparați prefixul care vă interesează cu acel tabel, apoi confirmați care intrare câștigă.

Parcurgeți calea de întoarcere din NIC-ul VM-ului

Faceți asta din NIC-ul VM-ului țintă, pentru prefixul clientului local, nu pentru internet. Calea de întoarcere este locul unde se ascund defectele site-to-site, pentru că o verificare a stării tunelului raportează doar că asocierile de securitate sunt active.

Dacă ruta așteptată lipsește, verificați prefixele îndepărtate furnizate de configurația gateway-ului, designul de conectivitate VNet și orice setare de propagare a rutelor. Un obiect de gateway de rețea locală descrie partea locală; existența lui nu dovedește că fiecare prefix necesar este prezent și preferat pe NIC. Sunt fapte diferite, iar doar unul dintre ele apare într-un rezumat al portalului.

Citiți tipul următorului salt în loc să copiați un exemplu

O cale printr-un gateway VPN administrat arată de obicei VirtualNetworkGateway ca tip de următor salt. VirtualAppliance descrie un alt design de forwarding, de obicei un firewall sau un dispozitiv de rețea virtual.

Nu creați o rută de dispozitiv către un endpoint VPN presupus doar pentru că un răspuns vechi de forum folosea acel tip. Dacă o rută definită de utilizator suprascrie calea dorită, găsiți proprietarul și scopul ei înainte de a o schimba. Un al doilea NIC poate schimba și ce interfață folosește invitatul, iar eliminarea lui poate rupe alt serviciu în loc să repare această rută.

Treceți la granița care încă eșuează

Când filtrarea și rutarea corespund ambele designului, defectul este în altă parte. Verificați tabelul de rute al invitatului, firewall-ul acestuia și dacă ascultătorul este legat de adresa așteptată. Apoi verificați selectoarele de trafic protejat ale VPN-ului și calea de răspuns locală. Fiecare dintre ele este un test separat cu un rezultat separat.

Încheiați cu o cerere de aplicație permisă și observații de la ambele capete. Un rezultat allow și un următor salt corect sunt două piese de dovezi, nu dovada că conexiunea a reușit.