Mortigita openconnect: itineroj kaj DNS ankoraŭ montras al la tunelo

La tunelo estas malsupre, sed la maŝino ankoraŭ kondutas kvazaŭ ĝi estus supre: serĉo pendas ĝis ĝi tempolimas, kaj itinero montras en interfacon, kiu ne plu ekzistas. Tio estas la subskribo de openconnect-procezo, kiu mortis sen ruligi sian malkonektan helpanton. La reta stato, kiun ĝi kreis, estas ankoraŭ instalita, kaj nenio alia en la sistemo scias, kiel forigi ĝin.

Trapasu la maŝinon en la ordo, en kiu la stato estis kreita: procezo, ligilo, itinero, solvilo. Ĉiu paŝo diras al vi, ĉu la kliento vere foriris aŭ nur malligiĝis de via terminalo, kaj tiu distingo decidas, ĉu vi riparu ion ajn.

Komencu per la procezo, ne per la agordo

Malfermu terminalon kaj demandu, kio ankoraŭ funkcias, antaŭ ol tuŝi itineron. pgrep -a openconnect listigas ĉiun okazon kun ĝiaj argumentoj, kio montras la pid-dosieron kaj la skripton donitan al ĝi. Procezo, kiun vi ne atendis, klarigas la fantoman tunelon pli rapide ol iu ajn protokolo.

Se nenio funkcias, rigardu la ligilon. ip link show tun0 diras al vi, ĉu la interfaco pluvivis, kaj ip route show dev tun0 listigas itinerojn ankoraŭ ligitajn al ĝi. Poste kontrolu la solvilon per resolvectl status. Notu ĉiujn tri eligojn antaŭ ol ŝanĝi ilin, ĉar tiu noto estas kiel vi poste distingos malfreŝan rikordon de nova.

Interfaco, kiu foriris, kutime forportas siajn itinerojn. Itineroj, kiuj pluvivas la ligilon, kutime signifas, ke la procezo ankoraŭ vivas aŭ ke dua kliento posedas la aparaton.

La helposkripto estas tio, kio malfaras la ŝanĝojn

openconnect mem ne forigas la interfacon, la itinerojn aŭ la solvajn rikordojn. Ĝi vokas eksteran helpanton, /etc/vpnc/vpnc-script en upstream-konstruo kaj /usr/share/vpnc-scripts/vpnc-script en la pakaĵoj Debian kaj Ubuntu, elektita per -s. La sama skripto, kiu starigas la tunelon, estas tiu, kiu ĝin malmuntas.

Se la procezo eliras sen voki tiun helpanton, la stato restas. La manlibro de OpenConnect estas eksplicita, ke enkursigado kaj nomservo ne funkcios ĝuste sen la skripto, kaj ĝi priskribas la helpanton kiel la komponanton, kiu malmuntas la staton de la interfaco ĉe eliro. Tial la vojo gravas, kiam vi lanĉas la klienton per -s.

Kiu signalo atingas tiun vojon, ŝanĝiĝis inter versioj. La manlibro de 7.06 traktas SIGTERM kiel tujan eliron, kiu preterlasas la skripton. Nunaj konstruoj dokumentas INT kaj TERM kiel puran halton, kie la sesio estas elsalutita kaj la helpanto ruliĝas. Legu la sekcion SIGNALS de la binara dosiero, kiun vi efektive havas, anstataŭ supozi iun el la du kondutoj.

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

Sendu la signalon, kiun via konstruo dokumentas

Kiam vi scias la signalon, haltigu la procezon laŭ pid anstataŭ laŭ ŝablono.

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

Poste ripetu la tri kontrolojn el la unua sekcio anstataŭ fidi la eliran staton. ip link show tun0 devus malsukcesi, ip route show dev tun0 devus presi nenion, kaj resolvectl status devus ne plu listigi la VPN-ligilon.

SIGHUP ne estas haltbutono: ĝi malkonektas, rulas la skripton kaj lasas la sesion rekomencigebla per --cookie. SIGUSR2 devigas tujan rekonekton. SIGKILL tute preterlasas la purigadon, kio estas ĝuste la stato, pri kiu temas ĉi tiu artikolo.

Riparu la solvilon sen anstataŭigi resolv.conf

Sur plej multaj Ubuntu-sistemoj /etc/resolv.conf estas simbola ligilo en systemd-resolved, ne dosiero, kiun vi devus redakti. Anstataŭigi ĝin rompas nomrezolucion por ĉiu reto, ne nur por la VPN. Anstataŭe forigu la registriĝon de la tunelo:

resolvectl revert tun0
resolvectl query example.com

Se la sistemo uzas resolvconf anstataŭ systemd-resolved, la rikordo por interfaco restas, ĝis oni diras al ĝi lasi la ligilon, kaj resolvconf -d tun0 estas la ekvivalenta ago. Kontrolu, kiu solvilo estas uzata, antaŭ ol elekti la komandon.

Serĉo ankoraŭ celanta servilon malantaŭ la mortinta ligilo pendas ĝis ĝi tempolimas, kaj tiu prokrasto aspektas kiel rompita DNS-servilo anstataŭ kiel restinta itinero.

Faru la sekvan malkonekton enuiga

Tenu la vojon de la pid-dosiero identa ĉe starto kaj malŝalto per pasado de --pid-file ĉiufoje, aŭ rulu openconnect sub unuo kies KillSignal kongruas kun la signalo, kiun via versio dokumentas. Unue testi en la antaŭa fono montras al vi la malŝaltajn mesaĝojn, kiujn la helpanto presas.

Konektu, malkonektu kaj rulu la tri kontrolojn unufoje. Pura eliro lasas neniun VPN-ligilon, neniun VPN-itineron kaj neniun VPN-solvilan rikordon. Se unu el la tri pluvivas, vi nun scias, kiu komponanto malsukcesis purigi. La sekva enketo tiam komenciĝas de tiu respondo anstataŭ de pendanta serĉo.