Azure P2S VPN-returttrafikk virkar berre éin veg

Tunnelikonet er grønt, NSG-en ser tillatande ut, dei effektive rutene ser riktige ut, og likevel kan ikkje VM-en opne ei tilkopling tilbake til den tilkopla klienten. Den vanlege antakinga er at ein fungerande point-to-site-tunnel er symmetrisk: viss klienten når VM-en, når VM-en klienten. Den antakinga er feilen i resonnementet, ikkje i konfigurasjonen. Ein tunnel kan bera éi retning av ein uoppfordra straum og sleppe den andre, og rettinga avheng av kva lag som slepp han.

Myte: ein tilkopla tunnel er ein tovegstunnel

Ein VPN-tunnel er ein policyveg, ikkje ein leidning. Kvar retning vert samanlikna med selektorar, ruter og filter, og kvar av dei kan tillate den eine retninga medan han blokkerer den andre.

I praksis er asymmetrien så vanleg at retninga høyrer heime i den første testen, ikkje den siste. Klienten initierer, gatewayen følgjer straumen, og svaret følgjer tilstanden som vart oppretta. Ein VM som startar ein ny straum har ingen slik tilstand, så han avheng av at returvegen er eksplisitt rutbar og tillaten. Når den vegen manglar, døyr tilkoplingsforsøket før nokon applikasjon ser det.

Test retninga før du testar tilgjengelegheita

Vel éi klientadresse, éi VM-adresse og éin protokoll. Kople til frå klienten og noter resultatet; start deretter den same testen frå VM-en og noter den òg. Viss den første lukkast og den andre mislukkast, fungerer klientpoolen, gateway-tilknytinga og vegen frå klient til VNet.

Neste steg er bevis, ikkje fleire reglar. Kontroller NSG-en på VM-subnettet i båe retningar, les dei effektive rutene på NIC-en til VM-en, og fang pakkar på VM-en medan klienten sender trafikk. Ein førespurnad som kjem utan svar er eit filter- eller returruteproblem; ein førespurnad som aldri kjem er eit vegproblem. Ikkje handsam ein mislukka ping som bevis på at VM-en er utilgjengeleg, for ein ICMP-policy kan sleppe svaret medan TCP fungerer.

IKEv2 point-to-site-returvegen er den vanlege mistenkte

I Azure-rapporten bak denne artikkelen kunne ein klient nå VM-ar over IKEv2, men innkomande ICMP frå VM-en til klienten mislukkast til tunneltypen til gatewayen vart bytt til OpenVPN. Rapporteraren opplyser at Microsoft stadfeste ei avgrensing i IKEv2 point-to-site-vegen, der returtrafikk frå ein VM til klienten ikkje vert ruta symmetrisk med mindre klienten starta økta. IKEv2 er avhengig av trafikkselektorar, og gatewayen respekterte ikkje returretninga i det tilfellet.

Det gjer ikkje OpenVPN til den betre tunneltypen generelt. Det gjer tunneltype til ein variabel i testmatrisa for denne arbeidsmengda.

Å byte tunneltype er ei tenesteendring, ikkje ein brytar. Kvar klient treng ein kompatibel profil, og gatewayen kan trenge eit anna sertifikat eller ei anna autentiseringsoppsett. Gjenskap einvegsåtferda med éin testklient og éin test-VM, endre typen etter ein godkjend plan, og gjenta deretter dei same retningstestane. Viss åtferda overlever bytet, var ikkje tunneltypen årsaka, og du har snevra inn problemet utan å røre produksjonen.

Myte: broadcast-oppdaging kryssar VNet-grensa

Ein annan antaking feilar av ein urelatert grunn. Eit virtuelt Azure-nettverk transporterer ikkje broadcast-trafikk, så ein VM kan ikkje ta imot broadcast-rammer frå eit lokalt nettverk over ei site-to-site- eller point-to-site-tilkopling. Applikasjonar som finn jamaldringar via broadcast, som eldre filutforsking eller enkelte einingsoppdagingsprotokollar, vil aldri sjå den fjerne sida, uansett korleis rutene er skrivne.

Erstatt broadcast-oppdaging med DNS-namn, ein katalogteneste eller ei eksplisitt jamaldringsliste. Viss applikasjonen ikkje har noko unicast-alternativ, treng designet ein annan oppdagingsmekanisme, ikkje ein breiare tunnel.

Kva som skal endrast, og korleis bevise det

Viss retningstesten berre feilar på IKEv2, noter tunneltypen til gatewayen, klientadressepoolen og den nøyaktige ICMP- eller TCP-testen, og vurder deretter ein godkjend OpenVPN-profil for dei råka klientane. Viss han feilar på alle tunneltypar, arbeid med returvegen: klientadressa må vere rutbar frå VM-subnettet, kvar brukardefinert rute må peike på eit gyldig neste hopp, og brannmuren til klienten må godta den innkomande straumen. Legg ved NSG- og rutebevisa i saka.

Stadfest med applikasjonen, ikkje med ping. Ei vellukka ICMP-utveksling etter ei endring seier ingenting om tenesteporten, autentiseringa eller namneoppløysinga. Gjenta testen etter ei ny tilkopling, fordi ein klient som får ei anna pooladresse kan endre resultatet. Gjenta han deretter éin gong til etter at klienten har sove og vakna, sidan det er i ei gjenoppteken økt at einvegsåtferd ofte dukkar opp att.