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, праходзіць слабейшы тэст, чым той, што мае значэнне. Паведамляйце пра канкрэтную змену, якую вы назіралі, з яе часавай адзнакай, замест таго каб называць запланаваную арэнду прычынай. Розніца паміж гэтымі двума справаздачамі ў тым, ці зможа наступны чалавек узнавіць няспраўнасць ці толькі чутку.