Hvorfor tilføjelse af et Azure VPN-præfiks bryder forbindelsen

Et præfiks, der tilføjes til det forkerte Azure-objekt, giver en forbindelse, der rapporterer Connected og ikke videresender noget, og det er den dyreste slags fejl i denne stak. Tre ressourcer er involveret, og kun én af dem ejer det fjerne adresserum: den virtuelle netværksgateway, den lokale netværksgateway, der beskriver den fjerne side, og forbindelsen, der forbinder dem. Præfikset hører til den lokale netværksgateway, forbindelsen skal genopbygges, før ændringen træder i kraft, og selve gatewayen efterlades normalt i fred. Rækkefølgen er ikke til forhandling, og portalen viser kun en del af den.

Tre objekter, hvoraf ét holder præfikset

Det virtuelle netværks adresserum besvarer et andet spørgsmål: hvad der bor inde i Azure. At tilføje et fjernt præfiks der ruter ikke trafik til det, det udvider blot det rum, som platformen mener at eje, hvilket kan støde sammen med det virkelige fjerne område. Den lokale netværksgateway er det objekt, der holder de fjerne præfikser, og forbindelsen refererer til begge gateways plus en på forhånd delt nøgle.

Der er en tredje reservation, man skal holde styr på. GatewaySubnet hoster de administrerede gatewayforekomster, skal bære præcis det navn, og for ikke-Basic SKU'er forventes det at være mindst /27.

Intet andet hører til i det undernet, og en præfiksændring har ingen grund til at røre det. Et præfiks, der mangler i den lokale netværksgateway, er utilgængeligt, uanset hvad forbindelsesstatus siger, fordi gatewayen kun tilbyder de præfikser, den blev informeret om, da den forhandlede tunnelen. Derfor er symptomet asymmetrisk: tunnelen er oppe, sikkerhedsassociationen er fin, og et undernet dukker aldrig op i trafikvælgerne. Hvis et enkelt fjernt område mangler, mens dets naboer virker, så stop med at kigge på tunnelen og læs den lokale netværksgateway.

Hvorfor det er forbindelsen, der fjernes

Forbindelsesobjektet fastholder den forhandlede konfiguration i hele sin levetid. Derfor fjerner den dokumenterede procedure først forbindelsen, opdaterer den lokale netværksgateway og genskaber derefter forbindelsen med den samme delte nøgle. Gatewayforekomsterne genopbygges ikke ved en ændring, der kun vedrører præfikset, hvilket holder afbrydelsen begrænset til forbindelsens nedrivning i stedet for en ny udrulning af gatewayen.

Den sletning er afbrydelsen, så behandl den som en planlagt ændring med en start og en forventet slutning i stedet for en hurtig redigering. I PowerShell er rækkefølgen kort: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, derefter Set-AzLocalNetworkGateway med det nye -AddressPrefix array, derefter New-AzVirtualNetworkGatewayConnection med den samme -SharedKey og de samme gateways. Genbrug af nøglen er vigtig, fordi den fjerne side ikke omkonfigureres, og en ny nøgle betyder koordinering med den, der ejer den fjerne enhed. Hvis et andet team kører den enhed, så aftal vinduet med dem, før du fjerner noget.

Hvornår gatewayen selv skal genopbygges

Et andet svar, der cirkulerer omkring dette problem, siger, at gatewayen skal genskabes, og nøglen skal udveksles igen. Det er korrekt for et andet sæt operationer: ændring af gatewaytypen eller SKU'en, skift mellem punkt-til-sted og sted-til-sted eller reparation af en gateway, hvis egen konfiguration er forkert. De ændringer ændrer faktisk gatewayressourcen, så en genopbygning er virkelig nødvendig.

En gateway oprettet til punkt-til-sted kan ikke bare tildeles en sted-til-sted-forbindelse. Punkt-til-sted-konfigurationen skal fjernes, og gatewayen genskabes, hvilket også giver en ny delt nøgle og en ny klientpakke.

Punkt-til-sted-pakken fortjener sin egen note, fordi den udløber. Portalen genererer en fil med kort levetid, så den praktiske tilgang er at downloade den én gang og distribuere den sammen med klientcertifikatet i stedet for at sende brugerne et portallink, der vil være dødt, når de klikker på det. For præfiksspørgsmålet gælder intet af dette. At holde de to procedurer adskilt er hele disciplinen: præfikser er en ændring på forbindelsesniveau, og gatewayegenskaber er en ændring på gatewayniveau.

Læs tilstanden, ikke portalens badge

Læs tilstanden fra ressourcen i stedet for fra badget i portalen. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 returnerer ConnectionStatus sammen med byte-tællere for indgående og udgående trafik, og det er tællerne, der adskiller en tunnel, der er forbundet og ikke bærer noget, fra en, der aldrig blev etableret.

Tællere, der stopper med at stige midt i en overførsel, peger på stien i stedet for på godkendelsen. Tællere, der slet ikke flytter sig, peger på præfikssættet eller den delte nøgle.

Timere forklarer en klasse af afbrydelser, der fejlagtigt tilskrives VPN'en. Azures belastningsbalancer lukker inaktive flows efter sin konfigurerede timeout, fire minutter som standard, da disse noter blev skrevet, og kan konfigureres opad, så en OpenVPN-server på en VM uden keepalive kan droppe hvert par minutter, mens alt andet ser sundt ud. En gateway, som platformen genstarter cyklisk, kan også afbryde en VNet-forbindelse til en Web App, og den fejl ligger på platformsiden i stedet for i en klientkonfiguration. Tegnet er, om afbrydelsen følger et fast interval eller en ændring, du har foretaget.

Hold de tre objekter og deres værdier i én registrering: det virtuelle netværks adresserum, den lokale netværksgateways præfiksliste og forbindelsens reference til den delte nøgle. site-til-site PowerShell-artiklen dokumenterer kommandoerne til den lokale netværksgateway og den rækkefølge, de hører til i. At sammenligne en præfiksændring med hukommelsen er, hvordan en fungerende tunnel bliver genopbygget to gange.

Bekræft derefter i den rækkefølge, du ændrede: den lokale netværksgateway viser den nye præfiksliste, forbindelsen er tilbage på Connected, og tællerne bevæger sig, når du sender trafik til en vært i det nye område. Hvis det tredje trin fejler, mens de to første består, har den fjerne side ikke accepteret den nye trafikvælger, og den fjerne enhed har brug for den matchende fase 2-post. Det er en samtale med den anden ende af tunnelen, ikke en anden ændring i Azure.