VPN мъртъв след сън: изгубен тунел или остаряло приложение?

Капакът се отваря, иконата за безжична мрежа се връща, а VPN все още показва, че е свързан. След това първата вътрешна страница виси до изтичане на времето, а нов раздел прави същото. Три различни неща могат да създадат тази картина и те се нуждаят от три различни поправки: тунел, който не е преживял съня, профил, който никой не е помолил да се активира отново, или приложение, което още държи сесия, умряла преди часове. Сравняването им е по-бързо от преинсталиране на каквото и да е.

Три неща могат да се счупят след събуждане

Първият кандидат е самият тунел. Интерфейсът може да съществува с адрес, докато връзката с партньора е изчезнала, затова индикаторът не е доказателство за работещ път. Ръкостискането, по-старо от съня, е признакът и за да го видите е нужна една команда.

Вторият е активирането. Много клиенти се свързват отново сами; някои не го правят и профил, който никой не кани да се върне, просто стои и изглежда конфигуриран. Този отказ е тих по дизайн, защото нищо не е дало грешка.

Третият е приложението. Раздел на браузър, SSH сесия или връзка към база данни могат да преживеят смяна на мрежата като файлов дескриптор, докато транспортът под тях е мъртъв. Тогава нова сесия работи безупречно и това ви казва, че тунелът е бил наред през цялото време.

Сравнете трите, преди да промените нещо, защото поправките не се припокриват. Рестартирането на клиент, който никога не е бил канен да стартира отново, прахосва доказателствата, които ви трябваха. Запишете на кой кандидат отговаря симптомът, преди да пипнете конфигурация. Това едно изречение обикновено решава останалата част от разследването.

Първо: върна ли се тунелът?

Гледайте интерфейса и състоянието на партньора, а не собствения текст за състояние на клиента. Интерфейс с адрес и без скорошно ръкостискане е тунел, който съществува само на име.

ip -brief addr show
wg show
ip route show table all | head -20

Ако интерфейсът липсва напълно, тунелът не е преживял и въпросът става кой е трябвало да го върне. Ако го има, но ръкостискането е старо, връзката с партньора трябва да се възстанови и клиентът може да чака трафик, който да я задейства.

Проверете и маршрутите и настройката на DNS. Тунелът може да се върне без маршрутите си, което създава объркващото състояние, в което интерфейсът работи, а вътрешните имена все още се решават през грешния сървър.

Второ: поиска ли нещо да се върне?

Тук сравнението си заслужава. Профил на OpenVPN плъгин и собствена WireGuard връзка се обработват различно от NetworkManager и справката за настройки на връзката е категорична, че connection.autoconnect не активира VPN профили; механизмът за вдигане на VPN заедно с връзка е connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Ако ръчното пресвързване поправя проблема всеки път, това е подписът на липсващо активиране, а не на счупен тунел. Журналът обикновено ще покаже интерфейса как пада и нищо как не го връща.

Устоявайте на желанието веднага да добавите hook за сън. Hook, който се задейства преди мрежата да се е възстановила, се състезава с процеса, на който се опитва да помогне, и превръща възпроизводим проблем в периодичен.

Трето: държи ли приложението стар режим?

Отворете напълно нова сесия към същата дестинация, преди да пипате VPN. Ако новата сесия работи, а старата не, тунелът е наред и приложението държи мъртва връзка.

Това е най-евтината от трите проверки и тази, която най-често се пропуска, защото прозорецът с отказа е точно на екрана. Затворете го, отворете го отново и отбележете дали проблемът оцелява. Ако новата сесия работи, спрете разследването на тунела напълно. Ако и тя се провали, приложението е симптом, а не причина.

Някои приложения се възстановяват сами след изтичане на време, затова симптомът може да изглежда, че се поправя сам след няколко минути. Това поведение сочи към приложението, а не към тунела, и си струва да се запише отделно. Колега, който казва, че просто се е оправило само, описва този модел, а не късмет.

Направете сравнението възпроизводимо

Дръжте променливите малки: една мрежа за достъп, една продължителност на съня и една и съща първа заявка всеки път. След това запишете два резултата: дали ръчното пресвързване го поправя и дали още един сън връща отказа.

Последното наблюдение е това, което разделя трите кандидата най-надеждно. Работеща нова сесия след провалена стара не е проблем на тунела и никакво преинсталиране на клиента няма да го промени.

Постоянният keepalive на WireGuard принадлежи на тази картина само като keepalive за NAT преобразуване. Той изпраща пакети, за да държи преобразуването отворено; не спира машината да заспи и не може да продължи да изпраща, докато процесът е спрян.

Запишете в тикета какво сте намерили: кое от трите е било счупено, какво го е поправило и как сте го възпроизвели. Следващият човек, който отвори капак в понеделник, ще ви благодари и отговорът няма да трябва да се открива от нулата.