Hvorfor det å legge til et Azure VPN-prefiks bryter forbindelsen

Et prefiks som legges til på feil Azure-objekt, gir en forbindelse som rapporterer Connected og ikke videresender noe, og det er den dyreste typen feil i denne stakken. Tre ressurser er involvert, og bare én av dem eier det eksterne adresserommet: den virtuelle nettverksgatewayen, den lokale nettverksgatewayen som beskriver den eksterne siden, og forbindelsen som knytter dem sammen. Prefikset tilhører den lokale nettverksgatewayen, forbindelsen må bygges på nytt for at endringen skal tre i kraft, og selve gatewayen blir vanligvis stående urørt. Rekkefølgen er ikke til forhandling, og portalen viser bare en del av den.

Tre objekter, hvorav ett holder prefikset

Adresserommet til det virtuelle nettverket svarer på et annet spørsmål: hva som bor inne i Azure. Å legge til et eksternt prefiks der ruter ikke trafikk dit, det utvider bare rommet plattformen mener den eier, noe som kan kollidere med det virkelige eksterne området. Den lokale nettverksgatewayen er objektet som holder de eksterne prefiksene, og forbindelsen refererer til begge gatewayene pluss en på forhånd delt nøkkel.

Det er en tredje forutsetning å holde styr på. GatewaySubnet er vert for de administrerte gatewayforekomstene, må ha nøyaktig det navnet, og for ikke-Basic-SKU-er forventes det å være minst /27.

Ingenting annet hører til i det subnettet, og en prefiksendring har ingen grunn til å røre det. Et prefiks som mangler i den lokale nettverksgatewayen, er utilgjengelig uansett hva forbindelsesstatusen sier, fordi gatewayen bare tilbyr de prefiksene den ble informert om da den forhandlet tunnelen. Derfor er symptomet asymmetrisk: tunnelen er oppe, sikkerhetstilknytningen er i orden, og ett subnett dukker aldri opp i trafikkvelgerne. Hvis ett eksternt område mangler mens naboene virker, slutt å se på tunnelen og les den lokale nettverksgatewayen.

Hvorfor det er forbindelsen som fjernes

Forbindelsesobjektet låser den forhandlede konfigurasjonen for hele levetiden. Derfor fjerner den dokumenterte prosedyren først forbindelsen, oppdaterer den lokale nettverksgatewayen og oppretter deretter forbindelsen på nytt med den samme delte nøkkelen. Gatewayforekomstene bygges ikke på nytt for en endring som bare gjelder prefikset, noe som begrenser avbruddet til nedrivingen av forbindelsen i stedet for en ny utrulling av gatewayen.

Den slettingen er avbruddet, så behandle den som en planlagt endring med en start og en forventet slutt i stedet for en rask redigering. I PowerShell er rekkefølgen kort: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, deretter Set-AzLocalNetworkGateway med det nye -AddressPrefix arrayet, deretter New-AzVirtualNetworkGatewayConnection med den samme -SharedKey og de samme gatewayene. Å gjenbruke nøkkelen er viktig, fordi den eksterne siden ikke konfigureres på nytt, og en ny nøkkel betyr koordinering med den som eier den eksterne enheten. Hvis et annet team drifter den enheten, avtal vinduet med dem før du fjerner noe.

Når selve gatewayen må bygges på nytt

Et andre svar som sirkulerer rundt dette problemet, sier at gatewayen må gjenopprettes og nøkkelen utveksles på nytt. Det er riktig for et annet sett med operasjoner: endring av gatewaytypen eller SKU-en, bytte mellom punkt-til-område og område-til-område, eller reparasjon av en gateway der selve konfigurasjonen er feil. Slike endringer endrer faktisk gatewayressursen, så en gjenoppbygging er virkelig nødvendig.

En gateway som er opprettet for punkt-til-område, kan ikke bare gis en område-til-område-forbindelse. Punkt-til-område-konfigurasjonen må fjernes og gatewayen gjenopprettes, noe som også gir en ny delt nøkkel og en ny klientpakke.

Punkt-til-område-pakken fortjener en egen merknad fordi den utløper. Portalen genererer en fil med kort levetid, så den praktiske tilnærmingen er å laste den ned én gang og distribuere den sammen med klientsertifikatet i stedet for å sende brukerne en portallink som vil være død når de klikker på den. For prefiksspørsmålet gjelder ingenting av dette. Å holde de to prosedyrene atskilt er hele disiplinen: prefikser er en endring på forbindelsesnivå, og gatewayegenskaper er en endring på gatewaynivå.

Les tilstanden, ikke portalens merke

Les tilstanden fra ressursen i stedet for fra merket i portalen. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 returnerer ConnectionStatus sammen med bytetellere for inn- og utgående trafikk, og det er tellerne som skiller en tunnel som er tilkoblet og ikke bærer noe, fra en som aldri ble etablert.

Tellere som slutter å øke midt i en overføring, peker på banen og ikke på autentiseringen. Tellere som ikke beveger seg i det hele tatt, peker på prefikssettet eller den delte nøkkelen.

Timere forklarer en klasse avbrudd som feilaktig tilskrives VPN-en. Lastbalansereren til Azure lukker inaktive strømmer etter den konfigurerte tidsavbruddet, fire minutter som standard da disse notatene ble skrevet og konfigurerbart oppover, så en OpenVPN-server på en VM uten keepalive kan falle hvert par minutter mens alt annet ser friskt ut. En gateway som plattformen restarter syklisk, kan også avbryte en VNet-forbindelse til en Web App, og den feilen ligger på plattformsiden og ikke i en klientkonfigurasjon. Tegnet er om avbruddet følger et fast intervall eller en endring du har gjort.

Hold de tre objektene og verdiene deres i én oppføring: adresserommet til det virtuelle nettverket, prefikslisten til den lokale nettverksgatewayen og referansen til forbindelsens delte nøkkel. PowerShell-artikkelen for område-til-område dokumenterer kommandoene for den lokale nettverksgatewayen og rekkefølgen de hører til i. Å sammenligne en prefiksendring med hukommelsen er måten en fungerende tunnel blir bygget på nytt to ganger.

Bekreft deretter i den rekkefølgen du endret: den lokale nettverksgatewayen viser den nye prefikslisten, forbindelsen er tilbake på Connected, og tellerne beveger seg når du sender trafikk til en vert i det nye området. Hvis det tredje trinnet feiler mens de to første går gjennom, har den eksterne siden ikke godtatt den nye trafikkvelgeren, og den eksterne enheten trenger den samsvarende fase 2-oppføringen. Det er en samtale med den andre enden av tunnelen, ikke en annen endring i Azure.