Waarom die byvoeging van ’n Azure VPN-voorvoegsel die verbinding laat val

’n Voorvoegsel wat op die verkeerde Azure-objek bygevoeg word, lewer ’n verbinding wat Connected rapporteer en niks aanstuur nie, en dit is die duurste soort fout in hierdie stapel. Drie hulpbronne is betrokke en net een van hulle besit die afgeleë adresruimte: die virtuele netwerkpoort, die plaaslike netwerkpoort wat die ander kant beskryf, en die verbinding wat hulle verbind. Die voorvoegsel hoort by die plaaslike netwerkpoort, die verbinding moet herbou word voordat die verandering in werking tree, en die poort self word gewoonlik alleen gelaat. Die volgorde is nie onderhandelbaar nie, en die portaal wys net ’n deel daarvan.

Drie objekte, waarvan een die voorvoegsel hou

Die virtuele netwerk-adresruimte beantwoord ’n ander vraag: wat binne Azure leef. Om ’n afgeleë voorvoegsel daar by te voeg, stuur nie verkeer daarheen nie; dit verbreed net die ruimte wat die platform dink hy besit, wat met die werklike afgeleë reeks kan bots. Die plaaslike netwerkpoort is die objek wat die afgeleë voorvoegsels hou, en die verbinding verwys na beide poorte plus ’n vooraf gedeelde sleutel.

Daar is ’n derde reservering om reg te hou. GatewaySubnet huisves die bestuurde poortinstansies, moet presies daardie naam dra, en vir nie-Basiese SKU's word daar verwag dat dit ten minste ’n /27 is.

Niks anders hoort in daardie subnet nie, en ’n voorvoegselverandering het geen rede om dit aan te raak nie. ’n Voorvoegsel wat by die plaaslike netwerkpoort ontbreek, is onbereikbaar ongeag wat die verbindingstatus sê, want die poort bied net die voorvoegsels aan waarvan hy vertel is wanneer hy die tonnel onderhandel. Dit is waarom die simptoom asimmetries is: die tonnel is op, die sekuriteitsassosiasie is reg, en een subnet verskyn nooit in die verkeerskeurders nie. As ’n enkele afgeleë reeks ontbreek terwyl sy bure werk, moet jy ophou om na die tonnel te kyk en die plaaslike netwerkpoort lees.

Waarom dit die verbinding is wat verwyder word

Die verbindingsobjek pen die onderhandelde konfigurasie vir sy leeftyd vas. Daarom verwyder die gedokumenteerde prosedure eers die verbinding, werk die plaaslike netwerkpoort by en herskep dan die verbinding met dieselfde gedeelde sleutel. Die poortinstansies word nie vir ’n suiwer voorvoegselverandering herbou nie, wat die onderbreking beperk tot die verbinding se aftakeling in plaas van ’n herontplooiing van die poort.

Daardie skrapping is die onderbreking, so behandel dit as ’n geskeduleerde verandering met ’n begin en ’n verwagte einde eerder as ’n vinnige wysiging. In PowerShell is die volgorde kort: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, dan Set-AzLocalNetworkGateway met die nuwe -AddressPrefix skikking, dan New-AzVirtualNetworkGatewayConnection met dieselfde -SharedKey en dieselfde poorte. Om die sleutel te hergebruik maak saak, want die ander kant word nie herkonfigureer nie en ’n nuwe sleutel beteken koördinering met wie ook al die afgeleë toestel besit. As ’n ander span daardie toestel bestuur, stem die venster met hulle af voordat jy enigiets verwyder.

Wanneer die poort self herbou moet word

’n Tweede antwoord wat rondom hierdie probleem sweef, sê die poort moet herskep en die sleutel heruitgeruil word. Dit is korrek vir ’n ander stel bewerkings: die verandering van die poorttipe of SKU, die verskuiwing tussen punt-tot-punt en werf-tot-werf, of die herstel van ’n poort wie se eie konfigurasie verkeerd is. Daardie veranderinge wysig wel die poorthulpbron, so ’n herbou is werklik nodig.

’n Poort wat vir punt-tot-punt geskep is, kan nie bloot ’n werf-tot-werf-verbinding kry nie. Die punt-tot-punt-konfigurasie moet verwyder en die poort herskep word, wat ook ’n nuwe gedeelde sleutel en ’n nuwe kliëntpakket lewer.

Die punt-tot-punt-pakket verdien sy eie nota omdat dit verval. Die portaal genereer ’n lêer met ’n kort leeftyd, so die praktiese benadering is om dit een keer af te laai en saam met die kliëntsertifikaat te versprei eerder as om gebruikers ’n portaal-skakel te stuur wat dood sal wees teen die tyd dat hulle dit klik. Vir die voorvoegselvraag geld niks hiervan nie. Om die twee prosedures apart te hou, is die hele dissipline: voorvoegsels is ’n verandering op verbindingsvlak, en poorteienskappe is ’n verandering op poortvlak.

Lees die toestand, nie die portaal-kenteken nie

Lees die toestand uit die hulpbron eerder as uit die kenteken in die portaal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 gee ConnectionStatus saam met inkomende en uitgaande grepe-tellers, en dit is die tellers wat ’n tonnel wat verbind is maar niks dra nie, onderskei van een wat nooit tot stand gekom het nie.

Tellers wat in die middel van ’n oordrag ophou toeneem, dui op die pad eerder as op verifikasie. Tellers wat glad nie beweeg nie, dui op die voorvoegselversameling of die gedeelde sleutel.

Tydhouers verduidelik ’n klas afskakelings wat verkeerdelik aan die VPN toegeskryf word. Azure se lasbalanseerder sluit ledige strome na sy gekonfigureerde tydsperdatum, vier minute by verstek toe hierdie notas geskryf is en opwaarts verstelbaar, so ’n OpenVPN-bediener op ’n VM sonder keepalive kan elke paar minute laat val terwyl alles anders gesond lyk. ’n Poort wat die platform siklus, kan ook ’n VNet-verbinding na ’n Web App onderbreek, en daardie fout lê aan die platformkant eerder as in ’n kliëntkonfigurasie. Die aanduiding is of die afskakeling ’n vaste interval volg of ’n verandering wat jy gemaak het.

Hou die drie objekte en hulle waardes in een rekord: die virtuele netwerk-adresruimte, die plaaslike netwerkpoort se voorvoegsellys, en die verbinding se verwysing na die gedeelde sleutel. Die werf-tot-werf PowerShell-artikel dokumenteer die plaaslike netwerkpoort-opdragte en die volgorde waarin hulle hoort. ’n Voorvoegselverandering wat teen die geheue vergelyk word, is hoe ’n werkende tonnel twee keer herbou word.

Verifieer dan in die volgorde waarin jy verander het: die plaaslike netwerkpoort wys die nuwe voorvoegsellys, die verbinding is terug op Connected, en die tellers beweeg wanneer jy verkeer na ’n gasheer in die nuwe reeks stuur. As die derde stap misluk terwyl die eerste twee slaag, het die ander kant nie die nuwe verkeerskeurder aanvaar nie en het die afgeleë toestel die ooreenstemmende fase 2-inskrywing nodig. Dit is ’n gesprek met die ander kant van die tonnel, nie nog ’n verandering in Azure nie.