Nužudytas openconnect: maršrutai ir DNS vis dar rodo į tunelį

Tunelis išjungtas, bet mašina vis dar elgiasi taip, lyg jis būtų įjungtas: užklausa kabo, kol baigiasi laikas, o maršrutas rodo į sąsają, kurios nebėra. Tai openconnect proceso, kuris mirė nepaleidęs savo atjungimo pagalbininko, parašas. Tinklo būsena, kurią jis sukūrė, vis dar įdiegta, ir niekas kitas sistemoje nežino, kaip ją pašalinti.

Pereikite mašiną ta tvarka, kuria būsena buvo sukurta: procesas, sąsaja, maršrutas, resolveris. Kiekvienas žingsnis pasako, ar klientas tikrai dingo, ar tik atsijungė nuo jūsų terminalo, ir šis skirtumas nulemia, ar apskritai ką nors taisyti.

Pradėkite nuo proceso, o ne nuo konfigūracijos

Atidarykite terminalą ir paklauskite, kas dar veikia, prieš liesdami maršrutą. pgrep -a openconnect išvardija kiekvieną egzempliorių su jo argumentais, o tai parodo pid failą ir jam duotą scenarijų. Procesas, kurio nesitikėjote, paaiškina fantominį tunelį greičiau nei bet koks žurnalas.

Jei niekas neveikia, pažiūrėkite į sąsają. ip link show tun0 pasako, ar sąsaja išliko, ir ip route show dev tun0 išvardija maršrutus, kurie vis dar prie jos pririšti. Tada patikrinkite resolverį su resolvectl status. Užrašykite visas tris išvestis prieš jas keisdami, nes būtent tas įrašas yra būdas vėliau atskirti pasenusį įrašą nuo naujo.

Dingusi sąsaja paprastai pasiima savo maršrutus. Maršrutai, kurie išlieka po sąsajos, paprastai reiškia, kad procesas dar gyvas arba įrenginį valdo antras klientas.

Būtent pagalbinis scenarijus atšaukia pakeitimus

openconnect pats nepašalina sąsajos, maršrutų ar resolverio įrašų. Jis kviečia išorinį pagalbininką, /etc/vpnc/vpnc-script upstream build’e ir /usr/share/vpnc-scripts/vpnc-script Debian ir Ubuntu paketuose, pasirenkamas su -s. Tas pats scenarijus, kuris pakelia tunelį, jį ir išardo.

Jei procesas baigiasi nepakvietęs to pagalbininko, būsena lieka. OpenConnect vadovas aiškiai nurodo, kad maršrutizavimas ir vardų tarnyba be scenarijaus neveiks tinkamai, ir apibūdina pagalbininką kaip komponentą, kuris išėjus išardo sąsajos būseną. Todėl kelias svarbus, kai paleidžiate klientą su -s.

Kuris signalas pasiekia tą kelią, pasikeitė tarp versijų. 7.06 vadovas SIGTERM laiko tiesioginiu išėjimu, kuris praleidžia scenarijų. Dabartiniai build’ai dokumentuoja INT ir TERM kaip švarų sustabdymą, kai sesija atjungiama ir pagalbininkas paleidžiamas. Skaitykite to dvejetainio failo, kurį iš tikrųjų turite, skyrių SIGNALS, o ne darykite prielaidą apie vieną iš dviejų elgsenų.

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

Nusiųskite signalą, kurį dokumentuoja jūsų build’as

Kai žinosite signalą, sustabdykite procesą pagal pid, o ne pagal šabloną.

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

Tada pakartokite tris patikras iš pirmos dalies, o ne pasikliaukite išėjimo būsena. ip link show tun0 turėtų nepavykti, ip route show dev tun0 neturėtų nieko spausdinti, ir resolvectl status nebeturėtų išvardyti VPN sąsajos.

SIGHUP nėra stabdymo mygtukas: jis atjungia, paleidžia scenarijų ir palieka sesiją atnaujinamą su --cookie. SIGUSR2 priverčia iš karto prisijungti iš naujo. SIGKILL visiškai praleidžia valymą, ir tai yra būtent ta būsena, apie kurią šis straipsnis.

Sutaisykite resolverį nekeisdami resolv.conf

Daugumoje Ubuntu sistemų /etc/resolv.conf yra simbolinė nuoroda į systemd-resolved, o ne failas, kurį turėtumėte redaguoti. Jį pakeitus sugenda vardų sprendimas visiems tinklams, ne tik VPN. Vietoj to pašalinkite tunelio registraciją:

resolvectl revert tun0
resolvectl query example.com

Jei sistema naudoja resolvconf, o ne systemd-resolved, kiekvienos sąsajos įrašas išlieka, kol jam pasakoma atsisakyti sąsajos, ir resolvconf -d tun0 yra lygiavertis veiksmas. Prieš rinkdamiesi komandą patikrinkite, kuris resolveris naudojamas.

Užklausa, vis dar nukreipta į serverį už mirusios sąsajos, kabo, kol baigiasi laikas, ir tas delsimas atrodo kaip sugedęs DNS serveris, o ne kaip likęs maršrutas.

Padarykite kitą atjungimą nuobodų

Laikykite pid failo kelią tą patį paleidžiant ir išjungiant, perduodami --pid-file kiekvieną kartą, arba vykdykite openconnect po unit’u kurio KillSignal atitinka signalą, kurį dokumentuoja jūsų versija. Bandymas pirmiausia pirmame plane parodo išjungimo pranešimus, kuriuos spausdina pagalbininkas.

Prisijunkite, atjunkite ir vieną kartą paleiskite tris patikras. Švarus išėjimas nepalieka nei VPN sąsajos, nei VPN maršruto, nei VPN resolverio įrašo. Jei vienas iš trijų išlieka, dabar žinote, kuris komponentas nesutvarkė. Kitas tyrimas tada prasideda nuo to atsakymo, o ne nuo kabančios užklausos.