Azure P2S VPN-i tagasiliiklus töötab ainult ühes suunas

Tunneli ikoon on roheline, NSG tundub lubav, efektiivsed marsruudid tunduvad õiged, ja ometi ei saa VM avada ühendust tagasi ühendatud kliendi poole. Tavaline eeldus on, et töötav point-to-site tunnel on sümmeetriline: kui klient jõuab VM-ini, jõuab VM kliendini. See eeldus on viga mõttekäigus, mitte konfiguratsioonis. Tunnel võib kanda ühte suunda soovimata voost ja visata teise kõrvale, ning parandus sõltub sellest, milline kiht selle kõrvale viskab.

Müüt: ühendatud tunnel on kahesuunaline tunnel

VPN-tunnel on poliitikatee, mitte traat. Iga suunda võrreldakse selektorite, marsruutide ja filtritega ning ükskõik milline neist võib lubada ühte suunda, blokeerides teise.

Praktikas on asümmeetria nii tavaline, et suund kuulub esimesse testi, mitte viimasesse. Klient algatab, lüüs jälgib voogu ja vastus järgib loodud olekut. VM, mis alustab uut voogu, sellist olekut ei oma, seega sõltub ta sellest, et tagasitee oleks selgesõnaliselt marsruuditav ja lubatud. Kui see tee puudub, sureb ühenduskatse enne, kui ükski rakendus seda näeb.

Testige suunda enne kättesaadavuse testimist

Valige üks kliendi aadress, üks VM-i aadress ja üks protokoll. Ühenduge kliendist ja registreerige tulemus; seejärel alustage sama testi VM-ist ja registreerige ka see. Kui esimene õnnestub ja teine ebaõnnestub, töötavad kliendipool, lüüsi seostamine ja tee kliendist VNeti.

Järgmine samm on tõendid, mitte rohkem reegleid. Kontrollige VM-i alamvõrgu NSG-d mõlemas suunas, lugege efektiivseid marsruute VM-i NIC-l ja püüdke pakette VM-is, kui klient saadab liiklust. Vastuseta saabuv päring on filtri või tagasimarsruudi probleem; päring, mis kunagi ei saabu, on tee probleem. Ärge pidage ebaõnnestunud pingi tõendiks, et VM on kättesaamatu, sest ICMP-poliitika võib vastuse kõrvale visata, samal ajal kui TCP töötab.

IKEv2 point-to-site tagasitee on tavaline kahtlusalune

Selle artikli taga olevas Azure’i aruandes pääses klient IKEv2 kaudu VM-idele ligi, kuid sissetulev ICMP VM-ist kliendini ebaõnnestus, kuni lüüsi tunnelitüüp lülitati ümber OpenVPN-ile. Aruande autor märgib, et Microsoft kinnitas IKEv2 point-to-site tee piirangu, kus VM-ist kliendini suunduv tagasiliiklus ei ole sümmeetriliselt marsruuditud, kui sessiooni ei alustanud klient. IKEv2 toetub liiklusselektoritele ja lüüs ei arvestanud sel juhul tagasisuunda.

See ei tee OpenVPN-ist üldiselt paremat tunnelitüüpi. See teeb tunnelitüübist selle töökoormuse testmaatriksis muutuja.

Tunnelitüübi vahetamine on teenuse muudatus, mitte lüliti. Iga klient vajab ühilduvat profiili ja lüüs võib vajada teistsugust sertifikaati või autentimise seadistust. Korrake ühesuunalist käitumist ühe testkliendi ja ühe test-VM-iga, muutke tüüpi kinnitatud ajakava järgi ja korrake seejärel samu suunateste. Kui käitumine jääb pärast vahetust püsima, ei olnud tunnelitüüp põhjus ja olete probleemi kitsendanud ilma tootmist puutumata.

Müüt: broadcast-tuvastus ületab VNeti piiri

Teine eeldus ebaõnnestub seotud põhjuseta. Azure’i virtuaalne võrk ei edasta broadcast-liiklust, seega ei saa VM vastu võtta broadcast-kaadreid kohalikust võrgust site-to-site või point-to-site ühenduse kaudu. Rakendused, mis leiavad kaaslasi broadcasti abil, näiteks vanem failibrauser või mõned seadmete tuvastamise protokollid, ei näe kunagi kaugpoolt, ükskõik kuidas marsruudid on kirjutatud.

Asendage broadcast-tuvastus DNS-nimede, kataloogiteenuse või selgesõnalise kaaslaste loendiga. Kui rakendusel puudub unicast-alternatiiv, vajab disain teistsugust tuvastusmehhanismi, mitte laiemat tunnelit.

Mida muuta ja kuidas seda tõestada

Kui suunatest ebaõnnestub ainult IKEv2 puhul, registreerige lüüsi tunnelitüüp, kliendi aadresside pool ja täpne ICMP või TCP test, seejärel hinnake mõjutatud klientide jaoks kinnitatud OpenVPN profiili. Kui see ebaõnnestub iga tunnelitüübi puhul, töötage tagasiteega: kliendi aadress peab olema VM-i alamvõrgust marsruuditav, iga kasutaja määratud marsruut peab osutama kehtivale järgmisele hüppele ja kliendi tulemüür peab sissetuleva voo vastu võtma. Lisage NSG ja marsruutide tõendid piletile.

Kontrollige rakendusega, mitte pingiga. Edukas ICMP-vahetus pärast muudatust ei ütle midagi teenuse pordi, selle autentimise ega nimelahenduse kohta. Korrake testi pärast uuesti ühendamist, sest klient, kes saab poolest teise aadressi, võib tulemust muuta. Seejärel korrake seda veel kord pärast seda, kui klient magab ja ärkab, sest just jätkatud sessioonis ilmub ühesuunaline käitumine sageli uuesti.