Povratni saobraćaj Azure P2S VPN-a radi samo u jednom smjeru

Ikona tunela je zelena, NSG izgleda propusno, efektivne rute izgledaju ispravno, a VM i dalje ne može otvoriti vezu natrag prema povezanom klijentu. Uobičajena pretpostavka je da je ispravan point-to-site tunel simetričan: ako klijent može doći do VM-a, i VM može doći do klijenta. Ta pretpostavka je greška u zaključivanju, ne u konfiguraciji. Tunel može nositi jedan smjer neželjenog toka i odbacivati drugi, a popravka zavisi od toga koji sloj ga odbacuje.

Mit: povezan tunel je dvosmjerni tunel

VPN tunel je staza politike, ne žica. Svaki smjer se upoređuje sa selektorima, rutama i filterima, i bilo koji od njih može dozvoliti jedan smjer dok blokira drugi.

U praksi je asimetrija dovoljno česta da smjer pripada prvom testu, a ne posljednjem. Klijent inicira, gateway prati tok, a odgovor slijedi stanje koje je stvoreno. VM koja započinje novi tok nema takvo stanje, pa zavisi od toga da povratna staza bude eksplicitno rutabilna i dozvoljena. Kada ta staza nedostaje, pokušaj veze umire prije nego što ga bilo koja aplikacija vidi.

Testirajte smjer prije nego što testirate dostupnost

Odaberite jednu adresu klijenta, jednu adresu VM-a i jedan protokol. Povežite se s klijenta i zabilježite rezultat; zatim pokrenite isti test s VM-a i i to zabilježite. Ako prvi uspije, a drugi ne, pool klijenata, pridruživanje gatewaya i staza od klijenta do VNet-a sve rade.

Sljedeći korak su dokazi, a ne još pravila. Provjerite NSG na podmreži VM-a u oba smjera, pročitajte efektivne rute na NIC-u VM-a i snimite pakete na VM-u dok klijent šalje saobraćaj. Zahtjev koji stigne bez odgovora problem je filtera ili povratne rute; zahtjev koji nikad ne stigne problem je staze. Ne uzimajte neuspjeli ping kao dokaz da je VM nedostupan, jer ICMP politika može odbaciti odgovor dok TCP radi.

Povratna staza IKEv2 point-to-site je uobičajeni osumnjičeni

U Azure izvještaju na kojem se zasniva ovaj članak, klijent je mogao doći do VM-ova preko IKEv2, ali je dolazni ICMP od VM-a prema klijentu padao sve dok tip tunela gatewaya nije prebačen na OpenVPN. Autor izvještaja navodi da je Microsoft potvrdio ograničenje u IKEv2 point-to-site stazi, gdje se povratni saobraćaj od VM-a prema klijentu ne rutira simetrično osim ako je klijent započeo sesiju. IKEv2 se oslanja na selektore saobraćaja, a gateway u tom slučaju nije poštovao povratni smjer.

To ne čini OpenVPN boljim tipom tunela općenito. To čini tip tunela promjenljivom u testnoj matrici za ovo radno opterećenje.

Promjena tipa tunela je promjena usluge, ne prekidač. Svakom klijentu treba kompatibilan profil, a gatewayu može trebati drugačiji certifikat ili postavka autentifikacije. Reproducirajte jednosmjerno ponašanje s jednim testnim klijentom i jednim testnim VM-om, promijenite tip po odobrenom rasporedu, a zatim ponovite iste testove smjera. Ako ponašanje preživi promjenu, tip tunela nije bio uzrok i suzili ste problem bez diranja produkcije.

Mit: broadcast otkrivanje prelazi granicu VNet-a

Druga pretpostavka pada iz nepovezanog razloga. Azure virtualna mreža ne prenosi broadcast saobraćaj, pa VM ne može primati broadcast okvire iz lokalne mreže preko site-to-site ili point-to-site veze. Aplikacije koje pronalaze partnere putem broadcasta, poput starijeg pregledanja datoteka ili nekih protokola za otkrivanje uređaja, nikada neće vidjeti udaljenu stranu, kako god rute bile napisane.

Zamijenite broadcast otkrivanje DNS imenima, uslugom imenika ili eksplicitnom listom partnera. Ako aplikacija nema unicast alternativu, dizajnu treba drugačiji mehanizam otkrivanja, a ne širi tunel.

Šta promijeniti i kako to dokazati

Ako test smjera pada samo na IKEv2, zabilježite tip tunela gatewaya, pool adresa klijenata i tačan ICMP ili TCP test, zatim procijenite odobreni OpenVPN profil za pogođene klijente. Ako pada na svakom tipu tunela, radite na povratnoj stazi: adresa klijenta mora biti rutabilna iz podmreže VM-a, svaka korisnički definirana ruta mora pokazivati na valjani sljedeći hop, a firewall klijenta mora prihvatati dolazni tok. Priložite dokaze NSG-a i ruta uz tiket.

Provjeravajte aplikacijom, ne pingom. Uspješna ICMP razmjena nakon promjene ne govori ništa o portu usluge, njegovoj autentifikaciji ili razrješavanju imena. Ponovite test nakon ponovnog povezivanja, jer klijent koji dobije drugu adresu iz poola može promijeniti rezultat. Zatim ga ponovite još jednom nakon što klijent zaspi i probudi se, jer se u obnovljenoj sesiji jednosmjerno ponašanje često vraća.