Miks Azure VPN-i prefiksi lisamine ühenduse katkestab

Valele Azure'i objektile lisatud prefiks loob ühenduse, mis teatab Connected ja ei edasta midagi, ning see on selle virna kalleim vealiik. Kaasatud on kolm ressurssi ja ainult üks neist omab kauget aadressiruumi: virtuaalvõrgu värav, kaughõlma kirjeldav kohalik võrguvärav ja neid ühendav ühendus. Prefiks kuulub kohalikule võrguväravale, ühendus tuleb muudatuse jõustumiseks uuesti üles ehitada ja värav ise jääb tavaliselt puutumata. Järjekord ei ole läbiräägitav ja portaal näitab sellest ainult osa.

Kolm objekti, millest üks hoiab prefiksit

Virtuaalvõrgu aadressiruum vastab teisele küsimusele: mis elab Azure'i sees. Kauge prefiksi lisamine sinna ei suuna liiklust sinna, vaid ainult laiendab ruumi, mida platvorm arvab endale kuuluvat, mis võib tegeliku kauge vahemikuga kokku põrgata. Kohalik võrguvärav on objekt, mis hoiab kaugeid prefikseid, ja ühendus viitab mõlemale väravale pluss eelnevalt jagatud võtmele.

On veel kolmas reservatsioon, mida meeles pidada. GatewaySubnet majutab hallatavaid värava eksemplare, peab kandma täpselt seda nime ja mitte-Basic SKU-de puhul eeldatakse, et see on vähemalt /27.

Midagi muud sinna alamvõrku ei kuulu ja prefiksi muutmisel pole põhjust seda puutuda. Kohalikus võrguväravas puuduv prefiks on kättesaamatu, ükskõik mida ühenduse olek ütleb, sest värav pakub tunnelit läbi rääkides ainult neid prefikseid, millest talle teatati. Seetõttu on sümptom asümmeetriline: tunnel on üleval, turbeseos on korras ja üks alamvõrk ei ilmu kunagi liikluse selektorites. Kui üks kauge vahemik puudub, samal ajal kui naabrid töötavad, lõpetage tunneli vaatamine ja lugege kohalikku võrguväravat.

Miks eemaldatakse just ühendus

Ühenduse objekt kinnitab läbi räägitud konfiguratsiooni kogu oma eluea jooksul. Seetõttu eemaldab dokumenteeritud protseduur kõigepealt ühenduse, uuendab kohalikku võrguväravat ja loob seejärel ühenduse uuesti sama jagatud võtmega. Värava eksemplare ei ehitata ainult prefiksi muutmiseks uuesti üles, mis piirab katkestuse ühenduse lammutamisega, mitte värava uuesti juurutamisega.

See kustutamine on katkestus, seega käsitlege seda planeeritud muudatusena, millel on algus ja oodatav lõpp, mitte kiire redigeerimisena. PowerShellis on järjestus lühike: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, seejärel Set-AzLocalNetworkGateway uue -AddressPrefix massiiviga, seejärel New-AzVirtualNetworkGatewayConnection sama -SharedKey ja samade väravatega. Võtme uuesti kasutamine on oluline, sest kaughõlma ei konfigureerita ümber ja uus võti tähendab kooskõlastamist sellega, kes kauget seadet omab. Kui seda seadet haldab teine meeskond, leppige akna suhtes nendega kokku enne, kui midagi eemaldate.

Millal tuleb värav ise uuesti üles ehitada

Teine vastus, mis selle probleemi ümber ringleb, ütleb, et värav tuleb uuesti luua ja võti uuesti vahetada. See kehtib teistsuguse toimingute kogumi puhul: värava tüübi või SKU muutmine, üleminek punkt-koht ja koht-koht vahel või värava parandamine, mille enda konfiguratsioon on vale. Sellised muudatused muudavad tõesti värava ressurssi, seega on uuesti ülesehitamine tõesti vajalik.

Punkt-koht jaoks loodud väravale ei saa lihtsalt koht-koht ühendust anda. Punkt-koht konfiguratsioon tuleb eemaldada ja värav uuesti luua, mis annab ka uue jagatud võtme ja uue kliendipaketi.

Punkt-koht pakett väärib oma märkust, sest see aegub. Portaal genereerib lühikese elueaga faili, seega on praktiline lähenemine see üks kord alla laadida ja levitada koos kliendisertifikaadiga, selle asemel et saata kasutajatele portaalilink, mis on nende klõpsamise ajaks surnud. Prefiksi küsimuse puhul ei kehti sellest miski. Kahe protseduuri lahus hoidmine on kogu distsipliin: prefiksid on ühenduse tasandi muudatus ja värava omadused on värava tasandi muudatus.

Lugege olekut, mitte portaali märki

Lugege olekut ressursist, mitte portaali märgist. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 tagastab ConnectionStatus koos sissetulevate ja väljuvate baitide loenduritega, ja just loendurid eristavad ühendatud, kuid mitte midagi kandvat tunnelit sellest, mis ei ole kunagi loodud.

Loendurid, mis lõpetavad ülekande keskel kasvamise, osutavad teele, mitte autentimisele. Loendurid, mis üldse ei liigu, osutavad prefiksite kogumile või jagatud võtmele.

Taimerid selgitavad ühte katkestuste klassi, mis omistatakse ekslikult VPN-ile. Azure'i koormusbalansseerija sulgeb jõudevood pärast oma konfigureeritud ajalimiiti, vaikimisi neli minutit, kui need märkmed kirjutati, ja seda saab suurendada, seega võib OpenVPN server VM-il ilma keepalive'ita iga paari minuti tagant maha kukkuda, samal ajal kui kõik muu näeb terve välja. Värav, mida platvorm tsükliliselt taaskäivitab, võib samuti katkestada VNet-ühenduse Web Appiga, ja see tõrge on platvormi poolel, mitte kliendi konfiguratsioonis. Tunnus on see, kas katkestus järgib kindlat intervalli või teie tehtud muudatust.

Hoidke kolm objekti ja nende väärtused ühes kirjes: virtuaalvõrgu aadressiruum, kohaliku võrguvärava prefiksite loend ja ühenduse jagatud võtme viide. koht-koht PowerShelli artikkel dokumenteerib kohaliku võrguvärava käsud ja järjekorra, kuhu need kuuluvad. Prefiksi muudatuse võrdlemine mäluga on viis, kuidas töötav tunnel kaks korda uuesti üles ehitatakse.

Seejärel kontrollige samas järjekorras, milles muutsite: kohalik võrguvärav näitab uut prefiksite loendit, ühendus on tagasi Connected ja loendurid liiguvad, kui saadate liiklust uue vahemiku hostile. Kui kolmas samm ebaõnnestub, samal ajal kui kaks esimest läbivad, ei ole kaughõlm uut liikluse selektorit aktsepteerinud ja kaugele seadmele on vaja vastavat faasi 2 kannet. See on vestlus tunneli teise otsaga, mitte veel üks muudatus Azure'is.