Kodėl pridėjus Azure VPN priešdėlį ryšys nutrūksta

Priešdėlis, pridėtas prie netinkamo Azure objekto, sukuria ryšį, kuris praneša Connected ir nieko neperduoda, ir tai yra brangiausia klaidos rūšis šiame kamine. Dalyvauja trys ištekliai, ir tik vienas jų valdo nuotolinę adresų erdvę: virtualaus tinklo šliuzas, vietinės tinklo tarpinės šliuzas, apibūdinantis tolimąją pusę, ir ryšys, kuris juos sujungia. Priešdėlis priklauso vietinės tinklo tarpinės šliuzui, ryšys turi būti atkurtas, kad pakeitimas įsigaliotų, o pats šliuzas paprastai paliekamas nepaliestas. Tvarka neaptariama, ir portalas rodo tik dalį jos.

Trys objektai, iš kurių vienas laiko priešdėlį

Virtualaus tinklo adresų erdvė atsako į kitą klausimą: kas gyvena Azure viduje. Nuotolinio priešdėlio pridėjimas ten nenukreipia srauto į jį, tik praplečia erdvę, kurią platforma laiko savo, ir tai gali susidurti su tikruoju nuotoliniu diapazonu. Vietinės tinklo tarpinės šliuzas yra objektas, kuris laiko nuotolinius priešdėlius, o ryšys nurodo abu šliuzus ir iš anksto bendrinamą raktą.

Yra ir trečia išlyga, kurią verta turėti omenyje. GatewaySubnet talpina valdomus šliuzo egzempliorius, turi turėti būtent šį pavadinimą, o ne Basic SKU atveju tikimasi, kad jis bus bent /27.

Niekas kitas nepriklauso tam potinkiui, ir priešdėlio pakeitimas neturi priežasties jo liesti. Vietinės tinklo tarpinės šliuze trūkstamas priešdėlis nepasiekiamas, kad ir ką sakytų ryšio būsena, nes šliuzas derėdamasis dėl tunelio siūlo tik tuos priešdėlius, apie kuriuos buvo informuotas. Todėl simptomas asimetriškas: tunelis pakeltas, saugos asociacija tvarkinga, ir vienas potinkis niekada neatsiranda srauto selektoriuose. Jei trūksta vieno nuotolinio diapazono, kol kaimynai veikia, nustokite žiūrėti į tunelį ir perskaitykite vietinės tinklo tarpinės šliuzą.

Kodėl pašalinamas būtent ryšys

Ryšio objektas užfiksuoja suderintą konfigūraciją visam savo gyvavimo laikui. Todėl dokumentuota procedūra pirmiausia pašalina ryšį, atnaujina vietinės tinklo tarpinės šliuzą ir tada iš naujo sukuria ryšį su tuo pačiu bendrinamu raktu. Šliuzo egzemplioriai neperkuriami vien tik priešdėlio pakeitimui, o tai apriboja prastovą iki ryšio išardymo, o ne šliuzo perkūrimo.

Tas trynimas ir yra prastova, todėl traktuokite jį kaip suplanuotą pakeitimą su pradžia ir numatoma pabaiga, o ne kaip greitą redagavimą. PowerShell tvarka trumpa: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, tada Set-AzLocalNetworkGateway su nauju -AddressPrefix masyvu, tada New-AzVirtualNetworkGatewayConnection su tuo pačiu -SharedKey ir tais pačiais šliuzais. Rakto pakartotinis naudojimas svarbus, nes tolimoji pusė nekonfigūruojama iš naujo, o naujas raktas reiškia derinimą su tuo, kas valdo nuotolinį įrenginį. Jei tą įrenginį valdo kita komanda, suderinkite laiko langą su ja prieš ką nors šalindami.

Kada reikia perkurti patį šliuzą

Antras atsakymas, kuris sukasi aplink šią problemą, sako, kad šliuzą reikia sukurti iš naujo ir raktą dar kartą apsikeisti. Tai teisinga kitam operacijų rinkiniui: šliuzo tipo ar SKU pakeitimui, perėjimui tarp point-to-site ir site-to-site, arba šliuzo, kurio pati konfigūracija neteisinga, taisymui. Tokie pakeitimai iš tiesų keičia šliuzo išteklių, tad perkūrimas tikrai būtinas.

Šliuzui, sukurtam point-to-site, negalima tiesiog duoti site-to-site ryšio. Point-to-site konfigūraciją reikia pašalinti ir šliuzą sukurti iš naujo, o tai taip pat sukuria naują bendrinamą raktą ir naują kliento paketą.

Point-to-site paketas nusipelno atskiros pastabos, nes jo galiojimas baigiasi. Portalas sukuria trumpo galiojimo failą, todėl praktiškas būdas yra jį vieną kartą atsisiųsti ir platinti kartu su kliento sertifikatu, o ne siųsti naudotojams portalo nuorodą, kuri bus mirusi, kai jie spustelės. Priešdėlio klausimui niekas iš to netinka. Dviejų procedūrų atskyrimas yra visa disciplina: priešdėliai yra ryšio lygio pakeitimas, o šliuzo savybės yra šliuzo lygio pakeitimas.

Skaitykite būseną, o ne portalo ženklelį

Skaitykite būseną iš ištekliaus, o ne iš portalo ženklelio. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 grąžina ConnectionStatus kartu su įeinančių ir išeinančių baitų skaitikliais, ir būtent skaitikliai atskiria prisijungusį, bet nieko neperduodantį tunelį nuo to, kuris niekada nebuvo nustatytas.

Skaitikliai, kurie nustoja didėti perdavimo viduryje, rodo kelią, o ne autentifikavimą. Skaitikliai, kurie visiškai nejuda, rodo priešdėlių rinkinį arba bendrinamą raktą.

Laikmačiai paaiškina vieną atsijungimų klasę, kuri klaidingai priskiriama VPN. Azure apkrovos balansuotojas uždaro neaktyvius srautus po sukonfigūruoto laiko limito, numatytai keturios minutės, kai buvo rašomos šios pastabos, ir jį galima didinti, todėl OpenVPN serveris VM be keepalive gali kristi kas kelias minutes, kol visa kita atrodo sveikai. Šliuzas, kurį platforma cikliškai perkrauna, taip pat gali nutraukti VNet ryšį su Web App, ir ta nesėkmė yra platformos pusėje, o ne kliento konfigūracijoje. Požymis yra tai, ar atsijungimas seka fiksuotą intervalą, ar jūsų atliktą pakeitimą.

Laikykite tris objektus ir jų vertes viename įraše: virtualaus tinklo adresų erdvę, vietinės tinklo tarpinės šliuzo priešdėlių sąrašą ir nuorodą į bendrinamą ryšio raktą. site-to-site PowerShell straipsnis dokumentuoja vietinės tinklo tarpinės šliuzo komandas ir tvarką, kuriai jos priklauso. Priešdėlio pakeitimo palyginimas su atmintimi yra būdas, kuriuo veikiantis tunelis perkuriamas du kartus.

Tada patikrinkite ta tvarka, kuria keitėte: vietinės tinklo tarpinės šliuzas rodo naują priešdėlių sąrašą, ryšys vėl Connected, o skaitikliai juda, kai siunčiate srautą į naujo diapazono prieglobą. Jei trečias žingsnis nepavyksta, kol pirmieji du praeina, tolimoji pusė nepriėmė naujo srauto selektoriaus, o nuotoliniam įrenginiui reikia atitinkamo 2-ojo etapo įrašo. Tai pokalbis su kitu tunelio galu, o ne dar vienas pakeitimas Azure.