AnyConnect lecsatlakozik terminál bezárásakor: munkamenet-ellenőrzések

Az alagút él, bezár egy felesleges terminált, és a VPN egyetlen billentyűleütés nélkül elszáll a kliensben. A Linuxos AnyConnect kliensnél a jelentett ok a munkamenet-elszámolás, nem az útválasztás: a kliens rögzíti, mely bejelentkezési munkamenetek léteztek az alagút felépülésekor, és bármelyikük végét az alagút lebontásának okaként kezeli. Az alábbi ellenőrzések sorrendben futnak, és az első, amelyik elbukik, megmondja, hogy egyáltalán ezzel a viselkedéssel áll-e szemben. A kliens szokásos kimenetében semmi nem említ terminált, ezért az első ösztön, a koncentrátor hibáztatása, általában kárba veszett fáradság.

Ne a rendszerfájlok szerkesztésével kezdje. Minden lépés vagy megmagyarázza a kiesést, vagy kizár egy jelöltet, és az olcsó lépések jönnek előbb.

Válassza szét a munkamenet-kiesést az alatta lévő hálózat kiesésétől

Csatlakozzon újra azonnal a megszakítás után. Az az alagút, amely másodperceken belül visszatér, ugyanazon a hálózaton, új hitelesítő adatok nélkül, helyi kiváltóra utal, például egy bezárt munkamenetre, és nem egy halott feltöltő kapcsolatra, Wi-Fi-vándorlásra vagy a koncentrátor tétlenségi időtúllépésére. Az az alagút, amely a Connecting állapotban akad, vagy amely csak hálózatváltás után jön létre, másik cikk.

Írja fel, mi volt nyitva az alagút felépülésekor: a terminál, ahonnan a klienst indította, bármely második shell, a grafikus bejelentkezés és bármely SSH-munkamenet egy másik gépről. Percek múlva szüksége lesz erre a listára, és a következő kiesés után emlékezetből újraépíteni megbízhatatlan.

Ellenőrizze, mit rögzített a kliens a csatlakozáskor

A kliens nem vizsgálja a folyamatszülőket vagy a terminál tulajdonjogát. Pillanatképet készít a csatlakozáskor jelen lévő bejelentkezési munkamenetek halmazáról, és később összehasonlítja ezt a halmazt; ha egy tag eltűnik, az összehasonlítás elbukik, és az alagút is megy vele. Ezért lehet ártalmatlan annak az ablaknak a bezárása, amelyből csatlakozott, míg egy független felesleges terminál bezárása megöli a kapcsolatot: az számít, hogy az a munkamenet benne volt-e az eredeti halmazban. Az ellenőrzés halmaz-összehasonlítás, nem számlálás, ezért egy munkamenet lecserélése ugyanolyan végzetes lehet, mint elveszíteni egyet.

Sorolja fel, mit láthatott a kliens, mielőtt bármit megváltoztat:

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

A who minden sora felhasználói folyamatbejegyzés a utmp fájlban. Ha a munkamenete kétszer jelenik meg, egyszer a grafikus bejelentkezéshez és egyszer a terminálhoz, akkor mindkét bejegyzés létezett a csatlakozáskor, és mindkettő jelölt.

Csak a saját bejegyzését távolítsa el az utmp fájlból

A közzétett kerülőmegoldás láthatatlanná teszi a utmp fájlban azt a munkamenetet, amelyet használni készül, még a kliens indulása előtt. Egy kis C-program végigmegy a getutent() bejegyzésein, megkeresi azt a rekordot, amelynek ut_line mezője megegyezik a szabványos bemenet TTY-jével, majd átírja azt a rekordot. A sorrend szándékos: setutent(), olvassa be a bejegyzést, másolja ki a ut_id mezőjét, állítsa a ut_type mezőt DEAD_PROCESS értékre, törölje a felhasználó és a sor mezőit, írja vissza a pututline() függvénnyel, majd endutent().

Fordítsa le, majd futtassa rootként abból a shellből, amely elindítja a klienst:

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

Két hibamód magyarázza a legtöbb jelentést arról, hogy az eszköz nem tesz semmit. A szabványos bemenethez kapcsolt TTY-n hat, ezért a terminál nélküli szkriptből vagy cron-feladatból való futtatás nem hagy neki semmit, amihez illeszkedjen. És a /run/utmp normál felhasználók számára nem írható, ezért a root nélküli futtatás csendben elbukik, hacsak nem ellenőrzi a kilépési állapotot.

Erősítse meg, hogy az alagút túléli a bezárást

Tesztelje a mechanizmust, ahelyett hogy feltételezné. Csatlakozzon abból a munkamenetből, amelyet meg akar tartani, nyisson egy második terminált, zárja be a másodikat, majd erősítse meg a vpn state paranccsal és az interfészlista szemrevételezésével, hogy az alagút még él. Ha túléli, a kiváltó egy adott munkamenettípus volt, nem minden munkamenet, és megtalálta azt a munkamenetet, amelynek nyitva kell maradnia.

Ha mégis eldobja, a figyelt munkamenet máshol volt, leggyakrabban a grafikus bejelentkezés, amely a terminálját létrehozta, és egyetlen TTY-bejegyzés eltávolítása nem fog segíteni. Ismételje meg a megfigyelést az első lépés teljes listájával, ahelyett hogy további sebészetet adna hozzá.

Amikor az utmp átírása a rossz válasz

A utmp megosztott elszámolás, nem magán tábla. Egy még élő munkamenet bejegyzésének átírása azt eredményezi, hogy a who, a w és egyes auditáló eszközök aluljelentik, és egy program, amely később ugyanezt a bejegyzést zárja, teljesen elbukhat. Tartsa az eszközt a saját munkamenetére korlátozva, őrizzen másolatot az eredeti fájlról, és ne alakítsa olyan indítási szolgáltatássá, amely minden rekordot eltávolít.

Ha a szervezete megfelelőség céljából munkamenet-elszámolást gyűjt, a kerülőmegoldás ellentétes ezzel a követelménnyel, és a támogatott válasz egy másik kliensverzió vagy más hozzáférési mód, nem egy foltozott utmp. A legtöbb embernek a legkevésbé beavatkozó javítás az, hogy egyszerűen egy egész nap nyitva maradó munkamenetből indítja a klienst, és békén hagyja azt az ablakot.

Mielőtt lezárja a jegyet, jegyezze fel, melyik munkamenetet figyelte a kliens az alagút felépülésekor. Ez az egyetlen sor az, ami a rejtélyes megszakítást reprodukálható feltétellé teszi a gépen következő ember számára.