Pse shtimi i një prefiksi Azure VPN ndërpret lidhjen

Një prefiks i shtuar në objektin e gabuar të Azure prodhon një lidhje që raporton Connected dhe nuk përcjell asgjë, dhe ky është lloji më i kushtueshëm i gabimit në këtë stivë. Janë të përfshira tre burime dhe vetëm njëri prej tyre zotëron hapësirën e adresave të largët: porta e rrjetit virtual, porta e rrjetit lokal që përshkruan anën e largët dhe lidhja që i bashkon. Prefiksi i përket portës së rrjetit lokal, lidhja duhet të rindërtohet që ndryshimi të hyjë në fuqi, dhe vetë porta zakonisht lihet e paprekur. Rendi nuk është i negociueshëm, dhe portali shfaq vetëm një pjesë të tij.

Tre objekte, njëri prej të cilëve mban prefiksin

Hapësira e adresave e rrjetit virtual i përgjigjet një pyetjeje tjetër: çfarë jeton brenda Azure. Shtimi i një prefiksi të largët atje nuk e drejton trafikun atje, thjesht zgjeron hapësirën që platforma mendon se zotëron, gjë që mund të përplaset me gamën reale të largët. Porta e rrjetit lokal është objekti që mban prefikset e largët, dhe lidhja referon të dyja portat plus një çelës të përbashkët paraprakisht.

Ka edhe një rezervë të tretë për t'u mbajtur mend. GatewaySubnet strehon instancat e menaxhuara të portës, duhet të mbajë saktësisht atë emër, dhe për SKU-të që nuk janë Basic pritet të jetë të paktën /27.

Asgjë tjetër nuk i përket asaj nënrrjete, dhe një ndryshim prefiksi nuk ka arsye ta prekë. Një prefiks që mungon në portën e rrjetit lokal është i paarritshëm çfarëdo që thotë statusi i lidhjes, sepse porta ofron vetëm prefikset për të cilat është informuar kur negocion tunelin. Prandaj simptoma është asimetrike: tuneli është lart, shoqata e sigurisë është në rregull, dhe një nënrrjet nuk shfaqet kurrë në përzgjedhësit e trafikut. Nëse mungon një gamë e vetme e largët ndërsa fqinjët funksionojnë, ndaloni së shikuari tunelin dhe lexoni portën e rrjetit lokal.

Pse hiqet pikërisht lidhja

Objekti i lidhjes fikson konfigurimin e negociuar për gjithë jetën e tij. Prandaj procedura e dokumentuar heq fillimisht lidhjen, përditëson portën e rrjetit lokal dhe më pas rikrijon lidhjen me të njëjtin çelës të përbashkët. Instancat e portës nuk rindërtohen për një ndryshim vetëm të prefiksit, gjë që e kufizon ndërprerjen në çmontimin e lidhjes në vend të një rivendosjeje të portës.

Ai fshirje është ndërprerja, prandaj trajtojeni si një ndryshim të planifikuar me fillim dhe fund të pritur në vend të një redaktimi të shpejtë. Në PowerShell sekuenca është e shkurtër: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, pastaj Set-AzLocalNetworkGateway me -AddressPrefix grupin e ri, pastaj New-AzVirtualNetworkGatewayConnection me të njëjtin -SharedKey dhe të njëjtat porta. Ripërdorimi i çelësit ka rëndësi, sepse ana e largët nuk rikonfigurohet dhe një çelës i ri do të thotë koordinim me atë që zotëron pajisjen e largët. Nëse një ekip tjetër e drejton atë pajisje, bini dakord për dritaren me ta përpara se të hiqni ndonjë gjë.

Kur duhet rindërtuar vetë porta

Një përgjigje e dytë që qarkullon rreth këtij problemi thotë se porta duhet rikrijuar dhe çelësi duhet shkëmbyer përsëri. Kjo është e saktë për një grup tjetër veprimesh: ndryshimi i llojit të portës ose i SKU-së, kalimi midis pikë-në-sajt dhe sajt-në-sajt, ose riparimi i një porte, konfigurimi i së cilës është i gabuar. Ndryshime të tilla me të vërtetë ndryshojnë burimin e portës, prandaj rindërtimi është vërtet i nevojshëm.

Një porte të krijuar për pikë-në-sajt nuk mund t'i jepet thjesht një lidhje sajt-në-sajt. Konfigurimi pikë-në-sajt duhet hequr dhe porta rikrijuar, gjë që prodhon gjithashtu një çelës të ri të përbashkët dhe një paketë të re klienti.

Paketa pikë-në-sajt meriton një shënim të vetin sepse skadon. Portali gjeneron një skedar me jetë të shkurtër, prandaj qasja praktike është ta shkarkoni një herë dhe ta shpërndani bashkë me certifikatën e klientit në vend që t'u dërgoni përdoruesve një lidhje portali që do të jetë e vdekur kur të klikojnë. Për çështjen e prefiksit, asgjë nga këto nuk vlen. Mbajtja e dy procedurave të ndara është e gjithë disiplina: prefikset janë një ndryshim në nivel lidhjeje, dhe vetitë e portës janë një ndryshim në nivel porte.

Lexoni gjendjen, jo distinktivin e portalit

Lexoni gjendjen nga burimi në vend të distinktivit në portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 kthen ConnectionStatus bashkë me numëruesit e bajtëve hyrës dhe dalës, dhe numëruesit janë ata që ndajnë një tunel të lidhur që nuk mbart asgjë nga një që nuk u vendos kurrë.

Numëruesit që ndalojnë së rrituri në mes të një transferimi tregojnë shtegun dhe jo vërtetimin. Numëruesit që nuk lëvizin fare tregojnë grupin e prefikseve ose çelësin e përbashkët.

Kohëmatësit shpjegojnë një klasë shkëputjesh që i atribuohen gabimisht VPN-së. Balancuesi i ngarkesës i Azure mbyll rrjedhat joaktive pas afatit të konfiguruar, katër minuta si parazgjedhje kur u shkruan këto shënime dhe i konfigurueshëm lart, prandaj një server OpenVPN në një VM pa keepalive mund të bjerë çdo pak minuta ndërsa gjithçka tjetër duket e shëndoshë. Një portë që platforma e rinis në cikle mund gjithashtu të ndërpresë një lidhje VNet me një Web App, dhe ai dështim është në anën e platformës dhe jo në një konfigurim klienti. Treguesi është nëse shkëputja ndjek një interval fiks apo një ndryshim që keni bërë.

Mbani tre objektet dhe vlerat e tyre në një regjistër të vetëm: hapësirën e adresave të rrjetit virtual, listën e prefikseve të portës së rrjetit lokal dhe referencën për çelësin e përbashkët të lidhjes. artikulli PowerShell për sajt-në-sajt dokumenton komandat e portës së rrjetit lokal dhe rendin të cilit i përkasin. Krahasimi i një ndryshimi prefiksi me kujtesën është mënyra se si një tunel funksional rindërtohet dy herë.

Më pas verifikoni sipas rendit në të cilin keni ndryshuar: porta e rrjetit lokal shfaq listën e re të prefikseve, lidhja është përsëri Connected, dhe numëruesit lëvizin kur dërgoni trafik në një strehues në gamën e re. Nëse hapi i tretë dështon ndërsa dy të parët kalojnë, ana e largët nuk e ka pranuar përzgjedhësin e ri të trafikut dhe pajisja e largët ka nevojë për hyrjen përkatëse të fazës 2. Ky është një bisedë me skajin tjetër të tunelit, jo një ndryshim tjetër në Azure.