Azure P2S VPN-returtrafikk virker bare én vei

Tunnelikonet er grønt, NSG-en ser tillatende ut, de effektive rutene ser riktige ut, og likevel kan ikke VM-en åpne en tilkobling tilbake til den tilkoblede klienten. Den vanlige antakelsen er at en fungerende point-to-site-tunnel er symmetrisk: hvis klienten når VM-en, når VM-en klienten. Den antakelsen er feilen i resonnementet, ikke i konfigurasjonen. En tunnel kan bære én retning av en uoppfordret strøm og slippe den andre, og rettelsen avhenger av hvilket lag som slipper den.

Myte: en tilkoblet tunnel er en toveis tunnel

En VPN-tunnel er en policyvei, ikke en ledning. Hver retning matches mot selektorer, ruter og filtre, og enhver av dem kan tillate den ene retningen mens den blokkerer den andre.

I praksis er asymmetrien så vanlig at retningen hører hjemme i den første testen, ikke den siste. Klienten initierer, gatewayen følger strømmen, og svaret følger tilstanden som ble opprettet. En VM som starter en ny strøm har ingen slik tilstand, så den avhenger av at returveien er eksplisitt rutbar og tillatt. Når den veien mangler, dør tilkoblingsforsøket før noen applikasjon ser det.

Test retningen før du tester tilgjengeligheten

Velg én klientadresse, én VM-adresse og én protokoll. Koble til fra klienten og noter resultatet; start deretter den samme testen fra VM-en og noter den også. Hvis den første lykkes og den andre mislykkes, fungerer klientpoolen, gateway-tilknytningen og veien fra klient til VNet.

Neste steg er bevis, ikke flere regler. Kontroller NSG-en på VM-ens subnett i begge retninger, les de effektive rutene på VM-ens NIC, og fang pakker på VM-en mens klienten sender trafikk. En forespørsel som ankommer uten svar er et filter- eller returruteproblem; en forespørsel som aldri ankommer er et veiproblem. Ikke behandle en mislykket ping som bevis på at VM-en er utilgjengelig, for en ICMP-policy kan slippe svaret mens TCP fungerer.

IKEv2 point-to-site-returveien er den vanlige mistenkte

I Azure-rapporten bak denne artikkelen kunne en klient nå VM-er over IKEv2, men innkommende ICMP fra VM-en til klienten mislyktes til gatewayens tunneltype ble byttet til OpenVPN. Rapporteren oppgir at Microsoft bekreftet en begrensning i IKEv2 point-to-site-veien, der returtrafikk fra en VM til klienten ikke rutes symmetrisk med mindre klienten startet økten. IKEv2 er avhengig av trafikkselektorer, og gatewayen respekterte ikke returretningen i det tilfellet.

Det gjør ikke OpenVPN til den bedre tunneltypen generelt. Det gjør tunneltype til en variabel i testmatrisen for denne arbeidsmengden.

Å bytte tunneltype er en tjenesteendring, ikke en bryter. Hver klient trenger en kompatibel profil, og gatewayen kan trenge et annet sertifikat eller en annen autentiseringsoppsett. Gjenskap enveisatferden med én testklient og én test-VM, endre typen etter en godkjent plan, og gjenta deretter de samme retningstestene. Hvis atferden overlever byttet, var ikke tunneltypen årsaken, og du har snevret inn problemet uten å røre produksjonen.

Myte: broadcast-oppdagelse krysser VNet-grensen

En andre antakelse feiler av en urelatert grunn. Et virtuelt Azure-nettverk transporterer ikke broadcast-trafikk, så en VM kan ikke motta broadcast-rammer fra et lokalt nettverk over en site-to-site- eller point-to-site-tilkobling. Applikasjoner som finner jevnaldrende via broadcast, som eldre filutforsking eller enkelte enhetsoppdagelsesprotokoller, vil aldri se den fjerne siden, uansett hvordan rutene er skrevet.

Erstatt broadcast-oppdagelse med DNS-navn, en katalogtjeneste eller en eksplisitt jevnaldrende liste. Hvis applikasjonen ikke har noe unicast-alternativ, trenger designet en annen oppdagelsesmekanisme, ikke en bredere tunnel.

Hva som skal endres, og hvordan bevise det

Hvis retningstesten bare feiler på IKEv2, noter gatewayens tunneltype, klientadressepoolen og den nøyaktige ICMP- eller TCP-testen, og vurder deretter en godkjent OpenVPN-profil for de berørte klientene. Hvis den feiler på alle tunneltyper, arbeid med returveien: klientadressen må være rutbar fra VM-ens subnett, enhver brukerdefinert rute må peke på et gyldig neste hopp, og klientens brannmur må godta den innkommende strømmen. Legg ved NSG- og rutebevisene i saken.

Verifiser med applikasjonen, ikke med ping. En vellykket ICMP-utveksling etter en endring sier ingenting om tjenesteporten, autentiseringen eller navneoppløsningen. Gjenta testen etter en ny tilkobling, fordi en klient som får en annen pooladresse kan endre resultatet. Gjenta den deretter én gang til etter at klienten har sovet og våknet, siden det er i en gjenopptatt økt at enveisatferd ofte dukker opp igjen.