Zpětný provoz Azure P2S VPN funguje jen jedním směrem

Ikona tunelu je zelená, NSG vypadá povolující, efektivní trasy vypadají správně, a přesto VM nemůže otevřít připojení zpět k připojenému klientovi. Obvyklý předpoklad je, že funkční point-to-site tunel je symetrický: když se klient dostane k VM, dostane se VM i ke klientovi. Tento předpoklad je chyba v uvažování, ne v konfiguraci. Tunel může nést jeden směr nevyžádaného toku a druhý zahazovat a oprava závisí na tom, která vrstva ho zahazuje.

Mýtus: připojený tunel je obousměrný tunel

VPN tunel je cesta politiky, ne drát. Každý směr se porovnává se selektory, trasami a filtry a kterýkoli z nich může povolit jeden směr a zablokovat druhý.

V praxi je asymetrie dost častá na to, aby směr patřil do prvního testu, ne do posledního. Klient inicializuje, brána sleduje tok a odpověď následuje stav, který vznikl. VM, která zahajuje nový tok, takový stav nemá, takže závisí na tom, aby zpětná cesta byla výslovně směrovatelná a povolená. Když tato cesta chybí, pokus o připojení umře dřív, než ho nějaká aplikace uvidí.

Otestujte směr dřív, než otestujete dostupnost

Vyberte jednu adresu klienta, jednu adresu VM a jeden protokol. Připojte se z klienta a zaznamenejte výsledek; pak spusťte stejný test z VM a také ho zaznamenejte. Pokud první uspěje a druhý selže, pool klientů, přidružení brány i cesta z klienta do VNetu fungují.

Dalším krokem jsou důkazy, ne další pravidla. Zkontrolujte NSG v podsíti VM v obou směrech, přečtěte efektivní trasy na NIC VM a zachyťte pakety na VM, zatímco klient posílá provoz. Požadavek, který dorazí bez odpovědi, je problém filtru nebo zpětné trasy; požadavek, který nedorazí vůbec, je problém cesty. Neberte neúspěšný ping jako důkaz, že VM je nedostupná, protože politika ICMP může zahodit odpověď, i když TCP funguje.

Zpětná cesta IKEv2 point-to-site je obvyklý podezřelý

Ve zprávě Azure, na níž je tento článek založen, se klient dostal k VM přes IKEv2, ale příchozí ICMP z VM ke klientovi selhávalo, dokud nebyl typ tunelu brány přepnut na OpenVPN. Autor zprávy uvádí, že Microsoft potvrdil omezení v cestě IKEv2 point-to-site, kde se zpětný provoz z VM ke klientovi nesměruje symetricky, pokud relaci nezahájil klient. IKEv2 se spoléhá na selektory provozu a brána v tom případě zpětný směr nerespektovala.

To nedělá z OpenVPN obecně lepší typ tunelu. Dělá to z typu tunelu proměnnou v testovací matici pro tuto zátěž.

Přepnutí typu tunelu je změna služby, ne přepínač. Každý klient potřebuje kompatibilní profil a brána může potřebovat jiný certifikát nebo nastavení ověřování. Reprodukujte jednosměrné chování s jedním testovacím klientem a jednou testovací VM, změňte typ podle schváleného harmonogramu a poté zopakujte stejné směrové testy. Pokud chování přepnutí přežije, typ tunelu nebyl příčinou a problém jste zúžili, aniž byste se dotkli produkce.

Mýtus: broadcastové zjišťování překračuje hranici VNetu

Druhý předpoklad selhává z nesouvisejícího důvodu. Virtuální síť Azure nepřenáší broadcastový provoz, takže VM nemůže přijímat broadcastové rámce z místní sítě přes připojení site-to-site nebo point-to-site. Aplikace, které nacházejí protějšky přes broadcast, jako starší procházení souborů nebo některé protokoly pro zjišťování zařízení, nikdy neuvidí vzdálenou stranu, ať jsou trasy napsané jakkoli.

Nahraďte broadcastové zjišťování názvy DNS, adresářovou službou nebo explicitním seznamem protějšků. Pokud aplikace nemá unicastovou alternativu, návrh potřebuje jiný mechanismus zjišťování, ne širší tunel.

Co změnit a jak to dokázat

Pokud směrový test selhává jen na IKEv2, zaznamenejte typ tunelu brány, pool adres klientů a přesný test ICMP nebo TCP, poté vyhodnoťte schválený profil OpenVPN pro postižené klienty. Pokud selhává u každého typu tunelu, pracujte na zpětné cestě: adresa klienta musí být směrovatelná z podsítě VM, každá uživatelem definovaná trasa musí ukazovat na platný další skok a firewall klienta musí přijmout příchozí tok. Přiložte důkazy z NSG a tras k tiketu.

Ověřujte aplikací, ne pingem. Úspěšná výměna ICMP po změně neříká nic o portu služby, jejím ověřování ani překladu názvů. Zopakujte test po opětovném připojení, protože klient, který dostane jinou adresu z poolu, může výsledek změnit. Potom ho zopakujte ještě jednou poté, co klient usne a probudí se, protože právě v obnovené relaci se jednosměrné chování často vrací.