AnyConnect valt weg als je een terminal sluit: sessiecontroles

De tunnel staat, je sluit een extra terminal, en de VPN valt weg zonder één toetsaanslag in de client. Bij de Linux AnyConnect-client is de gemelde oorzaak sessieadministratie en niet routering: de client legt vast welke loginsessies er bestonden toen de tunnel opkwam en beschouwt het einde van elk daarvan als reden om hem neer te halen. De controles hieronder lopen in volgorde, en de eerste die faalt vertelt of je überhaupt naar dit gedrag kijkt. Niets in de normale uitvoer van de client noemt een terminal, en daarom is de eerste reflex, de concentrator de schuld geven, meestal verloren moeite.

Begin niet met het bewerken van systeembestanden. Elke stap verklaart ofwel de onderbreking of schrapt een kandidaat, en de goedkope stappen komen eerst.

Onderscheid een sessie-uitval van een uitval in de onderlaag

Verbind direct na de verbreking opnieuw. Een tunnel die binnen enkele seconden terugkomt, op hetzelfde netwerk en zonder nieuwe inloggegevens, wijst op een lokale trigger zoals een gesloten sessie en niet op een dode uplink, Wi-Fi-roaming of een idle-timeout op de concentrator. Een tunnel die blijft hangen op Connecting, of die pas werkt als je van netwerk wisselt, is een ander artikel.

Schrijf op wat er open stond toen de tunnel opkwam: de terminal van waaruit je de client startte, elke tweede shell, de grafische login en elke SSH-sessie vanaf een andere machine. Je hebt die lijst zo nodig, en hem na de volgende uitval uit je geheugen reconstrueren is onbetrouwbaar.

Controleer wat de client bij het verbinden vastlegde

De client inspecteert geen procesouders of terminaleigendom. Hij maakt een momentopname van de set loginsessies die bij het verbinden bestond en vergelijkt die set later; verdwijnt er een lid, dan mislukt de vergelijking en gaat de tunnel mee. Daarom kan het sluiten van het venster waarin je verbond onschuldig zijn, terwijl het sluiten van een losse extra terminal de verbinding doodt: het gaat erom of die sessie in de oorspronkelijke set zat. Het is een setvergelijking en geen telling, en daarom kan een sessie vervangen net zo fataal zijn als er een verliezen.

Som op wat de client kon zien voordat je iets wijzigt:

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

Elke regel van who is een gebruikersprocesregel in utmp. Als je sessie twee keer verschijnt, één keer voor de grafische login en één keer voor de terminal, dan bestonden beide regels bij het verbinden en zijn beide kandidaten.

Verwijder alleen je eigen regel uit utmp

De gepubliceerde workaround maakt de sessie die je gaat gebruiken onzichtbaar in utmp voordat de client start. Een klein C-programma loopt door getutent(), zoekt de regel waarvan ut_line gelijk is aan de TTY van standaardinvoer, en herschrijft die regel. De volgorde is bewust: setutent(), de regel lezen, het ut_id kopiëren, ut_type op DEAD_PROCESS zetten, de gebruiker- en regelvelden wissen, terugschrijven met pututline(), en dan endutent().

Compileer het en start het als root vanuit de shell die de client start:

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

Twee faalmodi verklaren de meeste meldingen dat het hulpmiddel niets doet. Het werkt op de TTY die aan standaardinvoer hangt, dus vanuit een script of cronjob zonder terminal valt er niets te matchen. En /run/utmp is niet schrijfbaar voor gewone gebruikers, dus een run zonder root faalt stil tenzij je de exitstatus controleert.

Controleer of de tunnel het sluiten overleeft

Test het mechanisme in plaats van het aan te nemen. Verbind vanuit een sessie die je wilt houden, open een tweede terminal, sluit de tweede, en bevestig dan met vpn state en een blik op de interfacelijst dat de tunnel nog staat. Overleeft de tunnel, dan was de trigger een bepaald sessietype en niet elke sessie, en heb je de sessie gevonden die open moet blijven.

Valt hij toch weg, dan zat de bewaakte sessie elders, meestal de grafische login die je terminal opstartte, en helpt het strippen van één TTY-regel niet. Herhaal de observatie met de volledige lijst uit de eerste stap in plaats van meer chirurgie toe te voegen.

Wanneer het herschrijven van utmp het verkeerde antwoord is

utmp is gedeelde administratie, geen privétabel. De regel van een sessie die nog leeft herschrijven zorgt dat who, w en sommige audit-tools die sessie te weinig rapporteren, en een programma dat later dezelfde regel sluit kan helemaal falen. Houd het hulpmiddel beperkt tot je eigen sessie, bewaar een kopie van het originele bestand, en maak er geen opstartservice van die elke regel wist.

Als je site sessieadministratie verzamelt voor compliance, dan botst de workaround met die eis en is het ondersteunde antwoord een clientversie of een andere toegangsmethode, niet een gepatchte utmp. Voor de meeste mensen is de minst ingrijpende oplossing simpelweg de client starten vanuit een sessie die de hele dag open blijft en dat venster met rust laten.

Voordat je het ticket sluit, leg vast welke sessie de client bewaakte toen de tunnel opkwam. Die ene regel maakt van een mysterieuze verbreking een reproduceerbare toestand voor de volgende persoon op de machine.