Povratni promet Azure P2S VPN-a radi samo u jednom smjeru

Ikona tunela je zelena, NSG izgleda propusno, efektivne rute izgledaju ispravno, a VM ipak ne može otvoriti vezu natrag prema povezanom klijentu. Uobičajena pretpostavka jest 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 pogreška u zaključivanju, ne u konfiguraciji. Tunel može nositi jedan smjer neželjenog toka i odbacivati drugi, a popravak ovisi o tome koji ga sloj odbacuje.

Mit: povezan tunel je dvosmjerni tunel

VPN tunel je putanja politike, ne žica. Svaki se smjer uspoređuje sa selektorima, rutama i filtrima, i bilo koji od njih može dopustiti jedan smjer dok blokira drugi.

U praksi je asimetrija dovoljno česta da smjer pripada prvom testu, a ne posljednjem. Klijent inicira, pristupnik prati tok, a odgovor slijedi stanje koje je stvoreno. VM koja započinje novi tok nema takvo stanje, pa ovisi o tome da povratna putanja bude izričito rutabilna i dopuštena. Kada ta putanja 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 zabilježite i to. Ako prvi uspije, a drugi ne, pool klijenata, pridruživanje pristupnika i putanja od klijenta do VNet-a sve rade.

Sljedeći su korak 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 promet. Zahtjev koji stigne bez odgovora problem je filtra ili povratne rute; zahtjev koji nikad ne stigne problem je putanje. Ne uzimajte neuspjeli ping kao dokaz da je VM nedostupan, jer ICMP politika može odbaciti odgovor dok TCP radi.

Povratna putanja IKEv2 point-to-site uobičajeni je osumnjičenik

U Azure izvješću na kojem se temelji ovaj članak, klijent je mogao doći do VM-ova preko IKEv2, ali je dolazni ICMP od VM-a prema klijentu padao sve dok vrsta tunela pristupnika nije prebačena na OpenVPN. Autor izvješća navodi da je Microsoft potvrdio ograničenje u putanji IKEv2 point-to-site, gdje se povratni promet od VM-a prema klijentu ne usmjerava simetrično osim ako je klijent započeo sesiju. IKEv2 se oslanja na selektore prometa, a pristupnik u tom slučaju nije poštovao povratni smjer.

To ne čini OpenVPN općenito boljom vrstom tunela. To čini vrstu tunela varijablom u testnoj matrici za ovo radno opterećenje.

Promjena vrste tunela je promjena usluge, ne prekidač. Svakom klijentu treba kompatibilan profil, a pristupniku može trebati drugačiji certifikat ili postavka autentifikacije. Reproducirajte jednosmjerno ponašanje s jednim testnim klijentom i jednim testnim VM-om, promijenite vrstu prema odobrenom rasporedu, a zatim ponovite iste testove smjera. Ako ponašanje preživi promjenu, vrsta tunela nije bila 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 promet, 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 pregledavanja 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 izričitim popisom partnera. Ako aplikacija nema unicast alternativu, dizajnu treba drugačiji mehanizam otkrivanja, a ne širi tunel.

Što promijeniti i kako to dokazati

Ako test smjera pada samo na IKEv2, zabilježite vrstu tunela pristupnika, pool adresa klijenata i točan ICMP ili TCP test, zatim procijenite odobreni OpenVPN profil za pogođene klijente. Ako pada na svakoj vrsti tunela, radite na povratnoj putanji: adresa klijenta mora biti rutabilna iz podmreže VM-a, svaka korisnički definirana ruta mora pokazivati na valjani sljedeći skok, a vatrozid klijenta mora prihvatiti 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, njezinoj 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.