VPN казва, че е свързан, но маршрутът по подразбиране е мъртъв

Клиентът съобщава, че е свързан, иконата в системния трей изглежда нормална, а нищо не се зарежда. Започна веднага след като преминахте от Wi-Fi към кабел или веднага след като приключи надграждане на дистрибуцията. Счупи се не профилът, а състоянието, изградено за предишната базова връзка. Ядрото все още има маршрут по подразбиране, сочещ към тунелно устройство, което никой не притежава, или резолверът все още изброява сървъри на връзка, която е изчезнала. И двете повреди изглеждат като мъртва мрежа и двете се поправят на място.

Остарелите парчета бяха грешни още преди да ги забележите. Изваждането на кабела просто ги направи видими.

Попитайте ядрото накъде ще тръгне пакетът

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

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

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

Резолверът също пази мъртвата връзка

На хост със systemd-resolved DNS сървърите принадлежат на връзки, а не на един глобален списък. VPN връзка, която е паднала, може да остане регистрирана със своите сървъри известно време и тогава всяко търсене чака адрес, който никога няма да отговори. Това забавяне се усеща като мъртва мрежа и кара хората да гледат маршрутите, когато маршрутът е наред.

resolvectl status
resolvectl query intranet.example.com

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

Поправете регистрацията, а не /etc/resolv.conf. В текущите инсталации на Ubuntu и Fedora този път е символна връзка към състоянието на резолвера по време на изпълнение, затова редакция или се игнорира, или се презаписва при следващото мрежово събитие.

VPN никога не стартира сам

NetworkManager вдига VPN върху базова връзка и научава коя да следва от connection.secondaries на тази база. Справката за настройките на връзката изрично посочва, че автоматичното свързване не е реализирано за VPN профили. Това е целият механизъм зад този клас повреди: сменете базата и VPN трябва да бъде сдвоен отново или активиран ръчно.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Когато активният списък показва базата без VPN, тунелът изобщо не е активен и маршрутът никога не е бил инсталиран, а не е останал остарял. Когато активирането се оплаква, че няма изходна връзка, базата, с която е бил сдвоен, е изчезнала, затова първо поправете базата или сдвояването и спрете да опитвате VPN отново.

Надграждане може да изпусне настройки без съобщение

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

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

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

Три състояния, три различни поправки

Решете в кое състояние сте, преди да пипате нещо, защото рестартът унищожава доказателствата и повредата се връща при следващата мрежова промяна.

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