AnyConnect shkëputet kur mbyllni një terminal: kontrollet e sesioneve

Tuneli është lart, ju mbyllni një terminal rezervë dhe VPN-ja bie pa asnjë shtypje taste në klient. Në klientin AnyConnect për Linux shkaku i raportuar është kontabiliteti i sesioneve, jo rrugëzimi: klienti regjistron cilat sesione hyrjeje ekzistonin kur u ngrit tuneli dhe e trajton përfundimin e secilit prej tyre si arsye për ta rrëzuar. Kontrollet më poshtë kryhen me radhë, dhe e para që dështon ju tregon nëse po e shihni fare këtë sjellje. Asgjë në daljen e zakonshme të klientit nuk përmend një terminal, prandaj instinkti i parë, fajësimi i koncentratorit, zakonisht është punë e humbur.

Mos filloni duke redaktuar skedarë të sistemit. Çdo hap ose e shpjegon rënien ose heq një kandidat, dhe hapat e lirë vijnë të parët.

Ndani një rënie sesioni nga një rënie e shtresës bazë

Rilidhuni menjëherë pas shkëputjes. Një tunel që kthehet brenda sekondave, në të njëjtin rrjet dhe pa kredenciale të reja, tregon një shkaktar lokal si një sesion i mbyllur, jo një uplink të vdekur, roaming Wi-Fi ose një afat të pafundësisë në koncentrator. Një tunel që rri varur në Connecting, ose që dështon derisa të ndryshoni rrjetin, është një artikull tjetër.

Shkruani çfarë ishte hapur kur u ngrit tuneli: terminali nga i cili ekzekutuat klientin, çdo shell i dytë, hyrja grafike dhe çdo sesion SSH nga një makinë tjetër. Kjo listë do t'ju duhet pas një çasti, dhe rindërtimi i saj nga kujtesa pas rënies tjetër nuk është i besueshëm.

Kontrolloni çfarë regjistroi klienti në çastin e lidhjes

Klienti nuk inspekton prindërit e proceseve apo pronësinë e terminalit. Ai bën një fotografi të bashkësisë së sesioneve të hyrjes të pranishme në çastin e lidhjes dhe më vonë e krahason atë bashkësi; kur një anëtar zhduket, krahasimi dështon dhe tuneli shkon me të. Prandaj mbyllja e dritares nga e cila u lidhët mund të jetë e padëmshme, ndërsa mbyllja e një terminali rezervë të palidhur e vret lidhjen: rëndësi ka nëse ai sesion ishte në bashkësinë fillestare. Është krahasim bashkësish, jo numërim, prandaj zëvendësimi i një sesioni mund të jetë po aq fatal sa humbja e njërit.

Listoni çfarë klienti mund të shihte përpara se të ndryshoni gjë:

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

Çdo rresht nga who është një zë procesi përdoruesi në utmp. Nëse sesioni juaj shfaqet dy herë, një herë për hyrjen grafike dhe një herë për terminalin, të dy zërat ekzistonin në çastin e lidhjes dhe të dy janë kandidatë.

Hiqni nga utmp vetëm zërin tuaj

Zgjidhja e publikuar e bën të padukshëm në utmp sesionin që do të përdorni, përpara se klienti të nisë. Një program i vogël në C kalon nëpër getutent(), gjen regjistrin, ut_line i të cilit është i barabartë me TTY-në e hyrjes standarde, dhe pastaj e rishkruan atë regjistër. Radha është e qëllimshme: setutent(), lexo zërin, kopjo ut_id e tij, vendos ut_type në DEAD_PROCESS, pastro fushat e përdoruesit dhe të rreshtit, rishkruaj me pututline(), pastaj endutent().

Përpilojeni dhe pastaj ekzekutojeni si root nga shell-i që do të nisë klientin:

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

Dy mënyra dështimi shpjegojnë shumicën e raportimeve se mjeti nuk bën asgjë. Ai vepron mbi TTY-në e lidhur me hyrjen standarde, prandaj ekzekutimi nga një skript ose detyrë cron pa terminal nuk lë asgjë për t'u përputhur. Dhe /run/utmp nuk është i shkruajtshëm nga përdoruesit e zakonshëm, prandaj një ekzekutim pa root dështon në heshtje nëse nuk kontrolloni statusin e daljes.

Verifikoni që tuneli i mbijeton mbylljes

Testoni mekanizmin në vend që ta supozoni. Lidhuni nga një sesion që synoni ta mbani, hapni një terminal të dytë, mbyllni të dytin, pastaj konfirmoni me vpn state dhe një sy nga lista e ndërfaqeve që tuneli është ende lart. Nëse tuneli mbijeton, shkaktari ishte një lloj i caktuar sesioni dhe jo çdo sesion, dhe keni gjetur sesionin që duhet të mbetet i hapur.

Nëse ende bie, sesioni i vëzhguar ishte diku tjetër, më shpesh hyrja grafike që krijoi terminalin tuaj, dhe heqja e një zëri TTY nuk ndihmon. Përsëritni vëzhgimin me listën e plotë nga hapi i parë, në vend që të shtoni më shumë kirurgji.

Kur rishkrimi i utmp është përgjigja e gabuar

utmp është kontabilitet i përbashkët, jo një tabelë private. Rishkrimi i zërit të një sesioni ende të gjallë bën që who, w dhe disa mjete auditimi ta raportojnë më pak, dhe një program që më vonë mbyll të njëjtin zë mund të dështojë plotësisht. Mbani mjetin të kufizuar në sesionin tuaj, ruani një kopje të skedarit origjinal dhe mos e bëni një shërbim nisjeje që heq çdo regjistrim.

Nëse organizata juaj mbledh kontabilitet sesionesh për përputhshmëri, zgjidhja bie ndesh me atë kërkesë dhe përgjigja e mbështetur është një version klienti ose një metodë tjetër aksesi, jo një utmp i patchuar. Për shumicën, rregullimi më pak ndërhyrës është thjesht të nisni klientin nga një sesion që mbetet i hapur gjithë ditën dhe ta lini atë dritare në paqe.

Përpara se të mbyllni tiketën, regjistroni cilin sesion po vëzhgonte klienti kur u ngrit tuneli. Ai rresht i vetëm e kthen një shkëputje misterioze në një kusht të riprodhueshëm për personin tjetër në makinë.