Azure P2S VPN-returtrafik fungerar bara åt ena hållet

Tunnelikonen är grön, NSG ser tillåtande ut, de effektiva rutterna ser riktiga ut, och ändå kan VM:en inte öppna en anslutning tillbaka till den anslutna klienten. Det vanliga antagandet är att en fungerande point-to-site-tunnel är symmetrisk: om klienten når VM:en når VM:en klienten. Det antagandet är felet i resonemanget, inte i konfigurationen. En tunnel kan bära en riktning av ett oönskat flöde och släppa den andra, och rättelsen beror på vilket lager som släpper den.

Myt: en ansluten tunnel är en tvåvägstunnel

En VPN-tunnel är en policysökväg, inte en kabel. Varje riktning matchas mot selektorer, rutter och filter, och var och en av dem kan tillåta den ena riktningen medan den blockerar den andra.

I praktiken är asymmetrin så vanlig att riktningen hör hemma i det första testet, inte det sista. Klienten initierar, gatewayen följer flödet och svaret följer det tillstånd som skapades. En VM som startar ett nytt flöde har inget sådant tillstånd, så den är beroende av att returvägen är uttryckligen routbar och tillåten. När den vägen saknas dör anslutningsförsöket innan någon applikation ser det.

Testa riktningen innan du testar nåbarheten

Välj en klientadress, en VM-adress och ett protokoll. Anslut från klienten och notera resultatet; starta sedan samma test från VM:en och notera det också. Om det första lyckas och det andra misslyckas fungerar klientpoolen, gateway-kopplingen och vägen från klient till VNet.

Nästa steg är bevis, inte fler regler. Kontrollera NSG:n på VM:ens undernät i båda riktningarna, läs de effektiva rutterna på VM:ens NIC och fånga paket på VM:en medan klienten skickar trafik. En begäran som anländer utan svar är ett filter- eller returruttproblem; en begäran som aldrig anländer är ett vägproblem. Behandla inte en misslyckad ping som bevis på att VM:en är onåbar, för en ICMP-policy kan släppa svaret medan TCP fungerar.

IKEv2 point-to-site-returvägen är den vanliga misstänkta

I Azure-rapporten bakom den här artikeln kunde en klient nå VM:ar över IKEv2, men inkommande ICMP från VM:en till klienten misslyckades tills gatewayens tunneltyp byttes till OpenVPN. Rapportören uppger att Microsoft bekräftade en begränsning i IKEv2 point-to-site-vägen, där returtrafik från en VM till klienten inte routas symmetriskt om inte klienten startade sessionen. IKEv2 förlitar sig på trafikselektorer, och gatewayen respekterade inte returriktningen i det fallet.

Det gör inte OpenVPN till den bättre tunneltypen generellt. Det gör tunneltypen till en variabel i testmatrisen för den här arbetsbelastningen.

Att byta tunneltyp är en tjänsteändring, inte en strömbrytare. Varje klient behöver en kompatibel profil, och gatewayen kan behöva ett annat certifikat eller en annan autentiseringsinställning. Återskapa envägsbeteendet med en testklient och en test-VM, ändra typen enligt ett godkänt schema och upprepa sedan samma riktningstester. Om beteendet överlever bytet var tunneltypen inte orsaken och du har ringat in problemet utan att röra produktionen.

Myt: broadcast-upptäckt korsar VNet-gränsen

Ett andra antagande fallerar av en orelaterad anledning. Ett virtuellt Azure-nätverk transporterar inte broadcast-trafik, så en VM kan inte ta emot broadcast-ramar från ett lokalt nätverk över en site-to-site- eller point-to-site-anslutning. Applikationer som hittar peers via broadcast, som äldre filbläddring eller vissa enhetsupptäcktsprotokoll, kommer aldrig att se den avlägsna sidan, oavsett hur rutterna skrivs.

Ersätt broadcast-upptäckt med DNS-namn, en katalogtjänst eller en explicit peerlista. Om applikationen inte har något unicast-alternativ behöver designen en annan upptäcktsmekanism, inte en bredare tunnel.

Vad som ska ändras och hur det bevisas

Om riktningstestet bara misslyckas på IKEv2, notera gatewayens tunneltyp, klientadresspoolen och det exakta ICMP- eller TCP-testet, och utvärdera sedan en godkänd OpenVPN-profil för de berörda klienterna. Om det misslyckas på alla tunneltyper, arbeta med returvägen: klientadressen måste vara routbar från VM:ens undernät, varje användardefinierad rutt måste peka på ett giltigt nästa hopp, och klientens brandvägg måste acceptera det inkommande flödet. Bifoga NSG- och ruttbevisen till ärendet.

Verifiera med applikationen, inte med ping. Ett lyckat ICMP-utbyte efter en ändring säger ingenting om tjänstens port, dess autentisering eller dess namnuppslagning. Upprepa testet efter en återanslutning, eftersom en klient som får en annan pooladress kan ändra resultatet. Upprepa det sedan en gång till efter att klienten har sovit och vaknat, eftersom det är i en återupptagen session som envägsbeteende ofta dyker upp igen.