La revena trafiko de Azure P2S VPN funkcias nur unudirekte

La tunela ikono estas verda, la NSG ŝajnas permesa, la efikaj vojoj ŝajnas ĝustaj, kaj tamen la VM ankoraŭ ne povas malfermi konekton reen al la konektita kliento. La kutima supozo estas, ke funkcianta point-to-site-tunelo estas simetria: se la kliento povas atingi la VM, la VM povas atingi la klienton. Tiu supozo estas la eraro en la rezono, ne en la agordo. Tunelo povas porti unu direkton de nepeta fluo kaj forĵeti la alian, kaj la riparo dependas de tio, kiun tavolon forĵetas ĝin.

Mito: konektita tunelo estas dudirekta tunelo

VPN-tunelo estas politika vojo, ne drato. Ĉiu direkto estas komparata kun selektiloj, vojoj kaj filtriloj, kaj iu ajn el ili povas permesi unu direkton dum ĝi blokas la alian.

En praktiko la nesimetrio estas sufiĉe ofta, ke la direkto apartenas al la unua testo, ne al la lasta. La kliento iniciatas, la pordego spuras la fluon, kaj la respondo sekvas la staton, kiu estis kreita. VM, kiu komencas novan fluon, ne havas tian staton, do ĝi dependas de tio, ke la revena vojo estu eksplicite voja kaj permesita. Kiam tiu vojo mankas, la konekta provo mortas antaŭ ol iu ajn aplikaĵo vidas ĝin.

Testu la direkton antaŭ ol testi atingeblon

Elektu unu klientan adreson, unu VM-adreson kaj unu protokolon. Konektiĝu de la kliento kaj registru la rezulton; poste komencu la saman teston de la VM kaj registru ankaŭ tion. Se la unua sukcesas kaj la dua malsukcesas, la klienta baseno, la pordega asociiĝo kaj la vojo de kliento al VNet ĉiuj funkcias.

La sekva paŝo estas pruvoj, ne pli da reguloj. Kontrolu la NSG en la VM-subreto en ambaŭ direktoj, legu la efikajn vojojn sur la VM-NIC, kaj kaptu pakojn sur la VM dum la kliento sendas trafikon. Peto, kiu alvenas sen respondo, estas problemo de filtrilo aŭ revena vojo; peto, kiu neniam alvenas, estas problemo de vojo. Ne prenu malsukcesan ping kiel pruvon, ke la VM estas neatingebla, ĉar ICMP-politiko povas forĵeti la respondon dum TCP funkcias.

La revena vojo IKEv2 point-to-site estas la kutima suspektulo

En la Azure-raporto malantaŭ ĉi tiu artikolo, kliento povis atingi VM-ojn per IKEv2, sed envenanta ICMP de la VM al la kliento malsukcesis ĝis kiam la tunel-speco de la pordego estis ŝanĝita al OpenVPN. La raportinto deklaras, ke Microsoft konfirmis limigon en la IKEv2 point-to-site-vojo, kie revena trafiko de VM al la kliento ne estas voja simetrie krom se la kliento komencis la sesion. IKEv2 dependas de trafik-selektiloj, kaj la pordego ne honoris la revenan direkton en tiu kazo.

Tio ne faras OpenVPN la pli bonan tunel-specon ĝenerale. Ĝi faras la tunel-specon variablo en la testa matrico por ĉi tiu laborŝarĝo.

Ŝanĝi tunel-specon estas ŝanĝo de servo, ne ŝaltilo. Ĉiu kliento bezonas kongruan profilon, kaj la pordego eble bezonas alian atestilon aŭ agordon de aŭtentigo. Riproduktu la unudirektan konduton per unu testa kliento kaj unu testa VM, ŝanĝu la specon laŭ aprobita horaro, kaj poste ripetu la samajn direktajn testojn. Se la konduto postvivas la ŝanĝon, la tunel-speco ne estis la kaŭzo kaj vi mallarĝigis la problemon sen tuŝi produktaĵon.

Mito: dissenda malkovro transiras la randon de VNet

Dua supozo malsukcesas pro ne rilata kialo. Azure-virtuala reto ne transportas dissendan trafikon, do VM ne povas ricevi dissendajn kadrojn de loka reto per site-to-site aŭ point-to-site-konekto. Aplikaĵoj, kiuj trovas kunulojn per dissendo, kiel pli malnova dosier-esplorado aŭ iuj aparat-malkovraj protokoloj, neniam vidos la malproksiman flankon, kiel ajn la vojoj estas skribitaj.

Anstataŭigu dissendan malkovron per DNS-nomoj, adresara servo aŭ eksplicita kunula listo. Se la aplikaĵo ne havas unicast-alternativon, la dezajno bezonas alian malkovran mekanismon, ne pli larĝan tunelon.

Kion ŝanĝi kaj kiel pruvi ĝin

Se la direkta testo malsukcesas nur ĉe IKEv2, registru la tunel-specon de la pordego, la klientan adres-basenon kaj la precizan ICMP- aŭ TCP-teston, poste taksu aprobitan OpenVPN-profilon por la tuŝitaj klientoj. Se ĝi malsukcesas ĉe ĉiu tunel-speco, laboru la revenan vojon: la klienta adreso devas esti voja de la VM-subreto, iu ajn uzanto-difinita vojo devas montri al valida sekva salteto, kaj la klienta fajroŝirmilo devas akcepti la envenantan fluon. Aldonu la NSG- kaj vojajn pruvojn al la bileto.

Kontrolu per la aplikaĵo, ne per ping. Sukcesa ICMP-interŝanĝo post ŝanĝo diras nenion pri la serva pordo, ĝia aŭtentigo aŭ ĝia nom-rezolucio. Ripetu la teston post rekonekto, ĉar kliento, kiu ricevas alian basenan adreson, povas ŝanĝi la rezulton. Poste ripetu ĝin ankoraŭfoje post kiam la kliento dormas kaj vekiĝas, ĉar en daŭrigita sesio la unudirekta konduto ofte reaperas.