AnyConnect kobler fra når et terminalvindu lukkes: øktkontroller

Tunnelen er oppe, du lukker et ledig terminalvindu, og VPN-en faller uten et eneste tastetrykk i klienten. I Linux-AnyConnect-klienten er den rapporterte årsaken øktregnskap, ikke ruting: klienten registrerer hvilke innloggingsøkter som fantes da tunnelen kom opp, og behandler slutten på hvilken som helst av dem som grunn til å rive den ned. Kontrollene nedenfor kjøres i rekkefølge, og den første som feiler forteller om du i det hele tatt ser denne oppførselen. Ingenting i klientens vanlige utdata nevner et terminalvindu, og derfor er den første impulsen, å skylde på konsentratoren, som regel bortkastet arbeid.

Ikke start med å redigere systemfiler. Hvert steg forklarer enten fallet eller fjerner en kandidat, og de billige stegene kommer først.

Skille et øktfall fra et fall i underlaget

Koble til på nytt rett etter frakoblingen. En tunnel som kommer tilbake i løpet av sekunder, på samme nett, uten nye påloggingsdata, peker på en lokal utløser som en lukket økt, ikke på en død uplink, Wi-Fi-roaming eller en inaktivitetstidsavbrudd på konsentratoren. En tunnel som henger på Connecting, eller som feiler til du bytter nett, er en annen artikkel.

Skriv ned hva som var åpent da tunnelen kom opp: terminalen du kjørte klienten fra, eventuell andre skall, den grafiske innloggingen og eventuell SSH-økt fra en annen maskin. Du trenger lista om litt, og å rekonstruere den fra hukommelsen etter neste fall er upålitelig.

Sjekk hva klienten registrerte ved tilkobling

Klienten undersøker ikke prosessforeldre eller terminaleierskap. Den tar et øyeblikksbilde av settet med innloggingsøkter som finnes ved tilkobling og sammenligner det settet senere; når et medlem forsvinner, feiler sammenligningen og tunnelen går med. Derfor kan det være ufarlig å lukke vinduet du koblet fra, mens lukking av en urelatert ledig terminal dreper forbindelsen: det som teller er om økten var i det opprinnelige settet. Det er en settsammenligning, ikke en telling, og derfor kan det å erstatte en økt være like fatalt som å miste en.

List opp hva klienten kunne se før du endrer noe:

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

Hver linje fra who er en brukerprosessoppføring i utmp. Hvis økten din vises to ganger, én for den grafiske innloggingen og én for terminalen, fantes begge oppføringene ved tilkobling og begge er kandidater.

Fjern bare din egen oppføring fra utmp

Den publiserte omveien gjør økten du skal bruke usynlig i utmp før klienten starter. Et lite C-program går gjennom getutent(), finner posten der ut_line er lik TTY-en til standard inndata, og skriver deretter om posten. Rekkefølgen er med vilje: setutent(), les posten, kopier ut_id, sett ut_type til DEAD_PROCESS, tøm bruker- og linjefeltene, skriv den tilbake med pututline(), deretter endutent().

Kompiler det, og kjør det som root fra skallet som skal starte klienten:

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

To feilmoduser forklarer de fleste rapportene om at verktøyet ikke gjør noe. Det virker på TTY-en som er knyttet til standard inndata, så kjøring fra et skript eller en cron-jobb uten terminal gir det ingenting å matche. Og /run/utmp er ikke skrivbart for vanlige brukere, så en kjøring uten root feiler stille med mindre du sjekker avslutningsstatusen.

Bekreft at tunnelen overlever lukkingen

Test mekanismen i stedet for å anta den. Koble til fra en økt du vil beholde, åpne en andre terminal, lukk den andre, og bekreft deretter at tunnelen fortsatt er oppe med vpn state og et blikk på grensesnittlista. Hvis tunnelen overlever, var utløseren en bestemt økttype og ikke hver økt, og du har funnet økten som må holdes åpen.

Hvis den fortsatt faller, var den overvåkede økten et annet sted, oftest den grafiske innloggingen som startet terminalen din, og å fjerne én TTY-oppføring hjelper ikke. Gjenta observasjonen med hele lista fra første steg i stedet for å legge til mer kirurgi.

Når omskriving av utmp er feil svar

utmp er delt regnskap, ikke en privat tabell. Å skrive om posten til en økt som fortsatt lever gjør at who, w og noen revisjonsverktøy rapporterer den for lite, og et program som senere lukker samme post kan feile helt. Hold verktøyet begrenset til din egen økt, ta vare på en kopi av originalfilen, og ikke gjør det til en oppstartstjeneste som fjerner hver post.

Hvis nettstedet ditt samler øktregnskap for etterlevelse, er omveien i konflikt med det kravet, og det støttede svaret er en klientversjon eller en annen tilgangsmetode, ikke en lappet utmp. For de fleste er den minst inngripende løsningen rett og slett å starte klienten fra en økt som blir stående åpen hele dagen, og la det vinduet være.

Før du lukker saken, skriv ned hvilken økt klienten overvåket da tunnelen kom opp. Den ene linjen er det som gjør en mystisk frakobling til en reproduserbar betingelse for neste person på maskinen.