VPN казва „свързано“, но нищо не се маршрутизира: две места за проверка

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

Първо питайте ядрото кое устройство би използвало

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

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

ip route show default
ip route get 203.0.113.9

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

След това четете резолвера по връзки, а не по файл

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

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

resolvectl status
resolvectl query app.internal.example

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

Как остарял маршрут преживява промяната

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

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

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

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

Различавайте остаряло състояние от липсващ родител

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

Рестартирането скрива кое от трите сте имали, и точно затова изглежда като поправка.

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