AnyConnect falt út as in terminal slút: sesjekontrôles

De tunnel is oan, jo slute in oerstallich terminal, en de VPN falt út sûnder ien toetsdruk yn de klient. By de Linux-AnyConnect-klient is de rapportearre oarsaak sesje-administraasje en net routing: de klient registrearret hokker oanmeldingssesjes der bestienen doe't de tunnel omheech kaam en beskôget it ein fan elk dêrfan as reden om him del te heljen. De kontrôles hjirûnder rinne yn folchoarder, en de earste dy't mislearret fertelt jo oft jo dit gedrach uberhapt sjogge. Neat yn 'e gewoane útfier fan 'e klient neamt in terminal, dêrom is de earste ympuls, de konsintrator de skuld jaan, meastentiids fergrieme muoite.

Begjin net mei it bewurkjen fan systeembestanden. Eltse stap ferklearret of de fal of hellet in kandidaat fuort, en de goedkeape stappen komme earst.

Skied in sesjefal fan in fal fan it ûnderlizzende netwurk

Ferbyn jo fuortendaliks opnij nei de ferbrekking. In tunnel dy't binnen sekonden weromkomt, op itselde netwurk, sûnder nije oanmeldgegevens, wiist op in lokale trigger lykas in sletten sesje en net op in deade uplink, Wi-Fi-roming of in idle-timeout op de konsintrator. In tunnel dy't hinget op Connecting, of dy't mislearret oant jo fan netwurk feroarje, is in oar artikel.

Skriuw op wat iepen wie doe't de tunnel omheech kaam: it terminal fan wêr't jo de klient draaiden, elk twadde shell, de grafyske oanmelding en elk SSH-sesje fan in oare masine. Jo hawwe dy list oer in momint nedich, en it weromrekonstruearjen út it ûnthâld nei de folgjende fal is net betrouber.

Kontrolearje wat de klient by it ferbinen registrearre

De klient ûndersiket gjin prosesâlden of terminaleigendom. Hy nimt in momentopname fan 'e set oanmeldingssesjes dy't by it ferbinen oanwêzich wiene en fergeliket dy set letter; as in lid ferdwynt, mislearret de fergeliking en de tunnel giet mei. Dêrom kin it sluten fan it finster fan wêr't jo ferbûn hawwe harmless wêze, wylst it sluten fan in net-relatearre oerstallich terminal de ferbining deatet: wat telt is oft dy sesje yn 'e oarspronklike set siet. De kontrôle is in setfergeliking en gjin telling, dêrom kin it ferfangen fan in sesje like fataal wêze as it ferliezen fan ien.

List op wat de klient sjen koe foardat jo eat feroarje:

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

Elke rigel fan who is in brûkersprosesynfiering yn utmp. As jo sesje twa kear ferskynt, ien kear foar de grafyske oanmelding en ien kear foar it terminal, dan bestienen beide ynfieringen by it ferbinen en beide binne kandidaten.

Ferwiderje allinnich jo eigen ynfiering út utmp

De publisearre omwei makket de sesje dy't jo op it punt steane te brûken ûnsichtber yn utmp foardat de klient start. In lyts C-programma rint troch getutent(), fynt it record wêrfan de ut_line gelyk is oan de TTY fan standertynfier, en skriuwt dat record dan oer. De folchoarder is bewust: setutent(), lês de ynfiering, kopiearje syn ut_id, set ut_type op DEAD_PROCESS, wiskje de brûker- en rigelfjilden, skriuw it werom mei pututline(), en dan endutent().

Kompilearje it, en draai it dan as root út 'e shell dy't de klient start:

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

Twa mislearringsmodi ferklearje de measte rapporten dat it ark neat docht. It wurket op 'e TTY dy't oan standertynfier hinget, dus it draaien út in skript of cron-taak sûnder terminal lit it neat hawwe om te ferlykjen. En /run/utmp is net skriuwber foar gewoane brûkers, dus in run sûnder root mislearret stil, útsein as jo de útgongstatus kontrolearje.

Kontrolearje dat de tunnel it sluten oerlibbet

Test it meganisme ynstee fan it oan te nimmen. Ferbyn jo út in sesje dy't jo fan plan binne te hâlden, iepenje in twadde terminal, slút it twadde, en befêstigje dan dat de tunnel noch oan is mei vpn state en in each op 'e ynterface-list. As de tunnel oerlibbet, wie de trigger in bepaald sesjetype en net elke sesje, en jo hawwe de sesje fûn dy't iepen bliuwe moat.

As er noch altiten falt, wie de besjoen sesje earne oars, meastentiids de grafyske oanmelding dy't jo terminal makke hat, en it strippen fan ien TTY-ynfiering sil net helpe. Werhelje de observaasje mei de folsleine list fan 'e earste stap ynstee fan mear sjirurgy ta te foegjen.

Wannear't it oerskriuwen fan utmp it ferkearde antwurd is

utmp is dielde administraasje, gjin priveetabel. It oerskriuwen fan 'e ynfiering fan in sesje dy't noch libbet makket dat who, w en guon audit-ark dy ûnderrapportearje, en in programma dat letter deselde ynfiering slút kin folslein mislearje. Hâld it ark beheind ta jo eigen sesje, bewarje in kopy fan it orizjinele bestân, en meitsje der gjin boottsjinst fan dy't elk record strips.

As jo site sesje-administraasje sammelt foar neilibjen, dan is de omwei yn striid mei dy eask en it stipe antwurd is in oare klientferzje of in oare tagongsmetoade, net in patched utmp. Foar de measte minsken is de minst yngeande oplossing gewoan de klient starte út in sesje dy't de hiele dei iepen bliuwt en dat finster gewurde litte.

Foardat jo it ticket slute, registrearje hokker sesje de klient besjoen doe't de tunnel omheech kaam. Krekt dy iene rigel feroaret in mysterieuze ferbrekking yn in werhelber betingst foar de folgjende persoan op 'e masine.