Pinatay na openconnect: ang mga ruta at DNS ay nakaturo pa rin sa tunnel

Bumagsak ang tunnel, ngunit kumikilos pa rin ang makina na parang buhay ito: nakabitin ang isang lookup hanggang mag-time out, at may rutang nakaturo sa isang interface na wala na. Ito ang pirma ng isang proseso ng openconnect na namatay nang hindi pinatakbo ang katulong nitong pang-disconnect. Naka-install pa rin ang estado ng network na ginawa nito, at walang ibang bagay sa system ang marunong mag-alis nito.

Lakarin ang makina sa pagkakasunod-sunod kung paano nilikha ang estado: proseso, link, ruta, resolver. Sinasabi ng bawat hakbang kung talagang umalis ang kliyente o humiwalay lamang sa iyong terminal, at ang pagkakaibang iyon ang magpapasya kung may aayusin ka ba.

Magsimula sa proseso, hindi sa configuration

Magbukas ng terminal at itanong kung ano pa ang tumatakbo bago hawakan ang isang ruta. pgrep -a openconnect naglilista ng bawat instance kasama ang mga argumento nito, na nagpapakita ng pid file at ang script na ibinigay dito. Ang prosesong hindi mo inaasahan ang nagpapaliwanag ng phantom tunnel nang mas mabilis kaysa sa anumang log.

Kung walang tumatakbo, tingnan ang link. ip link show tun0 sinasabi kung nakaligtas ang interface, at ip route show dev tun0 naglilista ng mga rutang nakatali pa rin dito. Pagkatapos ay suriin ang resolver gamit ang resolvectl status. Isulat ang lahat ng tatlong output bago mo itong baguhin, dahil ang rekord na iyon ang paraan para makilala mo mamaya ang lumang entry sa bago.

Ang interface na nawala ay karaniwang may dalang mga ruta nito. Ang mga rutang nakaligtas sa link ay karaniwang nangangahulugang buhay pa ang proseso o may-ari ng device ang pangalawang kliyente.

Ang helper script ang nagbabalik ng mga pagbabago

Hindi tinatanggal ng openconnect mismo ang interface, mga ruta o entry ng resolver. Tumatawag ito ng panlabas na katulong, /etc/vpnc/vpnc-script sa isang upstream build at /usr/share/vpnc-scripts/vpnc-script sa mga pakete ng Debian at Ubuntu, pinipili gamit ang -s. Ang parehong script na nagtataas ng tunnel ang siyang nagbabagsak nito.

Kung lalabas ang proseso nang hindi tinatawag ang katulong na iyon, mananatili ang estado. manwal ng OpenConnect ay malinaw na hindi gagana nang tama ang routing at serbisyo ng pangalan kung wala ang script, at inilalarawan ang katulong bilang ang bahaging nagbibiyak ng estado ng interface sa paglabas. Kaya mahalaga ang landas kapag inilunsad mo ang kliyente gamit ang -s.

Nagbago sa pagitan ng mga bersyon kung aling signal ang umaabot sa landas na iyon. Itinuturing ng manwal ng 7.06 ang SIGTERM bilang agarang paglabas na lumalaktaw sa script. Dokumentado ng mga kasalukuyang build ang INT at TERM bilang malinis na paghinto, kung saan nila-log out ang session at tumatakbo ang katulong. Basahin ang seksyong SIGNALS ng binary na talagang mayroon ka sa halip na ipagpalagay ang alinman sa dalawang pag-uugali.

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

Ipadala ang signal na dokumentado ng iyong build

Kapag alam mo na ang signal, ihinto ang proseso ayon sa pid at hindi ayon sa pattern.

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

Pagkatapos ay ulitin ang tatlong pagsusuri mula sa unang seksyon sa halip na magtiwala sa exit status. ip link show tun0 dapat mabigo, ip route show dev tun0 hindi dapat mag-print ng anuman, at resolvectl status hindi na dapat ilista ang link ng VPN.

Ang SIGHUP ay hindi pindutan ng paghinto: nagdi-disconnect ito, pinapatakbo ang script at iniiwan ang session na maipagpapatuloy gamit ang --cookie. Pinipilit ng SIGUSR2 ang agarang muling pagkonekta. Nilalaktawan ng SIGKILL nang buo ang paglilinis, at iyon ang eksaktong estadong tinatalakay ng artikulong ito.

Ayusin ang resolver nang hindi pinapalitan ang resolv.conf

Sa karamihan ng mga system na Ubuntu /etc/resolv.conf ay isang symbolic link patungo sa systemd-resolved, hindi file na dapat mong i-edit. Ang pagpapalit nito ay sumisira sa paghahanap ng pangalan para sa bawat network, hindi lang sa VPN. Sa halip, alisin ang pagpapatala ng tunnel:

resolvectl revert tun0
resolvectl query example.com

Kung gumagamit ang system ng resolvconf sa halip na systemd-resolved, nananatili ang rekord sa bawat interface hanggang sabihan itong bitawan ang link, at resolvconf -d tun0 ay ang katumbas na aksyon. Suriin kung aling resolver ang ginagamit bago piliin ang utos.

Ang lookup na nakaturo pa rin sa server sa likod ng patay na link ay nakabitin hanggang mag-time out, at ang pagkaantala ay mukhang sirang DNS server kaysa natirang ruta.

Gawing boring ang susunod na pag-disconnect

Panatilihing pareho ang landas ng pid file sa pagsisimula at pagsasara sa pamamagitan ng pagbibigay ng --pid-file tuwing, o patakbuhin ang openconnect sa ilalim ng unit na ang KillSignal ay tumutugma sa signal na dokumentado ng iyong bersyon. Ang pagsubok muna sa foreground ay nagpapakita sa iyo ng mga mensahe ng pagsasara na ipiniprinta ng katulong.

Kumonekta, mag-disconnect at patakbuhin ang tatlong pagsusuri isang beses. Ang malinis na paglabas ay walang iniiwang link ng VPN, ruta ng VPN o entry ng resolver ng VPN. Kung may isang nakaligtas sa tatlo, alam mo na ngayon kung aling bahagi ang nabigong maglinis. Ang susunod na pagsisiyasat ay magsisimula sa sagot na iyon at hindi sa nakabiting lookup.