Убијен openconnect: руте и DNS и даље показују на тунел

Тунел је угашен, али машина се и даље понаша као да је укључен: упит виси док не истекне време, а рута показује на интерфејс који више не постоји. То је потпис openconnect процеса који је умро без покретања свог помоћника за прекид везе. Мрежно стање које је створио још је инсталирано, и ништа друго у систему не зна како да га уклони.

Прођите машину редом којим је стање стварано: процес, веза, рута, резолвер. Сваки корак вам каже да ли је клијент заиста отишао или се само одвојио од вашег терминала, а та разлика одлучује да ли уопште нешто поправљати.

Почните од процеса, а не од конфигурације

Отворите терминал и питајте шта још ради пре него што дотакнете руту. pgrep -a openconnect излистава сваку инстанцу са њеним аргументима, што показује pid датотеку и скрипту која јој је дата. Процес који нисте очекивали објашњава фантомски тунел брже од било ког лога.

Ако ништа не ради, погледајте везу. ip link show tun0 вам каже да ли је интерфејс преживео, и ip route show dev tun0 излистава руте које су још везане за њега. Затим проверите резолвер са resolvectl status. Запишите сва три излаза пре него што их промените, јер тај запис је начин да касније разликујете застарео унос од новог.

Интерфејс који нестане обично понесе своје руте са собом. Руте које надживе везу обично значе да је процес још жив или да уређај поседује други клијент.

Управо помоћна скрипта поништава промене

openconnect сам не уклања интерфејс, руте или уносе у резолверу. Позива спољног помоћника, /etc/vpnc/vpnc-script у upstream build-у и /usr/share/vpnc-scripts/vpnc-script у Debian и Ubuntu пакетима, биран са -s. Иста скрипта која подиже тунел је и она која га разграђује.

Ако процес изађе без позивања тог помоћника, стање остаје. OpenConnect приручник изричито наводи да рутирање и служба имена неће радити исправно без скрипте, и описује помоћника као компоненту која при изласку разграђује стање интерфејса. Зато је путања важна када клијента покрећете са -s.

Који сигнал стиже на ту путању променило се између верзија. Приручник за 7.06 третира SIGTERM као тренутни излаз који прескаче скрипту. Актуелни build-ови документују INT и TERM као чисто заустављање, при чему се сесија одјављује и помоћник се извршава. Читајте одељак SIGNALS бинарне датотеке коју заиста имате, уместо да претпостављате једно од два понашања.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Пошаљите сигнал који документује ваш build

Када знате сигнал, зауставите процес по pid-у, а не по обрасцу.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Затим поновите три провере из првог одељка уместо да верујете излазном статусу. ip link show tun0 би требало да пропадне, ip route show dev tun0 не би требало ништа да испише, и resolvectl status више не би требало да излистава VPN везу.

SIGHUP није дугме за заустављање: прекида, извршава скрипту и оставља сесију обновљивом са --cookie. SIGUSR2 присиљава тренутно поновно повезивање. SIGKILL потпуно прескаче чишћење, и то је управо стање о коме је овај чланак.

Поправите резолвер без замене resolv.conf

На већини Ubuntu система /etc/resolv.conf је симболичка веза на systemd-resolved, а не датотека коју би требало да уређујете. Њена замена квари разрешавање имена за сваку мрежу, не само за VPN. Уместо тога уклоните регистрацију тунела:

resolvectl revert tun0
resolvectl query example.com

Ако систем користи resolvconf уместо systemd-resolved, унос по интерфејсу остаје док му се не каже да пусти везу, и resolvconf -d tun0 је еквивалентна радња. Проверите који се резолвер користи пре него што изаберете команду.

Упит који још циља сервер иза мртве везе виси док не истекне, а то кашњење изгледа као покварен DNS сервер, а не као заостала рута.

Учините следећи прекид досадним

Држите путању pid датотеке истом при покретању и гашењу тако што ћете прослеђивати --pid-file сваки пут, или покрените openconnect под unit-ом чији KillSignal одговара сигналу који документује ваша верзија. Тестирање прво у првом плану показује вам поруке гашења које помоћник исписује.

Повежите се, прекинете и покрените три провере једном. Чист излаз не оставља ни VPN везу, ни VPN руту, ни унос VPN резолвера. Ако једна од три преживи, сада знате која компонента није очистила. Следећа истрага тада почиње од тог одговора, а не од висећег упита.