Kāpēc Azure VPN prefiksa pievienošana pārtrauc savienojumu

Nepareizajam Azure objektam pievienots prefikss rada savienojumu, kas ziņo Connected un neko neuztur, un tas ir visdārgākais kļūdas veids šajā stekā. Iesaistīti trīs resursi, un tikai viens no tiem pārvalda attālo adrešu telpu: virtuālā tīkla vārteja, vietējā tīkla vārteja, kas apraksta tālo pusi, un savienojums, kas tās savieno. Prefikss pieder vietējā tīkla vārtejai, savienojums ir jāpārbūvē, lai izmaiņas stātos spēkā, un pati vārteja parasti tiek atstāta neskarta. Secība nav apspriežama, un portāls parāda tikai daļu no tās.

Trīs objekti, no kuriem viens glabā prefiksu

Virtuālā tīkla adrešu telpa atbild uz citu jautājumu: kas dzīvo Azure iekšienē. Attālā prefiksa pievienošana tur nenovirza trafiku uz to, tā tikai paplašina telpu, ko platforma uzskata par savu, un tas var sadurties ar reālo attālo diapazonu. Vietējā tīkla vārteja ir objekts, kas glabā attālos prefiksus, un savienojums atsaucas uz abām vārtejām un iepriekš koplietotu atslēgu.

Ir arī trešais nosacījums, ko vērts paturēt prātā. GatewaySubnet mitina pārvaldītos vārtejas gadījumus, tam jābūt tieši ar šo nosaukumu, un ne-Basic SKU tiek gaidīts vismaz /27.

Nekas cits nepieder pie šī apakštīkla, un prefiksa maiņai nav iemesla to aiztikt. Vietējā tīkla vārtejā trūkstošais prefikss nav sasniedzams, lai ko teiktu savienojuma statuss, jo vārteja, apspriežot tuneli, piedāvā tikai tos prefiksus, par kuriem tā tika informēta. Tāpēc simptoms ir asimetrisks: tunelis ir augšā, drošības asociācija ir kārtībā, un viens apakštīkls nekad neparādās trafika selektoros. Ja trūkst viena attālā diapazona, kamēr kaimiņi darbojas, pārstājiet skatīties uz tuneli un izlasiet vietējā tīkla vārteju.

Kāpēc tiek noņemts tieši savienojums

Savienojuma objekts fiksē apspriesto konfigurāciju visā tā darbības laikā. Tāpēc dokumentētā procedūra vispirms noņem savienojumu, atjaunina vietējā tīkla vārteju un pēc tam no jauna izveido savienojumu ar to pašu koplietoto atslēgu. Vārtejas gadījumi netiek pārbūvēti tikai prefiksa maiņas dēļ, kas ierobežo pārtraukumu ar savienojuma nojaukšanu, nevis vārtejas atkārtotu izvietošanu.

Šī dzēšana ir pārtraukums, tāpēc izturieties pret to kā pret plānotu izmaiņu ar sākumu un gaidāmu beigām, nevis kā pret ātru labojumu. PowerShell secība ir īsa: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, tad Set-AzLocalNetworkGateway ar jauno -AddressPrefix masīvu, tad New-AzVirtualNetworkGatewayConnection ar to pašu -SharedKey un tām pašām vārtejām. Atslēgas atkārtota izmantošana ir svarīga, jo tālā puse netiek pārkonfigurēta un jauna atslēga nozīmē koordināciju ar to, kam pieder attālā ierīce. Ja šo ierīci pārvalda cita komanda, vienojieties par laika logu ar to, pirms kaut ko noņemat.

Kad pati vārteja ir jāpārbūvē

Otra atbilde, kas cirkulē ap šo problēmu, saka, ka vārteja ir jāizveido no jauna un atslēga jāapmaina vēlreiz. Tas ir pareizi citai darbību kopai: vārtejas tipa vai SKU maiņai, pārejai starp point-to-site un site-to-site, vai tādas vārtejas labošanai, kuras pašas konfigurācija ir nepareiza. Šādas izmaiņas patiešām maina vārtejas resursu, tāpēc pārbūve patiešām ir nepieciešama.

Vārtejai, kas izveidota point-to-site, nevar vienkārši piešķirt site-to-site savienojumu. Point-to-site konfigurācija ir jānoņem un vārteja jāizveido no jauna, kas arī rada jaunu koplietoto atslēgu un jaunu klienta pakotni.

Point-to-site pakotne ir pelnījusi atsevišķu piezīmi, jo tai beidzas derīgums. Portāls ģenerē failu ar īsu darbības laiku, tāpēc praktiskā pieeja ir to vienreiz lejupielādēt un izplatīt kopā ar klienta sertifikātu, nevis sūtīt lietotājiem portāla saiti, kas būs mirusi, kad viņi uzklikšķinās. Prefiksa jautājumam nekas no tā neattiecas. Abu procedūru šķiršana ir visa disciplīna: prefiksi ir savienojuma līmeņa izmaiņa, un vārtejas īpašības ir vārtejas līmeņa izmaiņa.

Lasiet stāvokli, nevis portāla žetonu

Lasiet stāvokli no resursa, nevis no portāla žetona. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 atgriež ConnectionStatus kopā ar ienākošo un izejošo baitu skaitītājiem, un tieši skaitītāji atšķir pieslēgtu, bet neko nenesošu tuneli no tāda, kas nekad netika izveidots.

Skaitītāji, kas pārtrauc pieaugt pārsūtīšanas vidū, norāda uz ceļu, nevis uz autentifikāciju. Skaitītāji, kas nemaz nekustas, norāda uz prefiksu kopu vai koplietoto atslēgu.

Taimeri izskaidro vienu atslēgšanās klasi, kas tiek kļūdaini attiecināta uz VPN. Azure slodzes līdzsvarotājs aizver neaktīvās plūsmas pēc konfigurētā taimauta, pēc noklusējuma četras minūtes, kad tika rakstītas šīs piezīmes, un to var palielināt, tāpēc OpenVPN serveris VM bez keepalive var krist ik pēc dažām minūtēm, kamēr viss pārējais izskatās vesels. Vārteja, ko platforma cikliski pārstartē, arī var pārtraukt VNet savienojumu ar Web App, un šī kļūme ir platformas pusē, nevis klienta konfigurācijā. Pazīme ir tā, vai atslēgšanās seko fiksētam intervālam vai jūsu veiktajai izmaiņai.

Turiet trīs objektus un to vērtības vienā ierakstā: virtuālā tīkla adrešu telpu, vietējā tīkla vārtejas prefiksu sarakstu un atsauci uz savienojuma koplietoto atslēgu. site-to-site PowerShell raksts dokumentē vietējā tīkla vārtejas komandas un secību, pie kuras tās pieder. Prefiksa maiņas salīdzināšana ar atmiņu ir veids, kā strādājošs tunelis tiek pārbūvēts divreiz.

Pēc tam pārbaudiet tādā secībā, kādā mainījāt: vietējā tīkla vārteja rāda jauno prefiksu sarakstu, savienojums atkal ir Connected, un skaitītāji kustas, kad sūtāt trafiku uz jaunā diapazona resursdatoru. Ja trešais solis neizdodas, kamēr pirmie divi iztur, tālā puse nav pieņēmusi jauno trafika selektoru, un attālajai ierīcei ir vajadzīgs atbilstošais 2. fāzes ieraksts. Tā ir saruna ar tuneli otrā galā, nevis vēl viena izmaiņa Azure.