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, минава по-слаб тест от този, който има значение. Съобщете конкретната промяна, която наблюдавахте, с нейния времеви маркер, вместо да наричате планирания лиз причина. Разликата между тези два доклада е дали следващият човек може да възпроизведе неизправността, или само слуха.