Atsarginė nuoma grįžus svetainės tuneliui: atnaujinti ar laukti?

Svetainės linija veikia, tunelis sukurtas, o filialo kompiuteriai vis dar nepasiekia failų serverio. Per triktį ėjo du laikrodžiai, ir tik vienas jų baigėsi. Tunelis atsistatė, kai grįžo šifruotas kelias; kiekvieno kliento adresas atsistato, kai jo dabartinė nuoma baigiasi arba pakeičiama. Šių dviejų laiko juostų palyginimas paaiškina atotrūkį greičiau nei ugniasienės žurnalų skaitymas.

Du laikrodžiai, ir vienas jų nėra tunelis

Su DHCP per VPN ir vietine atsargine priemone įrenginys gali išduoti laikinas vietines nuomas, kol nuotolinis DHCP kelias nepasiekiamas. Laikinoji trukmė paprastai skaičiuojama minutėmis, o tai pakankamai trumpa problemai paslėpti ir pakankamai ilga, kad atlaikytų trumpą triktį. Kai tunelis grįžta, atsarginė priemonė nustoja siūlyti tas nuomas. Ji neįeina į klientą ir neatšaukia nuomos, kurią jis jau turi. Tas klientas išlaiko savo adresą, kaukę, šliuzą ir resolverį iki atnaujinimo arba pasibaigimo, todėl sveikas tunelis ir sugedęs kompiuteris gali sugyventi iki nuomos pabaigos.

Laikykite įgyvendinimą ir programinės įrangos versiją susietus su šiuo teiginiu. Laikmačių pavadinimai ir numatomosios vertės skiriasi tarp SonicOS leidimų, o senesnė sąsaja neįrodo, ką daro naujesnė.

Palyginkite du atkūrimo žingsnius

Žingsnis A yra laukti. Jis nieko nekainuoja, niekuo nerizikuoja ir palieka kiekvienam klientui atnaujinti pagal savo grafiką. Žingsnis B yra priverstinai atlaisvinti ir atnaujinti paveiktame kliente, o tai iš karto duoda norimą adresą, bet nutraukia viską, ką klientas daro. Viename kompiuteryje priverstinis atnaujinimas paprastai yra greitesnis kelias ir jį lengva pagrįsti. Laboratorijoje arba mokėjimo terminale sandorio viduryje laukimas yra saugesnis pasirinkimas, o už darbo valandų suplanuotas atnaujinimas pranoksta abu.

ipconfig /all
ipconfig /release
ipconfig /renew

Perskaitykite išvestį prieš ką nors atlaisvindami. Jei adresas, šliuzas ir DNS jau atitinka įprastą diapazoną, klientas atsistatė pats, o likusi problema yra kitur. Linux kliente atitikmuo yra nuomos atlaisvinimas ir atnaujinimas per tinklo tvarkyklę, o ne rankiniu būdu redaguotas adresas, nes priešingu atveju tvarkyklė perrašys jūsų pakeitimą kitame įvykyje.

Skaitykite pasiūlymą, ne tik adresą

Adresas pats savaime nesako, kas jį suteikė. Svarbu yra serverio identifikatorius pasiūlyme, nuomos laikas ir tai, ar šliuzas bei resolveris atitinka atsarginį diapazoną, ar įprastą.

tcpdump -ni any 'port 67 or port 68'

Fiksuokite atnaujinimo metu, nes tyli sąsaja jums sako, kad klientas niekada neprašė. Jei pasiūlymas ateina iš vietinės atsarginės priemonės, kai tunelis veikia, pasirinkimo logika vis dar laiko nuotolinį kelią neprieinamu, o priverstiniai atnaujinimai klientuose tik pakartos tą patį rezultatą. Susiekite įrašą su tunelio įvykiais tuo pačiu laikrodžiu. Raktų atnaujinimas arba trumpas nutrūkimas, pasibaigiantis sekundėmis prieš kliento užklausą, yra tikėtina priežastis; švarus tunelis su atsarginiu atsakymu yra pasirinkimo kelio konfigūracijos problema.

Kur palyginimas apsiverčia

Jei vienu metu nukenčia daug klientų, atnaujinimai pagal klientą virsta pertraukimų eile ir skambučiu į pagalbą. Tokiu atveju žiūrėkite į atsarginį diapazoną ir atkūrimo procedūrą, o ne į klientus, nes populiacija atsistatė kartu ir vėl atsistatys kartu.

Jei nukentėjo tik vienas klientas, o jo kaimynai gerai, galioja priešingai: kintamasis yra to kliento nuoma, jo rezervacija arba jo paties DHCP kliento elgsena, o visos svetainės pakeitimas yra netinkamas įrankis.

Statiniai adresai ir rezervacijos reikalauja trečio atsakymo. Prie adreso pritvirtintas klientas negali būti išgelbėtas atnaujinimu, o rezervacija, kuri susiduria su atsarginiu diapazonu, sukuria dublikatą, kuris atrodo kaip maršrutizavimo gedimas, kol nepalyginsite dviejų adresų planų.

Užrašykite išėjimo procedūrą

Iš anksto nuspręskite, kam skirta atsarginė priemonė, kiek laiko klientas gali laikyti laikiną adresą ir kas gali priverstinai atnaujinti darbo valandomis. Užrašykite atsakymą ten, kur jį ras budintis inžinierius, šalia diapazono apibrėžimo. Tada išbandykite vieną kartą sąmoningai: nutraukite tunelį, stebėkite, ką gauna klientas, atkurkite tunelį ir užrašykite, kiek laiko klientui reikia susigrąžinti įprastus nustatymus. Šis vienas pratimas pakeičia didžiąją dalį spėlionių kitą kartą, kai svetainės linija suvirpės.

Užbaikite patvirtindami išteklių, o ne adresą. Pasiekti failų serverį, išspręsti jo vardą ir pasiekti internetą yra trys atskiri patikrinimai, ir tik paskutinis niekada nekėlė abejonių.