AnyConnect dett ut når eit terminalvindauge blir lukka: øktkontrollar

Tunnelen er oppe, du lukkar eit ledig terminalvindauge, og VPN-en dett ut utan eitt einaste tastetrykk i klienten. I Linux-AnyConnect-klienten er den rapporterte årsaka øktrekneskap, ikkje ruting: klienten registrerer kva innloggingsøkter som fanst då tunnelen kom opp, og handsamar slutten på kva som helst av dei som grunn til å rive han ned. Kontrollane nedanfor går i rekkjefølgje, og den første som feilar fortel om du i det heile ser denne åtferda. Ingenting i dei vanlege utdataa til klienten nemner eit terminalvindauge, og difor er den første impulsen, å skylde på konsentratoren, som regel bortkasta arbeid.

Ikkje start med å redigere systemfiler. Kvart steg forklarer anten fallet eller fjernar ein kandidat, og dei billege stega kjem først.

Skilje eit øktfall frå eit fall i underlaget

Kopla til på nytt rett etter fråkoblinga. Ein tunnel som kjem tilbake i løpet av sekund, på same nett, utan nye påloggingsdata, peikar på ein lokal utløysar som ei lukka økt, ikkje på ein daud uplink, Wi-Fi-roaming eller eit inaktivitetstidsavbrot på konsentratoren. Ein tunnel som heng på Connecting, eller som feilar til du byter nett, er ein annan artikkel.

Skriv ned kva som var ope då tunnelen kom opp: terminalen du køyrde klienten frå, eventuelt andre skal, den grafiske innlogginga og eventuell SSH-økt frå ein annan maskin. Du treng lista om litt, og å rekonstruere ho frå minnet etter neste fall er upåliteleg.

Sjekk kva klienten registrerte ved tilkopling

Klienten granskar ikkje prosessforeldre eller terminaleige. Han tek eit augeblinksbilete av settet med innloggingsøkter som finst ved tilkopling og samanliknar det settet seinare; når eit medlem forsvinn, feilar samanlikninga og tunnelen går med. Difor kan det vere ufarleg å lukke vindauget du kopla frå, medan lukking av ein urelatert ledig terminal drep sambandet: det som tel er om økta var i det opphavlege settet. Det er ein settsamanliknad, ikkje ei teljing, og difor kan det å bytte ut ei økt vere like fatalt som å miste ei.

List opp kva klienten kunne sjå før du endrar noko:

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

Kvar linje frå who er ein brukarprosessoppføring i utmp. Viss økta di viser seg to gonger, éin for den grafiske innlogginga og éin for terminalen, fanst båe oppføringane ved tilkopling og båe er kandidatar.

Fjern berre di eiga oppføring frå utmp

Den publiserte omvegen gjer økta du skal bruke usynleg i utmp før klienten startar. Eit lite C-program går gjennom getutent(), finn posten der ut_line er lik TTY-en til standard inndata, og skriv deretter om posten. Rekkjefølgja er med vilje: setutent(), les posten, kopier ut_id, set ut_type til DEAD_PROCESS, tøm brukar- og linjefelta, skriv han tilbake med pututline(), deretter endutent().

Kompiler det, og køyr det som root frå skalet som skal starte klienten:

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

To feilmodusar forklarer dei fleste rapportane om at verktøyet ikkje gjer noko. Det verkar på TTY-en som er knytt til standard inndata, så køyring frå eit skript eller ein cron-jobb utan terminal gjev det ingenting å matche. Og /run/utmp er ikkje skrivbart for vanlege brukarar, så ei køyring utan root feilar stille med mindre du sjekkar avslutningsstatusen.

Stadfest at tunnelen overlever lukkinga

Test mekanismen i staden for å gå ut frå han. Kopla til frå ei økt du vil behalde, opne ein andre terminal, lukk den andre, og stadfest deretter at tunnelen framleis er oppe med vpn state og eit blikk på grensesnittlista. Viss tunnelen overlever, var utløysaren ein bestemt økttype og ikkje kvar økt, og du har funne økta som må haldast open.

Viss han framleis dett, var den overvaka økta ein annan stad, oftast den grafiske innlogginga som starta terminalen din, og å fjerne éi TTY-oppføring hjelper ikkje. Gjenta observasjonen med heile lista frå første steg i staden for å leggje til meir kirurgi.

Når omskriving av utmp er feil svar

utmp er delt rekneskap, ikkje ein privat tabell. Å skrive om posten til ei økt som framleis lever gjer at who, w og nokre revisjonsverktøy rapporterer ho for lite, og eit program som seinare lukkar same posten kan feile heilt. Hald verktøyet avgrensa til di eiga økt, ta vare på ein kopi av originalfila, og ikkje gjer det til ein oppstartsteneste som fjernar kvar post.

Viss nettstaden din samlar øktrekneskap for etterleving, er omvegen i konflikt med det kravet, og det støtta svaret er ein klientversjon eller ein annan tilgangsmetode, ikkje ein lappa utmp. For dei fleste er den minst inngripande løysinga rett og slett å starte klienten frå ei økt som blir ståande open heile dagen, og la det vindauget vere.

Før du lukkar saka, skriv ned kva økt klienten overvaka då tunnelen kom opp. Den eine linja er det som gjer ei mystisk fråkobling til ein reproduserbar tilstand for neste person på maskina.