AnyConnect kopplar ner när ett terminalfönster stängs: sessionskontroller

Tunneln är uppe, du stänger ett extra terminalfönster och VPN:en faller utan ett enda tangenttryck i klienten. I Linux-klienten för AnyConnect är den rapporterade orsaken sessionsredovisning och inte routing: klienten registrerar vilka inloggningssessioner som fanns när tunneln kom upp och behandlar slutet på vilken som helst av dem som skäl att riva den. Kontrollerna nedan körs i ordning, och den första som fallerar säger om du ens tittar på detta beteende. Inget i klientens vanliga utdata nämner en terminal, och därför är den första impulsen, att skylla på concentratorn, oftast bortkastat arbete.

Börja inte med att redigera systemfiler. Varje steg antingen förklarar fallet eller tar bort en kandidat, och de billiga stegen kommer först.

Skilj ett sessionsfall från ett fall i underliggande lager

Återanslut omedelbart efter frånkopplingen. En tunnel som kommer tillbaka inom sekunder, på samma nät och utan nya inloggningsuppgifter, pekar på en lokal utlösare som en stängd session och inte på en död uplänk, Wi-Fi-roaming eller en inaktivitetsgräns på concentratorn. En tunnel som hänger på Connecting, eller som misslyckas tills du byter nät, är en annan artikel.

Skriv ner vad som var öppet när tunneln kom upp: terminalen du körde klienten från, eventuellt andra skal, den grafiska inloggningen och eventuell SSH-session från en annan maskin. Listan behövs om en stund, och att rekonstruera den ur minnet efter nästa fall är opålitligt.

Kontrollera vad klienten registrerade vid anslutningen

Klienten inspekterar inte processföräldrar eller terminalägande. Den tar en ögonblicksbild av mängden inloggningssessioner som fanns vid anslutningen och jämför den mängden senare; när en medlem försvinner misslyckas jämförelsen och tunneln följer med. Därför kan det vara ofarligt att stänga fönstret du anslöt från, medan stängning av en orelaterad extra terminal dödar förbindelsen: det som avgör är om sessionen fanns i den ursprungliga mängden. Det är en mängdjämförelse och inte en räkning, och därför kan det vara lika fatalt att ersätta en session som att förlora en.

Lista vad klienten kunde se innan du ändrar något:

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

Varje rad från who är en användarprocesspost i utmp. Om din session syns två gånger, en för den grafiska inloggningen och en för terminalen, fanns båda posterna vid anslutningen och båda är kandidater.

Ta bort bara din egen post från utmp

Den publicerade kringgången gör sessionen du ska använda osynlig i utmp innan klienten startar. Ett litet C-program går genom getutent(), hittar posten vars ut_line är lika med TTY:n för standardindata och skriver sedan om posten. Ordningen är avsiktlig: setutent(), läs posten, kopiera dess ut_id, sätt ut_type till DEAD_PROCESS, rensa användar- och radfälten, skriv tillbaka med pututline(), sedan endutent().

Kompilera det och kör det sedan som root från skalet som ska starta klienten:

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

Två fellägen förklarar de flesta rapporter om att verktyget inte gör något. Det verkar på TTY:n som är kopplad till standardindata, så körning från ett skript eller ett cron-jobb utan terminal lämnar inget att matcha. Och /run/utmp är inte skrivbar för vanliga användare, så en körning utan root misslyckas tyst om du inte kontrollerar utgångsstatusen.

Bekräfta att tunneln överlever stängningen

Testa mekanismen i stället för att anta den. Anslut från en session du tänker behålla, öppna en andra terminal, stäng den andra och bekräfta sedan med vpn state och en blick på gränssnittslistan att tunneln fortfarande är uppe. Om tunneln överlever var utlösaren en viss sessionstyp och inte varje session, och du har hittat sessionen som måste hållas öppen.

Om den fortfarande faller satt den övervakade sessionen någon annanstans, oftast den grafiska inloggning som startade din terminal, och att ta bort en TTY-post hjälper inte. Upprepa observationen med hela listan från första steget i stället för att lägga till mer kirurgi.

När omskrivning av utmp är fel svar

utmp är delad redovisning, inte en privat tabell. Att skriva om posten för en session som fortfarande lever gör att who, w och vissa granskningsverktyg rapporterar den för lite, och ett program som senare stänger samma post kan misslyckas helt. Håll verktyget begränsat till din egen session, spara en kopia av originalfilen och gör det inte till en uppstartstjänst som rensar varje post.

Om din organisation samlar in sessionsredovisning för efterlevnad krockar kringgången med det kravet, och det stödda svaret är en klientversion eller en annan åtkomstmetod, inte en patchad utmp. För de flesta är den minst ingripande lösningen helt enkelt att starta klienten från en session som står öppen hela dagen och låta det fönstret vara.

Innan du stänger ärendet, skriv ner vilken session klienten bevakade när tunneln kom upp. Den enda raden gör en mystisk frånkoppling till ett reproducerbart villkor för nästa person vid maskinen.