AnyConnect falas kiam terminalo fermiĝas: sesiaj kontroloj

La tunelo estas supren, vi fermas rezervan terminalon, kaj la VPN falas sen eĉ unu klakado en la kliento. Ĉe la Linux-kliento AnyConnect la raportita kaŭzo estas sesia librotenado, ne enkursigo: la kliento registras kiuj ensalutaj sesioj ekzistis kiam la tunelo leviĝis kaj traktas la finon de iu ajn el ili kiel kaŭzon por detrui ĝin. La subaj kontroloj plenumiĝas laŭvice, kaj la unua malsukcesa diras al vi ĉu vi entute rigardas ĉi tiun konduton. Nenio en la kutima eligo de la kliento mencias terminalon, tial la unua instinkto, kulpigi la koncentrilon, kutime estas vana peno.

Ne komencu per redaktado de sistemaj dosieroj. Ĉiu paŝo aŭ klarigas la falon aŭ forigas kandidaton, kaj la malmultekostaj paŝoj venas unue.

Apartigu sesian falon disde falo de la suba reto

Rekonektiĝu tuj post la malkonekto. Tunelo, kiu revenas ene de sekundoj, en la sama reto, sen novaj akreditaĵoj, indikas lokan kaŭzanton kiel fermita sesio, ne mortan supran ligon, Wi-Fi-romadon aŭ senaktivan tempolimon ĉe la koncentrilo. Tunelo, kiu pendas ĉe Connecting, aŭ kiu malsukcesas ĝis vi ŝanĝas reton, estas alia artikolo.

Notu kio estis malfermita kiam la tunelo leviĝis: la terminalo el kiu vi lanĉis la klienton, iu dua ŝelo, la grafika ensaluto, kaj iu ajn SSH-sesio el alia maŝino. Vi bezonos tiun liston post momento, kaj rekonstrui ĝin el memoro post la sekva falo estas nefidinda.

Kontrolu kion la kliento registris ĉe la konekto

La kliento ne ekzamenas procesajn gepatrojn aŭ terminalan posedon. Ĝi prenas momentfoton de la aro de ensalutaj sesioj ĉeestantaj ĉe la konekto kaj poste komparas tiun aron; kiam membro malaperas, la komparo malsukcesas kaj la tunelo iras kun ĝi. Tial fermi la fenestron el kiu vi konektiĝis povas esti sendanĝera, dum fermi senrilatan rezervan terminalon mortigas la konekton: gravas ĉu tiu sesio estis en la origina aro. La kontrolo estas komparo de aroj, ne nombrado, tial anstataŭigi sesion povas esti same fatala kiel perdi unu.

Listigu kion la kliento povis vidi antaŭ ol vi ŝanĝos ion:

who
w
last -n 10
sudo ls -l /run/utmp

Ĉiu linio de who estas uzanta proceza ero en utmp. Se via sesio aperas dufoje, unufoje por la grafika ensaluto kaj unufoje por la terminalo, ambaŭ eroj ekzistis ĉe la konekto kaj ambaŭ estas kandidatoj.

Forigu nur vian propran eron el utmp

La publikigita solvo igas la sesion, kiun vi tuj uzos, nevidebla en utmp antaŭ ol la kliento startas. Malgranda C-programo trairas getutent(), kongruas la rikordon kies ut_line egalas la TTY de la norma enigo, kaj poste reskribas tiun rikordon. La ordo estas intenca: setutent(), legu la eron, kopiu ĝian ut_id, agordu ut_type al DEAD_PROCESS, malplenigu la kampojn de uzanto kaj linio, reskribu ĝin per pututline(), poste endutent().

Kompilu ĝin, poste rulu ĝin kiel root el la ŝelo, kiu lanĉos la klienton:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Du fiaskaj manieroj klarigas la plej multajn raportojn, ke la ilo faras nenion. Ĝi agas sur la TTY alligita al la norma enigo, do ruli ĝin el skripto aŭ cron-tasko sen terminalo lasas al ĝi nenion por kongrui. Kaj /run/utmp ne estas skribebla de ordinaraj uzantoj, do rulado sen root silentas malsukcese se vi ne kontrolas la eligan staton.

Kontrolu ĉu la tunelo postvivas la fermon

Testu la mekanismon anstataŭ supozi ĝin. Konektiĝu el sesio, kiun vi intencas teni, malfermu duan terminalon, fermu la duan, poste konfirmu per vpn state kaj rigardo al la interfaca listo, ke la tunelo ankoraŭ estas supren. Se la tunelo postvivas, la kaŭzanto estis specifa sesia tipo, ne ĉiu sesio, kaj vi trovis la sesion, kiu devas resti malfermita.

Se ĝi ankoraŭ falas, la observata sesio estis aliloke, plej ofte la grafika ensaluto, kiu generis vian terminalon, kaj forigi unu TTY-eron ne helpos. Ripetu la observon kun la plena listo el la unua paŝo anstataŭ aldoni pli da kirurgio.

Kiam la reskribo de utmp estas la malĝusta respondo

utmp estas komuna librotenado, ne privata tabelo. Reskribi la eron de sesio, kiu ankoraŭ vivas, igas who, w kaj kelkajn reviziajn ilojn raporti ĝin sub la reala, kaj programo, kiu poste fermos la saman eron, povas tute fiaski. Tenu la ilon limigita al via propra sesio, konservu kopion de la originala dosiero, kaj ne faru el ĝi praŝargan servon, kiu forigas ĉiun rikordon.

Se via organizo kolektas sesian librotenadon por kongruo, la solvo kontraŭas tiun postulon kaj la subtenata respondo estas alia klienta versio aŭ alia alirmetodo, ne flikita utmp. Por la plej multaj homoj la malplej truda riparo estas simple lanĉi la klienton el sesio, kiu restos malfermita la tutan tagon, kaj lasi tiun fenestron trankvila.

Antaŭ ol vi fermos la bileton, notu kiun sesion la kliento observis kiam la tunelo leviĝis. Ĝuste tiu unu linio transformas misteran malkonekton en ripeteblan kondiĉon por la sekva persono ĉe la maŝino.