AnyConnect val weg wanneer 'n terminaal sluit: sessiekontroles

Die tonnel is op, jy maak 'n oortollige terminaal toe, en die VPN gaan af sonder 'n enkele toetsdruk in die kliënt. By die Linux AnyConnect-kliënt is die gerapporteerde oorsaak sessieboekhouding eerder as routering: die kliënt teken aan watter aanmeldingsessies bestaan het toe die tonnel opgekom het, en beskou die einde van enige van hulle as 'n rede om dit af te breek. Die kontroles hieronder loop in volgorde, en die eerste een wat misluk, sê vir jou of jy hoegenaamd na hierdie gedrag kyk. Niks in die kliënt se gewone uitvoer noem 'n terminaal nie, en daarom is die eerste instink, om die konsentrator te blameer, gewoonlik vermorste moeite.

Moenie begin deur stelsellêers te wysig nie. Elke stap verduidelik óf die onderbreking óf verwyder 'n kandidaat, en die goedkoop stappe kom eerste.

Skei 'n sessie-onderbreking van 'n onderlaag-onderbreking

Herverbind onmiddellik ná die ontkoppeling. 'n Tonnel wat binne sekondes terugkom, op dieselfde netwerk, sonder nuwe geloofsbriewe, dui op 'n plaaslike sneller soos 'n geslote sessie eerder as 'n dooie opverbinding, Wi-Fi-swerf of 'n ledige tydsversaking op die konsentrator. 'n Tonnel wat op Connecting hang, of wat misluk totdat jy netwerke verander, is 'n ander artikel.

Skryf neer wat oop was toe die tonnel opgekom het: die terminaal van waar jy die kliënt geloop het, enige tweede skulp, die grafiese aanmelding, en enige SSH-sessie vanaf 'n ander masjien. Jy het daardie lys binnekort nodig, en om dit ná die volgende onderbreking uit die geheue te herkonstrueer, is onbetroubaar.

Kontroleer wat die kliënt by die verbinding aangeteken het

Die kliënt ondersoek nie prosesouers of terminaaleienaarskap nie. Dit neem 'n momentopname van die stel aanmeldingsessies wat by die verbinding bestaan het en vergelyk daardie stel later; wanneer 'n lid verdwyn, misluk die vergelyking en die tonnel gaan saam. Daarom kan die sluit van die venster waarvandaan jy verbind het onskadelik wees, terwyl die sluit van 'n onverwante oortollige terminaal die verbinding doodmaak: wat saak maak, is of daardie sessie in die oorspronklike stel was. Die kontrole is 'n stelvergelyking eerder as 'n telling, en daarom kan die vervanging van 'n sessie net so noodlottig wees as om een te verloor.

Lys wat die kliënt kon sien voordat jy enigiets verander:

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

Elke reël van who is 'n gebruikersproses-inskrywing in utmp. As jou sessie twee keer verskyn, een keer vir die grafiese aanmelding en een keer vir die terminaal, het albei inskrywings by die verbinding bestaan en albei is kandidate.

Verwyder net jou eie inskrywing uit utmp

Die gepubliseerde oplossing maak die sessie wat jy op die punt is om te gebruik onsigbaar in utmp voordat die kliënt begin. 'n Klein C-program loop deur getutent(), pas die rekord wie se ut_line gelyk is aan die TTY van standaardinsette, en herskryf dan daardie rekord. Die volgorde is doelbewus: setutent(), lees die inskrywing, kopieer sy ut_id, stel ut_type op DEAD_PROCESS, maak die gebruiker- en lynvelde skoon, skryf dit terug met pututline(), en dan endutent().

Kompileer dit en hardloop dit dan as root vanaf die skulp wat die kliënt sal begin:

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

Twee mislukkingsmodusse verantwoord die meeste verslae dat die gereedskap niks doen nie. Dit werk op die TTY wat aan standaardinsette gekoppel is, so om dit vanuit 'n script of 'n cron-taak sonder 'n terminaal te hardloop, laat niks om aan te pas nie. En /run/utmp is nie deur gewone gebruikers skryfbaar nie, so 'n loop sonder root misluk stilweg tensy jy die uitgangstatus nagaan.

Verifieer dat die tonnel die sluiting oorleef

Toets die meganisme eerder as om dit te aanvaar. Verbind vanaf 'n sessie wat jy van plan is om oop te hou, maak 'n tweede terminaal oop, maak die tweede een toe, en bevestig dan dat die tonnel nog op is met vpn state en 'n blik op die koppelvlaklys. As die tonnel oorleef, was die sneller 'n spesifieke sessietipe eerder as elke sessie, en jy het die sessie gevind wat oop moet bly.

As dit steeds val, was die dopgehoude sessie elders — meestal die grafiese aanmelding wat jou terminaal geskep het — en om een TTY-inskrywing te stroop sal nie help nie. Herhaal die waarneming met die volledige lys van die eerste stap eerder as om meer chirurgie by te voeg.

Wanneer die utmp-herskrywing die verkeerde antwoord is

utmp is gedeelde boekhouding, nie 'n private tabel nie. Om die inskrywing van 'n sessie wat nog leef te herskryf, maak dat who, w en sommige ouditgereedskap dit onderrapporteer, en 'n program wat later dieselfde inskrywing sluit, kan heeltemal misluk. Hou die gereedskap beperk tot jou eie sessie, hou 'n kopie van die oorspronklike lêer, en moenie dit in 'n opstartdiens verander wat elke rekord stroop nie.

As jou werf sessieboekhouding vir nakoming insamel, bots die oplossing met daardie vereiste en die ondersteunde antwoord is 'n kliëntweergawe of 'n ander toegangsmetode, nie 'n gepakte utmp nie. Vir die meeste mense is die mins indringende oplossing bloot om die kliënt vanaf 'n sessie te begin wat die hele dag oop sal bly en daardie venster alleen te laat.

Voordat jy die kaartjie sluit, teken aan watter sessie die kliënt dopgehou het toe die tonnel opgekom het. Daardie enkele reël is wat 'n raaiselagtige ontkoppeling in 'n herhaalbare toestand vir die volgende persoon op die masjien verander.