Сайт туннелі қайтқаннан кейінгі резервтік жалдау: жаңарту керек пе, әлде күту керек пе?

Сайт желісі қосылған, туннель орнатылған, бірақ филиал компьютерлері әлі файлдық серверге жете алмайды. Үзіліс кезінде екі сағат жүріп жатты және олардың тек біреуі ғана аяқталды. Шифрланған жол қайтқанда туннель қалпына келді; әрбір клиенттің мекенжайы ағымдағы жалдауы аяқталғанда немесе ауыстырылғанда қалпына келеді. Осы екі уақыт сызығын салыстыру алшақтықты firewall журналдарын оқығаннан тезірек түсіндіреді.

Екі сағат, және олардың біреуі туннель емес

VPN арқылы DHCP және жергілікті резервтік механизммен құрылғы қашықтағы DHCP жолы қолжетімсіз болған кезде уақытша жергілікті жалдаулар бере алады. Уақытша ұзақтық әдетте минутпен есептеледі, бұл мәселені жасыруға жеткілікті қысқа және қысқа үзілістен өтуге жеткілікті ұзақ. Туннель қайтқанда резервтік механизм бұл жалдауларды ұсынуды тоқтатады. Ол клиенттің ішіне кіріп, оның қолындағы жалдауды жоймайды. Бұл клиент мекенжайын, маскасын, шлюзін және шешушісін жаңартуға немесе мерзімі біткенге дейін сақтайды, сондықтан сау туннель мен бұзылған компьютер жалдаудың қалған уақытында қатар өмір сүре алады.

Іске асыру мен бағдарламалық нұсқаны осы тұжырымға байланысты ұстаңыз. Таймер атаулары мен әдепкі мәндер SonicOS шығарылымдары арасында ерекшеленеді, ал ескі интерфейс жаңасының не істейтінін дәлелдемейді.

Қалпына келтірудің екі қадамын салыстырыңыз

A қадамы — күту. Ол ештеңеге тұрмайды, еш тәуекелге бармайды және әр клиентке өз кестесімен жаңартуға мүмкіндік береді. B қадамы — зардап шеккен клиентте мәжбүрлі босату мен жаңартуды орындау, бұл мақсатты мекенжайды бірден береді, бірақ клиент істеп жатқанның бәрін үзеді. Бір компьютерде мәжбүрлі жаңарту әдетте жылдамырақ жол және оны негіздеу оңай. Зертханада немесе транзакция ортасындағы сауда терминалында күту қауіпсіз таңдау, ал жұмыс уақытынан тыс жоспарланған жаңарту екеуінен де озады.

ipconfig /all
ipconfig /release
ipconfig /renew

Бірдеңені босатпас бұрын шығысты оқыңыз. Мекенжай, шлюз және DNS әдеттегі ауқымға сай болса, клиент өзі қалпына келді, ал қалған мәселе басқа жерде. Linux клиентінде баламасы — қолмен өңделген мекенжай емес, желілік менеджер арқылы жалдауды босату және жаңарту, өйткені әйтпесе менеджер келесі оқиғада өзгерісіңізді қайта жазады.

Ұсынысты оқыңыз, тек мекенжайды емес

Мекенжайдың өзі оны кім бергенін айтпайды. Маңыздысы — ұсыныстағы сервер идентификаторы, жалдау уақыты және шлюз бен шешушінің резервтік ауқымға немесе әдеттегіге сәйкес келуі.

tcpdump -ni any 'port 67 or port 68'

Жаңарту кезінде жазып алыңыз, өйткені тыныш интерфейс клиенттің ешқашан сұрамағанын айтады. Егер туннель қосылып тұрғанда ұсыныс жергілікті резервтен келсе, таңдау логикасы қашықтағы жолды әлі де қолжетімсіз деп санайды, ал клиенттерде мәжбүрлі жаңарту тек сол нәтижені қайталайды. Жазбаны сол сағаттағы туннель оқиғаларымен байланыстырыңыз. Клиент сұранысынан секунд бұрын аяқталатын кілт жаңартуы немесе қысқа үзіліс ықтимал себеп; таза туннель мен резервтік жауап — таңдау жолындағы конфигурация мәселесі.

Салыстыру қай жерде аударылады

Егер бір уақытта көп клиент зардап шексе, әр клиент бойынша жаңартулар үзілістер кезегіне және қолдау қоңырауына айналады. Бұл жағдайда клиенттерге емес, резервтік ауқым мен қалпына келтіру рәсіміне қараңыз, өйткені топ бірге қалпына келді және тағы бірге қалпына келеді.

Егер көршілері дұрыс болғанда тек бір клиент зардап шексе, керісінше дұрыс: айнымалы — сол клиенттің жалдауы, оның резервтелуі немесе өз DHCP клиентінің әрекеті, ал бүкіл сайтқа өзгеріс — қате құрал.

Статикалық мекенжайлар мен резервтеулер үшінші жауапты қажет етеді. Мекенжайға бекітілген клиентті жаңартумен құтқару мүмкін емес, ал резервтік ауқыммен қақтығысатын резервтеу екі мекенжай жоспарын салыстырғанша маршруттау ақауына ұқсайтын көшірме жасайды.

Шығу рәсімін жазып қойыңыз

Резервтің не үшін екенін, клиенттің уақытша мекенжайын қанша уақыт ұстай алатынын және жұмыс уақытында кімнің жаңартуды мәжбүрлей алатынын алдын ала шешіңіз. Жауапты кезекші инженер табатын жерге, ауқым анықтамасының қасына жазыңыз. Сосын оны бір рет әдейі сынап көріңіз: туннельді түсіріңіз, клиенттің не алатынын бақылаңыз, туннельді қалпына келтіріңіз және клиенттің әдеттегі параметрлерін қайтаруға қанша уақыт кететінін жазып алыңыз. Осы бір жаттығу келесі жолы сайт желісі шайқалғанда болжамдардың көбін алмастырады.

Ресурсты растаумен аяқтаңыз, мекенжайды емес. Файлдық серверге жету, оның атын шешу және интернетке шығу — үш бөлек тексеру, ал тек соңғысы ғана ешқашан күмән тудырмаған.