Azure P2S VPN-returtrafik virker kun én vej

Tunnelikonet er grønt, NSG ser tilladende ud, de effektive ruter ser rigtige ud, og alligevel kan VM'en ikke åbne en forbindelse tilbage til den tilsluttede klient. Den sædvanlige antagelse er, at en fungerende point-to-site-tunnel er symmetrisk: hvis klienten kan nå VM'en, kan VM'en også nå klienten. Den antagelse er fejlen i ræsonnementet, ikke i konfigurationen. En tunnel kan bære én retning af en uopfordret strøm og droppe den anden, og rettelsen afhænger af, hvilket lag der dropper den.

Myte: en tilsluttet tunnel er en tovejstunnel

En VPN-tunnel er en politikvej, ikke en ledning. Hver retning matches mod selektorer, ruter og filtre, og enhver af dem kan tillade den ene retning, mens den blokerer den anden.

I praksis er asymmetrien så almindelig, at retningen hører til den første test, ikke den sidste. Klienten initierer, gatewayen følger strømmen, og svaret følger den tilstand, der blev oprettet. En VM, der starter en ny strøm, har ingen sådan tilstand, så den afhænger af, at returvejen eksplicit kan routes og er tilladt. Når den vej mangler, dør forbindelsesforsøget, før nogen applikation ser det.

Test retningen, før du tester tilgængelighed

Vælg én klientadresse, én VM-adresse og én protokol. Forbind fra klienten, og noter resultatet; start derefter den samme test fra VM'en, og noter også den. Hvis den første lykkes, og den anden fejler, virker klientpuljen, gateway-tilknytningen og vejen fra klient til VNet alle sammen.

Det næste skridt er beviser, ikke flere regler. Kontroller NSG'en på VM'ens undernet i begge retninger, læs de effektive ruter på VM'ens NIC, og optag pakker på VM'en, mens klienten sender trafik. En anmodning, der ankommer uden svar, er et filter- eller returruteproblem; en anmodning, der aldrig ankommer, er et vejproblem. Betragt ikke en mislykket ping som bevis på, at VM'en er utilgængelig, for ICMP-politik kan droppe svaret, mens TCP virker.

IKEv2 point-to-site-returvejen er den sædvanlige mistænkte

I Azure-rapporten bag denne artikel kunne en klient nå VM'er over IKEv2, men indgående ICMP fra VM'en til klienten fejlede, indtil gatewayens tunneltype blev skiftet til OpenVPN. Forfatteren oplyser, at Microsoft bekræftede en begrænsning i IKEv2 point-to-site-vejen, hvor returtrafik fra en VM til klienten ikke routes symmetrisk, medmindre klienten startede sessionen. IKEv2 er afhængig af trafikselektorer, og gatewayen respekterede ikke returretningen i det tilfælde.

Det gør ikke OpenVPN til den bedre tunneltype generelt. Det gør tunneltype til en variabel i testmatricen for denne arbejdsbyrde.

At skifte tunneltype er en serviceændring, ikke en kontakt. Hver klient skal have en kompatibel profil, og gatewayen kan have brug for et andet certifikat eller en anden godkendelsesopsætning. Gengiv den envejsadfærd med én testklient og én test-VM, skift typen på en godkendt tidsplan, og gentag derefter de samme retningstests. Hvis adfærden overlever skiftet, var tunneltypen ikke årsagen, og du har indsnævret problemet uden at røre produktionen.

Myte: broadcast-opdagelse krydser VNet-grænsen

En anden antagelse fejler af en urelateret grund. Et Azure-virtuelt netværk transporterer ikke broadcast-trafik, så en VM kan ikke modtage broadcast-rammer fra et lokalt netværk over en site-to-site- eller point-to-site-forbindelse. Applikationer, der finder peers via broadcast, som ældre filgennemgang eller visse enhedsopdagelsesprotokoller, vil aldrig se den fjerne side, uanset hvordan ruterne er skrevet.

Erstat broadcast-opdagelse med DNS-navne, en katalogtjeneste eller en eksplicit peer-liste. Hvis applikationen ikke har noget unicast-alternativ, har designet brug for en anden opdagelsesmekanisme, ikke en bredere tunnel.

Hvad skal ændres, og hvordan beviser du det

Hvis retningstesten kun fejler på IKEv2, så noter gatewayens tunneltype, klientadressepuljen og den præcise ICMP- eller TCP-test, og vurder derefter en godkendt OpenVPN-profil til de berørte klienter. Hvis den fejler på alle tunneltyper, arbejd med returvejen: klientadressen skal kunne routes fra VM'ens undernet, enhver brugerdefineret rute skal pege på et gyldigt næste hop, og klientens firewall skal acceptere den indgående strøm. Vedhæft NSG- og rutebeviserne til sagen.

Verificér med applikationen, ikke med ping. En vellykket ICMP-udveksling efter en ændring siger intet om serviceporten, dens godkendelse eller dens navneopløsning. Gentag testen efter en genopkobling, fordi en klient, der får en anden puljeadresse, kan ændre resultatet. Gentag den derefter én gang mere, efter at klienten sover og vågner, da det er i en genoptaget session, at envejsadfærd ofte dukker op igen.