Забіты openconnect: маршруты і DNS па-ранейшаму паказваюць у тунель

Тунель не працуе, але машына па-ранейшаму паводзіць сябе так, быццам ён уключаны: запыт вісіць, пакуль не скончыцца тайм-аўт, а маршрут паказвае ў інтэрфейс, якога ўжо няма. Гэта подпіс працэса openconnect, які памёр, не запусціўшы свайго памочніка адключэння. Стан сеткі, які ён стварыў, усё яшчэ ўсталяваны, і нішто іншае ў сістэме не ведае, як яго выдаліць.

Прайдзіце па машыне ў тым парадку, у якім ствараўся стан: працэс, канал, маршрут, рэзалвер. Кожны крок паведамляе, ці кліент сапраўды знік, ці проста адлучыўся ад вашага тэрмінала, і гэтае адрозненне вырашае, ці трэба наогул нешта рамантаваць.

Пачніце з працэса, а не з канфігурацыі

Адкрыйце тэрмінал і спытайце, што ўсё яшчэ працуе, перш чым чапаць маршрут. pgrep -a openconnect пералічвае кожны асобнік з яго аргументамі, што паказвае pid-файл і скрыпт, які быў яму дадзены. Працэс, якога вы не чакалі, тлумачыць фантомны тунель хутчэй за любы журнал.

Калі нічога не працуе, паглядзіце на канал. ip link show tun0 паведамляе, ці выжыў інтэрфейс, і ip route show dev tun0 пералічвае маршруты, якія ўсё яшчэ прывязаны да яго. Затым праверце рэзалвер з resolvectl status. Запішыце ўсе тры вынікі, перш чым іх змяняць, бо менавіта гэты запіс дазволіць вам пазней адрозніць састарэлы запіс ад новага.

Інтэрфейс, які знік, звычайна забірае свае маршруты з сабой. Маршруты, якія жывуць даўжэй за канал, звычайна азначаюць, што працэс яшчэ жывы або другі кліент валодае прыладай.

Менавіта скрыпт-памочнік адкочвае змены

openconnect не выдаляе інтэрфейс, маршруты ці запісы рэзалвера сам. Ён выклікае знешні памочнік, /etc/vpnc/vpnc-script у upstream-зборцы і /usr/share/vpnc-scripts/vpnc-script у пакетах Debian і Ubuntu, выбраны з дапамогай -s. Той жа скрыпт, які ўздымае тунель, яго і разбірае.

Калі працэс выходзіць, не выклікаўшы гэтага памочніка, стан застаецца. Кіраўніцтва OpenConnect непасрэдна сцвярджае, што маршрутызацыя і служба імёнаў не будуць працаваць правільна без скрыпта, і апісвае памочнік як кампанент, які разбірае стан інтэрфейса пры выхадзе. Вось чаму шлях важны, калі вы запускаеце кліент з -s.

Які сігнал дасягае гэтага шляху, змянілася паміж версіямі. Кіраўніцтва 7.06 лічыць SIGTERM неадкладным выхадам, які прапускае скрыпт. Бягучыя зборкі дакументуюць INT і TERM як чыстае спыненне, калі сеанс разлагіньваецца і памочнік запусціць. Чытайце раздзел SIGNALS бінарніка, які ў вас насамрэч ёсць, замест таго каб меркаваць любы з двух паводзін.

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

Пашліце сігнал, які дакументуе вашая зборка

Калі вы ведаеце сігнал, спыніце працэс па 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 пад юнітам у якога KillSignal адпавядае сігналу, які дакументуе вашая версія. Тэставанне спачатку на пярэднім плане паказвае паведамленні спынення, якія друкуе памочнік.

Падключыцеся, адключыцеся і адзін раз прайдзіце тры праверкі. Чысты выхад не пакідае ні VPN-канала, ні VPN-маршруту, ні запісу VPN-рэзалвера. Калі адзін з трох выжыў, вы ўжо ведаеце, які кампанент не выканаў ачыстку. Тады наступнае расследаванне пачынаецца з гэтага адказу, а не з завіслага запыту.