AnyConnect falder, når en terminal lukkes: sessionskontroller

Tunnelen er oppe, du lukker en ekstra terminal, og VPN falder uden et eneste tastetryk i klienten. På Linux-klienten til AnyConnect er den rapporterede årsag sessionsbogholderi og ikke routing: klienten registrerer, hvilke loginsessioner der fandtes, da tunnelen kom op, og behandler afslutningen af enhver af dem som grund til at rive den ned. Kontrollerne nedenfor køres i rækkefølge, og den første, der fejler, fortæller dig, om du overhovedet står med denne adfærd. Intet i klientens sædvanlige output nævner en terminal, og derfor er den første indskydelse, at give koncentratoren skylden, som regel spildt arbejde.

Begynd ikke med at redigere systemfiler. Hvert trin forklarer enten faldet eller fjerner en kandidat, og de billige trin kommer først.

Adskil et sessionsfald fra et fald i det underliggende netværk

Genopret forbindelsen straks efter afbrydelsen. En tunnel, der er tilbage inden for sekunder, på samme netværk, uden nye legitimationsoplysninger, peger på en lokal udløser som en lukket session frem for et dødt uplink, Wi-Fi-roaming eller en idle-timeout på koncentratoren. En tunnel, der hænger på Connecting eller fejler, indtil du skifter netværk, er en anden artikel.

Skriv ned, hvad der var åbent, da tunnelen kom op: terminalen, du startede klienten fra, enhver anden shell, det grafiske login og enhver SSH-session fra en anden maskine. Du får brug for listen om lidt, og det er upålideligt at rekonstruere den fra hukommelsen efter næste fald.

Kontroller, hvad klienten registrerede ved forbindelsen

Klienten undersøger ikke procesforældre eller terminalejerskab. Den tager et øjebliksbillede af mængden af loginsessioner, der var til stede ved forbindelsen, og sammenligner den mængde senere; når et medlem forsvinder, fejler sammenligningen, og tunnelen går med. Derfor kan det være harmløst at lukke det vindue, du oprettede forbindelsen fra, mens lukning af en uvedkommende ekstra terminal dræber forbindelsen: det afgørende er, om den session var i den oprindelige mængde. Kontrollen er en mængdesammenligning og ikke en optælling, og derfor kan udskiftning af en session være lige så fatal som at miste en.

List, hvad klienten kunne se, før du ændrer noget:

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

Hver linje fra who er en brugerprocespost i utmp. Hvis din session optræder to gange, en gang for det grafiske login og en gang for terminalen, fandtes begge poster ved forbindelsen, og begge er kandidater.

Fjern kun din egen post fra utmp

Den offentliggjorte workaround gør den session, du er ved at bruge, usynlig i utmp, før klienten starter. Et lille C-program gennemløber getutent(), finder den post, hvis ut_line svarer til TTY for standardinput, og omskriver derefter posten. Rækkefølgen er bevidst: setutent(), læs posten, kopiér dens ut_id, sæt ut_type til DEAD_PROCESS, ryd felterne for bruger og linje, skriv den tilbage med pututline() og derefter endutent().

Kompilér det, og kør det derefter som root fra den shell, der skal starte klienten:

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

To fejltilstande forklarer de fleste rapporter om, at værktøjet intet gør. Det virker på det TTY, der er knyttet til standardinput, så kørsel fra et script eller et cron-job uden terminal efterlader det intet at matche. Og /run/utmp kan ikke skrives af almindelige brugere, så en kørsel uden root fejler lydløst, medmindre du kontrollerer exitstatus.

Bekræft, at tunnelen overlever lukningen

Test mekanismen i stedet for at antage den. Opret forbindelse fra en session, du agter at beholde, åbn en ekstra terminal, luk den anden, og bekræft derefter med vpn state og et blik på grænsefladelisten, at tunnelen stadig er oppe. Overlever den, var udløseren en bestemt sessionstype og ikke enhver session, og du har fundet den session, der skal holdes åben.

Falder den stadig, var den overvågede session et andet sted, oftest det grafiske login, der startede din terminal, og det hjælper ikke at fjerne en enkelt TTY-post. Gentag observationen med den fulde liste fra første trin i stedet for at tilføje mere kirurgi.

Når omskrivningen af utmp er det forkerte svar

utmp er fælles bogholderi, ikke en privat tabel. At omskrive posten for en session, der stadig er levende, får who, w og visse revisionsværktøjer til at underrapportere den, og et program, der senere lukker samme post, kan fejle helt. Hold værktøjet begrænset til din egen session, gem en kopi af den oprindelige fil, og gør det ikke til en boottjeneste, der fjerner hver post.

Hvis din organisation indsamler sessionsbogholderi til compliance, strider workarounden mod det krav, og det understøttede svar er en anden klientversion eller en anden adgangsmetode, ikke en patchet utmp. For de fleste er den mindst indgribende løsning ganske enkelt at starte klienten fra en session, der bliver åben hele dagen, og lade det vindue være.

Før du lukker sagen, skal du notere, hvilken session klienten overvågede, da tunnelen kom op. Netop den ene linje gør en mystisk afbrydelse til en reproducerbar betingelse for den næste person ved maskinen.