Дали VPN паѓа по обновување на DHCP? Споредете ги адресите

Обновувањето на закупот и падот на 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 поминува послаб тест од оној што е важен. Пријавете ја конкретната промена што ја набљудувавте, со нејзината временска ознака, наместо да го именувате закажаниот закуп како причина. Разликата меѓу тие две извештаи е дали следниот човек може да го репродуцира дефектот или само гласината.