Povratni promet Azure P2S VPN deluje samo v eno smer

Ikona tunela je zelena, NSG se zdi dovoljujoč, učinkovite poti se zdijo pravilne, a VM vseeno ne more odpreti povezave nazaj k povezanemu odjemalcu. Običajna predpostavka je, da je delujoč tunel point-to-site simetričen: če odjemalec doseže VM, VM doseže odjemalca. Ta predpostavka je napaka v razmišljanju, ne v konfiguraciji. Tunel lahko prenaša eno smer nezahtevanega toka in drugo zavrže, popravek pa je odvisen od tega, katera plast jo zavrže.

Mit: povezan tunel je dvosmerni tunel

Tunel VPN je pot politike, ne žica. Vsaka smer se primerja s selektorji, potmi in filtri, in kateri koli od njih lahko dovoli eno smer, medtem ko drugo blokira.

V praksi je asimetrija dovolj pogosta, da smer sodi v prvi test, ne v zadnjega. Odjemalec začne, prehod sledi toku, odgovor pa sledi stanju, ki je bilo ustvarjeno. VM, ki začne nov tok, takega stanja nima, zato je odvisna od tega, da je povratna pot izrecno usmerljiva in dovoljena. Ko te poti ni, poskus povezave umre, preden ga vidi katera koli aplikacija.

Preverite smer, preden preverite dosegljivost

Izberite en naslov odjemalca, en naslov VM in en protokol. Povežite se z odjemalca in zabeležite rezultat; nato zaženite isti test z VM in zabeležite še tega. Če prvi uspe in drugi ne, bazen odjemalcev, povezava prehoda in pot od odjemalca do VNeta delujejo.

Naslednji korak so dokazi, ne več pravil. Preverite NSG v podomrežju VM v obe smeri, preberite učinkovite poti na NIC VM in zajemite pakete na VM, medtem ko odjemalec pošilja promet. Zahteva, ki prispe brez odgovora, je težava filtra ali povratne poti; zahteva, ki nikoli ne prispe, je težava poti. Ne jemljite neuspešnega pinga kot dokaz, da VM ni dosegljiva, ker lahko politika ICMP zavrže odgovor, medtem ko TCP deluje.

Povratna pot IKEv2 point-to-site je običajni osumljenec

V poročilu Azure, na katerem temelji ta članek, je odjemalec dosegel VM prek IKEv2, vendar je dohodni ICMP z VM k odjemalcu spodletel, dokler vrsta tunela prehoda ni bila preklopljena na OpenVPN. Avtor poročila navaja, da je Microsoft potrdil omejitev na poti IKEv2 point-to-site, kjer se povratni promet z VM k odjemalcu ne usmerja simetrično, razen če je sejo začel odjemalec. IKEv2 se opira na selektorje prometa, prehod pa v tem primeru ni upošteval povratne smeri.

To ne naredi OpenVPN na splošno boljše vrste tunela. To naredi vrsto tunela spremenljivko v testni matriki za to delovno obremenitev.

Menjava vrste tunela je sprememba storitve, ne stikalo. Vsak odjemalec potrebuje združljiv profil, prehod pa morda potrebuje drugo potrdilo ali nastavitev preverjanja pristnosti. Poustvarite enosmerno vedenje z enim testnim odjemalcem in eno testno VM, spremenite vrsto po odobrenem urniku in nato ponovite iste teste smeri. Če vedenje preživi preklop, vrsta tunela ni bila vzrok in težavo ste zožili, ne da bi se dotaknili produkcije.

Mit: odkrivanje prek broadcasta prestopi mejo VNeta

Druga predpostavka spodleti iz nepovezanega razloga. Virtualno omrežje Azure ne prenaša broadcast prometa, zato VM ne more prejemati broadcast okvirov iz lokalnega omrežja prek povezave site-to-site ali point-to-site. Aplikacije, ki najdejo partnerje prek broadcasta, kot starejše brskanje po datotekah ali nekateri protokoli za odkrivanje naprav, ne bodo nikoli videle oddaljene strani, ne glede na to, kako so zapisane poti.

Odkrivanje prek broadcasta zamenjajte z imeni DNS, imeniško storitvijo ali izrecnim seznamom partnerjev. Če aplikacija nima alternativne unicast poti, zasnova potrebuje drug mehanizem odkrivanja, ne širšega tunela.

Kaj spremeniti in kako to dokazati

Če test smeri spodleti samo na IKEv2, zabeležite vrsto tunela prehoda, bazen naslovov odjemalcev in natančen test ICMP ali TCP, nato ocenite odobren profil OpenVPN za prizadete odjemalce. Če spodleti pri vsaki vrsti tunela, delajte na povratni poti: naslov odjemalca mora biti usmerljiv iz podomrežja VM, vsaka uporabniško določena pot mora kazati na veljaven naslednji skok, požarni zid odjemalca pa mora sprejeti dohodni tok. Dokaze NSG in poti priložite k zahtevku.

Preverjajte z aplikacijo, ne s pingom. Uspešna izmenjava ICMP po spremembi ne pove ničesar o vratih storitve, njenem preverjanju pristnosti ali razreševanju imen. Ponovite test po ponovni povezavi, ker lahko odjemalec, ki prejme drug naslov iz bazena, spremeni rezultat. Nato ga ponovite še enkrat, potem ko odjemalec zaspi in se prebudi, saj se prav v obnovljeni seji enosmerno vedenje pogosto vrne.