Да ли 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 пролази слабији тест од оног који је важан. Пријавите конкретну промену коју сте приметили, са њеном временском ознаком, уместо да наведете планирани закуп као узрок. Разлика између та два извештаја је да ли следећа особа може да репродукује квар или само гласину.