Kvifor det å leggje til eit Azure VPN-prefiks bryt sambandet

Eit prefiks som blir lagt til på feil Azure-objekt, gjev eit samband som rapporterer Connected og ikkje videresender noko, og det er den dyraste typen feil i denne stabelen. Tre ressursar er involverte, og berre éin av dei eig det eksterne adresserommet: den virtuelle nettverksporten, den lokale nettverksporten som skildrar den eksterne sida, og sambandet som knyter dei saman. Prefikset høyrer til den lokale nettverksporten, sambandet må byggjast på nytt for at endringa skal tre i kraft, og sjølve porten blir vanlegvis ståande urørt. Rekkjefølgja er ikkje til forhandling, og portalen viser berre ein del av henne.

Tre objekt, der eitt held prefikset

Adresserommet til det virtuelle nettverket svarar på eit anna spørsmål: kva som bur inne i Azure. Å leggje til eit eksternt prefiks der ruter ikkje trafikk dit, det utvidar berre rommet plattforma meiner ho eig, noko som kan kollidere med det verkelege eksterne området. Den lokale nettverksporten er objektet som held dei eksterne prefiksa, og sambandet viser til begge portane pluss ein på førehand delt nøkkel.

Det er eit tredje førehald å halde styr på. GatewaySubnet er vert for dei administrerte portinstansane, må ha nøyaktig det namnet, og for ikkje-Basic-SKU-ar er det venta at det er minst /27.

Ingenting anna høyrer til i det subnettet, og ei prefiksendring har inga grunn til å røre det. Eit prefiks som manglar i den lokale nettverksporten, er utilgjengeleg uansett kva sambandsstatusen seier, fordi porten berre tilbyr dei prefiksa han vart informert om då han forhandla tunnelen. Difor er symptomet asymmetrisk: tunnelen er oppe, tryggleikstilknytinga er i orden, og eitt subnett dukkar aldri opp i trafikkveljarane. Viss eitt eksternt område manglar medan naboane verkar, slutt å sjå på tunnelen og les den lokale nettverksporten.

Kvifor det er sambandet som blir fjerna

Sambandsobjektet låser den forhandla konfigurasjonen for heile levetida. Difor fjernar den dokumenterte prosedyren først sambandet, oppdaterer den lokale nettverksporten og opprettar deretter sambandet på nytt med den same delte nøkkelen. Portinstansane blir ikkje bygde på nytt for ei endring som berre gjeld prefikset, noko som avgrensar avbrotet til nedrivinga av sambandet i staden for ein ny utrulling av porten.

Den slettinga er avbrotet, så handsam henne som ei planlagd endring med ein start og ein venta slutt i staden for ei rask redigering. I PowerShell er rekkjefølgja kort: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, deretter Set-AzLocalNetworkGateway med det nye -AddressPrefix arrayet, deretter New-AzVirtualNetworkGatewayConnection med den same -SharedKey og dei same portane. Å bruke nøkkelen om att er viktig, fordi den eksterne sida ikkje blir konfigurert på nytt, og ein ny nøkkel tyder koordinering med den som eig den eksterne eininga. Viss eit anna team driftar den eininga, avtal vindauga med dei før du fjernar noko.

Når sjølve porten må byggjast på nytt

Eit andre svar som sirkulerer rundt dette problemet, seier at porten må opprettast på nytt og nøkkelen utvekslast på nytt. Det er rett for eit anna sett med operasjonar: endring av porttypen eller SKU-en, byte mellom punkt-til-område og område-til-område, eller reparasjon av ein port der sjølve konfigurasjonen er feil. Slike endringar endrar faktisk portressursen, så ein nybygg er verkeleg naudsynt.

Ein port som er oppretta for punkt-til-område, kan ikkje berre få eit område-til-område-samband. Punkt-til-område-konfigurasjonen må fjernast og porten opprettast på nytt, noko som også gjev ein ny delt nøkkel og ein ny klientpakke.

Punkt-til-område-pakken fortener ei eiga merknad fordi han går ut. Portalen genererer ei fil med kort levetid, så den praktiske tilnærminga er å laste henne ned éin gong og distribuere henne saman med klientsertifikatet i staden for å sende brukarane ei portallenkje som vil vere daud når dei klikkar på henne. For prefiksspørsmålet gjeld ingenting av dette. Å halde dei to prosedyrane åtskilde er heile disiplinen: prefiks er ei endring på sambandsnivå, og portegenskapar er ei endring på portnivå.

Les tilstanden, ikkje portalmerket

Les tilstanden frå ressursen i staden for frå merket i portalen. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 returnerer ConnectionStatus saman med byteteljarar for inn- og utgåande trafikk, og det er teljarane som skil ein tunnel som er tilkopla og ikkje ber noko, frå ein som aldri vart etablert.

Teljarar som sluttar å auke midt i ei overføring, peikar på banen og ikkje på autentiseringa. Teljarar som ikkje rører seg i det heile, peikar på prefikssettet eller den delte nøkkelen.

Timar forklarar ein klasse avbrot som feilaktig blir tilskrivne VPN-en. Lastbalanseraren til Azure lukkar inaktive straumar etter den konfigurerte tidsavbrotet, fire minutt som standard då desse notata vart skrivne og konfigurerbart oppover, så ein OpenVPN-server på ein VM utan keepalive kan falle kvart par minutt medan alt anna ser friskt ut. Ein port som plattforma startar på nytt syklisk, kan også avbryte eit VNet-samband til ein Web App, og den feilen ligg på plattformsida og ikkje i ein klientkonfigurasjon. Teiknet er om avbrotet følgjer eit fast intervall eller ei endring du har gjort.

Hald dei tre objekta og verdiane deira i éin oppføring: adresserommet til det virtuelle nettverket, prefikslista til den lokale nettverksporten og referansen til den delte nøkkelen til sambandet. PowerShell-artikkelen for område-til-område dokumenterer kommandoane for den lokale nettverksporten og rekkjefølgja dei høyrer til i. Å samanlikne ei prefiksendring med minnet er måten ein fungerande tunnel blir bygd på nytt to gonger.

Stadfest deretter i den rekkjefølgja du endra: den lokale nettverksporten viser den nye prefikslista, sambandet er tilbake på Connected, og teljarane rører seg når du sender trafikk til ein vert i det nye området. Viss det tredje steget feilar medan dei to første går gjennom, har den eksterne sida ikkje godteke den nye trafikkveljaren, og den eksterne eininga treng den samsvarande fase 2-oppføringa. Det er ein samtale med den andre enden av tunnelen, ikkje ei anna endring i Azure.