DHCP жаңартуынан кейін VPN үзіледі ме? Мекенжайларды салыстырыңыз

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

Үзілген клиенттен бастаңыз

Алдымен клиенттің қосылым журналын ашып, үзілу уақытын секундқа дейін жазып алыңыз. Сосын сол минут үшін операциялық жүйенің желілік журналын ашып, интерфейстің не істегенін ретімен оқыңыз. Бұл рет — бүкіл тергеу: ажырауға дейінгі DHCP оқиғасы, DHCP оқиғасына дейінгі ажырау және арасында ештеңе жоқ екі оқиға — үш түрлі қорытынды. Туннель қайта қосылып жатқанда тек жалдауды атайтын журнал жолы — әшекей, дәлел емес.

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

Оқиға айналасындағы төрт мәнді салыстырыңыз

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

Жаңарту нені өзгерте алады, нені өзгерте алмайды

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

Қосылымның ашық жағы ешбір жергілікті өзгеріссіз-ақ өзгеруі мүмкін. Операторлық деңгейдегі аударманың артында VPN серіктесі көретін мекенжай жергілікті жалдаудың не істегеніне қарамастан қайта тағайындалуы мүмкін, және бұл қайта тағайындау клиенттің ішінен жергілікті желі ақауына дәл ұқсайды. Жергілікті хабарланған мекенжайды серіктес жақтағы бақылаумен салыстыру оларды ажыратудың жалғыз жолы.

Клиент бейімделе алмағанда

Тасымалын ескі мекенжайға байлаған, серіктеске ескірген маршрутты кэштеген немесе интерфейс сәйкестігін сақтаған клиент енді жоқ жолды қайталап көре береді. Бұл бейімделу ақауы және хост енді жете алмайтын мекенжайға қайталама жіберулер түрінде көрінеді. Кейбір клиенттер мұны құрылымы бойынша шешеді: мысалы, WireGuard жаңа көзден дұрыс аутентификацияланған пакет келгенде серіктестің соңғы нүктесін жаңартады.

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

Кінәламас бұрын оқиғаны қайталаңыз

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

Қолдау көрсетілген түзетуден кейін сол оқиғаны қайталап, сосын қолданба мен атау сұрауын тексеріңіз, өйткені қайта қосылатын, бірақ DNS-ті бұзатын туннель маңызды тесттен әлсіз тесттен өтеді. Жоспарланған жалдауды себеп деп атаудың орнына байқаған нақты өзгерісіңізді оның уақыт белгісімен хабарлаңыз. Бұл екі есептің айырмашылығы — келесі адам ақауды қайта жасай ала ма, әлде тек қауесетті ме.