Spätná prevádzka Azure P2S VPN funguje len jedným smerom

Ikona tunela je zelená, NSG vyzerá povoľujúco, efektívne trasy vyzerajú správne, a napriek tomu VM nemôže otvoriť pripojenie späť k pripojenému klientovi. Zvyčajný predpoklad je, že funkčný point-to-site tunel je symetrický: ak sa klient dostane k VM, dostane sa VM aj ku klientovi. Tento predpoklad je chyba v uvažovaní, nie v konfigurácii. Tunel môže prenášať jeden smer nevyžiadanej prevádzky a druhý zahadzovať, a oprava závisí od toho, ktorá vrstva ho zahadzuje.

Mýtus: pripojený tunel je obojsmerný tunel

VPN tunel je cesta politiky, nie drôt. Každý smer sa porovnáva so selektormi, trasami a filtrami a ktorýkoľvek z nich môže povoliť jeden smer a zablokovať druhý.

V praxi je asymetria dosť častá na to, aby smer patril do prvého testu, nie do posledného. Klient inicializuje, brána sleduje tok a odpoveď nasleduje stav, ktorý vznikol. VM, ktorá začína nový tok, taký stav nemá, takže závisí od toho, aby bola spätná cesta výslovne smerovateľná a povolená. Keď táto cesta chýba, pokus o pripojenie zomrie skôr, než ho nejaká aplikácia uvidí.

Otestujte smer skôr, než otestujete dostupnosť

Vyberte jednu adresu klienta, jednu adresu VM a jeden protokol. Pripojte sa z klienta a zaznamenajte výsledok; potom spustite ten istý test z VM a zaznamenajte aj ten. Ak prvý uspeje a druhý zlyhá, pool klientov, pridruženie brány aj cesta z klienta do VNetu fungujú.

Ďalším krokom sú dôkazy, nie ďalšie pravidlá. Skontrolujte NSG v podsieti VM v oboch smeroch, prečítajte efektívne trasy na NIC VM a zachyťte pakety na VM, kým klient posiela prevádzku. Požiadavka, ktorá dorazí bez odpovede, je problém filtra alebo spätnej trasy; požiadavka, ktorá nedorazí vôbec, je problém cesty. Neberte neúspešný ping ako dôkaz, že VM je nedostupná, pretože politika ICMP môže zahodiť odpoveď, aj keď TCP funguje.

Spätná cesta IKEv2 point-to-site je obvyklý podozrivý

V správe Azure, na ktorej je tento článok založený, sa klient dostal k VM cez IKEv2, ale prichádzajúci ICMP z VM ku klientovi zlyhával, kým nebol typ tunela brány prepnutý na OpenVPN. Autor správy uvádza, že Microsoft potvrdil obmedzenie v ceste IKEv2 point-to-site, kde sa spätná prevádzka z VM ku klientovi nesmeruje symetricky, pokiaľ reláciu nezačal klient. IKEv2 sa spolieha na selektory prevádzky a brána v tom prípade spätný smer nezohľadnila.

To nerobí z OpenVPN všeobecne lepší typ tunela. Robí to z typu tunela premennú v testovacej matici pre túto záťaž.

Prepnúť typ tunela je zmena služby, nie prepínač. Každý klient potrebuje kompatibilný profil a brána môže potrebovať iný certifikát alebo nastavenie overovania. Reprodukujte jednosmerné správanie s jedným testovacím klientom a jednou testovacou VM, zmeňte typ podľa schváleného harmonogramu a potom zopakujte rovnaké smerové testy. Ak správanie prepnutie prežije, typ tunela nebol príčinou a problém ste zúžili bez zásahu do produkcie.

Mýtus: broadcastové zisťovanie prekračuje hranicu VNetu

Druhý predpoklad zlyháva z nesúvisiaceho dôvodu. Virtuálna sieť Azure neprenáša broadcastovú prevádzku, takže VM nemôže prijímať broadcastové rámce z lokálnej siete cez pripojenie site-to-site alebo point-to-site. Aplikácie, ktoré nachádzajú partnerov cez broadcast, ako staršie prehliadanie súborov alebo niektoré protokoly zisťovania zariadení, nikdy neuvidia vzdialenú stranu, nech sú trasy napísané akokoľvek.

Nahraďte broadcastové zisťovanie názvami DNS, adresárovou službou alebo explicitným zoznamom partnerov. Ak aplikácia nemá unicastovú alternatívu, návrh potrebuje iný mechanizmus zisťovania, nie širší tunel.

Čo zmeniť a ako to dokázať

Ak smerový test zlyháva len na IKEv2, zaznamenajte typ tunela brány, pool adries klientov a presný test ICMP alebo TCP, potom vyhodnoťte schválený profil OpenVPN pre postihnutých klientov. Ak zlyháva pri každom type tunela, pracujte na spätnej ceste: adresa klienta musí byť smerovateľná z podsiete VM, každá používateľom definovaná trasa musí ukazovať na platný ďalší skok a firewall klienta musí prijať prichádzajúci tok. Priložte dôkazy z NSG a trás k tiketu.

Overujte aplikáciou, nie pingom. Úspešná výmena ICMP po zmene nehovorí nič o porte služby, jej overovaní ani preklade názvov. Zopakujte test po opätovnom pripojení, pretože klient, ktorý dostane inú adresu z poolu, môže výsledok zmeniť. Potom ho zopakujte ešte raz po tom, čo klient zaspí a prebudí sa, pretože práve v obnovenej relácii sa jednosmerné správanie často vracia.