Zakaj dodajanje predpone Azure VPN prekine povezavo

Predpona, dodana napačnemu objektu Azure, ustvari povezavo, ki poroča Connected in ničesar ne posreduje, in to je najdražja vrsta napake v tem skladu. Vpleteni so trije viri in le eden od njih ima oddaljeni naslovni prostor: prehod virtualnega omrežja, lokalni omrežni prehod, ki opisuje oddaljeno stran, in povezava, ki ju poveže. Predpona pripada lokalnemu omrežnemu prehodu, povezavo je treba znova zgraditi, da sprememba začne veljati, sam prehod pa običajno ostane nedotaknjen. Vrstni red ni predmet pogajanj in portal prikaže le del njega.

Trije objekti, od katerih eden hrani predpono

Naslovni prostor virtualnega omrežja odgovarja na drugo vprašanje: kaj živi znotraj Azure. Dodajanje oddaljene predpone tam ne usmerja prometa tja, le širi prostor, za katerega platforma meni, da ga ima, kar se lahko zaleti v dejanski oddaljeni obseg. Lokalni omrežni prehod je objekt, ki hrani oddaljene predpone, povezava pa se sklicuje na oba prehoda in vnaprej skupni ključavnico.

Obstaja še tretji pridržek, ki ga velja imeti v mislih. GatewaySubnet gosti upravljane primerke prehoda, mora imeti točno to ime, pri vrstah SKU, ki niso Basic, pa se pričakuje, da je vsaj /27.

Nič drugega ne spada v to podomrežje in sprememba predpone se ga nima razloga dotakniti. Predpona, ki v lokalnem omrežnem prehodu manjka, je nedosegljiva ne glede na to, kaj pravi stanje povezave, ker prehod ponuja le tiste predpone, o katerih je bil obveščen pri pogajanju o tunelu. Zato je simptom asimetričen: tunel je vzpostavljen, varnostna povezava je v redu in eno podomrežje se nikoli ne pojavi v izbirnikih prometa. Če en oddaljeni obseg manjka, medtem ko sosednji delujejo, prenehajte gledati v tunel in preberite lokalni omrežni prehod.

Zakaj se odstrani prav povezava

Objekt povezave pritrdi dogovorjeno konfiguracijo za celotno življenjsko dobo. Zato dokumentirani postopek najprej odstrani povezavo, posodobi lokalni omrežni prehod in nato povezavo znova ustvari z istim skupnim ključem. Primerki prehoda se ne obnovijo za spremembo samo predpone, kar omeji prekinitev na razgradnjo povezave namesto na ponovno uvajanje prehoda.

Ta izbris je prekinitev, zato ga obravnavajte kot načrtovano spremembo z začetkom in pričakovanim koncem, ne kot hitro urejanje. V PowerShellu je zaporedje kratko: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, nato Set-AzLocalNetworkGateway z novim -AddressPrefix poljem, nato New-AzVirtualNetworkGatewayConnection z istim -SharedKey in istimi prehodi. Ponovna uporaba ključa je pomembna, ker se oddaljena stran ne prekonfigurira in nov ključ pomeni usklajevanje s tistim, ki ima oddaljeno napravo. Če to napravo upravlja druga ekipa, se z njo dogovorite o časovnem oknu, preden karkoli odstranite.

Kdaj je treba znova zgraditi sam prehod

Drugi odgovor, ki kroži okoli te težave, pravi, da je treba prehod znova ustvariti in ključ ponovno izmenjati. To velja za drug nabor operacij: spremembo vrste prehoda ali SKU, prehod med točko-in-lokacijo in lokacijo-in-lokacijo ali popravilo prehoda, katerega lastna konfiguracija je napačna. Takšne spremembe res spremenijo vir prehoda, zato je obnova resnično potrebna.

Prehodu, ustvarjenemu za točko-in-lokacijo, ni mogoče preprosto dodeliti povezave lokacija-in-lokacija. Konfiguracijo točke-in-lokacije je treba odstraniti in prehod znova ustvariti, kar ustvari tudi nov skupni ključ in nov odjemalski paket.

Paket točke-in-lokacije si zasluži svojo opombo, ker poteče. Portal ustvari datoteko s kratko življenjsko dobo, zato je praktični pristop prenesti jo enkrat in razdeliti skupaj z odjemalskim potrdilom, namesto da bi uporabnikom poslali portalno povezavo, ki bo mrtva, ko bodo kliknili. Za vprašanje predpone nič od tega ne velja. Ločevanje obeh postopkov je vsa disciplina: predpone so sprememba na ravni povezave, lastnosti prehoda pa sprememba na ravni prehoda.

Berite stanje, ne značke portala

Berite stanje iz vira, ne iz značke na portalu. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 vrne ConnectionStatus skupaj s števci vhodnih in izhodnih bajtov, in prav števci ločijo tunel, ki je povezan in ne prenaša ničesar, od tistega, ki se ni nikoli vzpostavil.

Števci, ki prenehajo naraščati sredi prenosa, kažejo na pot, ne na preverjanje pristnosti. Števci, ki se sploh ne premaknejo, kažejo na nabor predpon ali skupni ključ.

Časovniki pojasnjujejo razred prekinitev, ki se napačno pripisujejo VPN. Uravnavanje obremenitve v Azure zapre nedejavne tokove po nastavljenem časovnem omejitvi, privzeto štiri minute, ko so bile te opombe napisane, in ga je mogoče povečati, zato lahko strežnik OpenVPN na VM brez keepalive pade vsakih nekaj minut, medtem ko je vse drugo videti zdravo. Prehod, ki ga platforma ciklično znova zažene, lahko tudi prekine povezavo VNet z Web App, in ta napaka je na strani platforme in ne v odjemalski konfiguraciji. Namig je, ali prekinitev sledi stalnemu intervalu ali spremembi, ki ste jo naredili.

Hranite tri objekte in njihove vrednosti v enem zapisu: naslovni prostor virtualnega omrežja, seznam predpon lokalnega omrežnega prehoda in sklic na skupni ključ povezave. članek o PowerShellu za lokacijo-in-lokacijo dokumentira ukaze lokalnega omrežnega prehoda in vrstni red, kamor spadajo. Primerjava spremembe predpone s spominom je način, kako se delujoč tunel dvakrat znova zgradi.

Nato preverite v vrstnem redu, v katerem ste spreminjali: lokalni omrežni prehod prikazuje nov seznam predpon, povezava je znova Connected in števci se premaknejo, ko pošljete promet na gostitelja v novem obsegu. Če tretji korak spodleti, medtem ko prva dva uspeta, oddaljena stran ni sprejela novega izbirnika prometa in oddaljena naprava potrebuje ustrezni vnos faze 2. To je pogovor z drugim koncem tunela, ne še ena sprememba v Azure.