AnyConnect Terputus Apabila Terminal Ditutup: Semakan Sesi

Terowong berjalan, anda menutup terminal tambahan, dan VPN jatuh tanpa satu pun kekunci ditekan dalam klien. Pada klien AnyConnect Linux punca yang dilaporkan ialah perakaunan sesi, bukan penghalaan: klien merekod sesi log masuk mana yang wujud semasa terowong naik dan menganggap tamatnya mana-mana satu daripadanya sebagai sebab untuk menurunkannya. Semakan di bawah dijalankan mengikut urutan, dan yang pertama gagal memberitahu sama ada anda sedang melihat tingkah laku ini. Tiada apa dalam output biasa klien menyebut terminal, sebab itu naluri pertama, menyalahkan konsentrator, biasanya usaha yang sia-sia.

Jangan mula dengan menyunting fail sistem. Setiap langkah sama ada menerangkan kejatuhan itu atau membuang satu calon, dan langkah murah datang dahulu.

Asingkan kejatuhan sesi daripada kejatuhan lapisan bawah

Sambung semula sejurus selepas terputus. Terowong yang kembali dalam beberapa saat, pada rangkaian yang sama, tanpa kelayakan baharu, menunjuk kepada pencetus setempat seperti sesi tertutup dan bukan pautan atas mati, perayauan Wi-Fi atau tamat masa melahu pada konsentrator. Terowong yang tergantung pada Connecting, atau yang gagal sehingga anda menukar rangkaian, ialah artikel lain.

Catat apa yang terbuka semasa terowong naik: terminal tempat anda menjalankan klien, mana-mana shell kedua, log masuk grafik, dan mana-mana sesi SSH daripada mesin lain. Anda memerlukan senarai itu sebentar lagi, dan membinanya semula daripada ingatan selepas kejatuhan seterusnya tidak boleh dipercayai.

Semak apa yang klien rekod semasa menyambung

Klien tidak memeriksa induk proses atau pemilikan terminal. Ia mengambil syot kilat set sesi log masuk yang ada semasa menyambung dan membandingkan set itu kemudian; apabila seorang ahli hilang, perbandingan gagal dan terowong turut jatuh. Itulah sebabnya menutup tetingkap tempat anda menyambung boleh tidak berbahaya manakala menutup terminal tambahan yang tidak berkaitan membunuh sambungan: yang penting ialah sama ada sesi itu berada dalam set asal. Ia perbandingan set, bukan kiraan, sebab itu menggantikan sesi boleh sama mautnya dengan kehilangan satu.

Senaraikan apa yang klien dapat lihat sebelum anda mengubah apa-apa:

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

Setiap baris daripada who ialah entri proses pengguna dalam utmp. Jika sesi anda muncul dua kali, sekali untuk log masuk grafik dan sekali untuk terminal, kedua-dua entri wujud semasa menyambung dan kedua-duanya calon.

Buang hanya entri anda sendiri daripada utmp

Penyelesaian yang diterbitkan menjadikan sesi yang akan anda gunakan tidak kelihatan dalam utmp sebelum klien bermula. Satu program C kecil menelusuri getutent(), memadankan rekod yang ut_line sama dengan TTY input standard, kemudian menulis semula rekod itu. Urutannya disengajakan: setutent(), baca entri, salin ut_id, tetapkan ut_type kepada DEAD_PROCESS, kosongkan medan pengguna dan baris, tulis semula dengan pututline(), kemudian endutent().

Kompilnya, kemudian jalankannya sebagai root daripada shell yang akan memulakan klien:

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

Dua mod kegagalan menjelaskan kebanyakan laporan bahawa alat itu tidak berbuat apa-apa. Ia bertindak pada TTY yang terpasang pada input standard, jadi menjalankannya daripada skrip atau kerja cron tanpa terminal tidak meninggalkan apa-apa untuk dipadankan. Dan /run/utmp tidak boleh ditulis oleh pengguna biasa, jadi larian bukan root gagal secara senyap melainkan anda memeriksa status keluar.

Sahkan terowong bertahan selepas ditutup

Uji mekanisme itu daripada menganggapnya. Sambung daripada sesi yang anda mahu kekalkan, buka terminal kedua, tutup yang kedua, kemudian sahkan terowong masih naik dengan vpn state dan pandangan pada senarai antara muka. Jika terowong bertahan, pencetusnya ialah jenis sesi tertentu dan bukan setiap sesi, dan anda telah menemui sesi yang mesti kekal terbuka.

Jika ia masih jatuh, sesi yang dipantau berada di tempat lain, selalunya log masuk grafik yang melahirkan terminal anda, dan membuang satu entri TTY tidak akan membantu. Ulangi pemerhatian dengan senarai penuh daripada langkah pertama daripada menambah lebih banyak pembedahan.

Apabila penulisan semula utmp ialah jawapan yang salah

utmp ialah perakaunan dikongsi, bukan jadual peribadi. Menulis semula entri sesi yang masih hidup menyebabkan who, w dan sesetengah alat audit melaporkannya kurang, dan program yang kemudian menutup entri yang sama boleh gagal sepenuhnya. Hadkan alat itu kepada sesi anda sendiri, simpan salinan fail asal, dan jangan jadikannya perkhidmatan boot yang membuang setiap rekod.

Jika tapak anda mengumpul perakaunan sesi untuk pematuhan, penyelesaian ini bercanggah dengan keperluan itu dan jawapan yang disokong ialah versi klien atau kaedah akses lain, bukan utmp yang ditampal. Bagi kebanyakan orang pembaikan paling kurang invasif ialah memulakan klien daripada sesi yang akan kekal terbuka sepanjang hari dan membiarkan tetingkap itu.

Sebelum menutup tiket, rekod sesi mana yang klien pantau semasa terowong naik. Satu baris itu yang menukar pemutusan misteri menjadi keadaan boleh diulang bagi orang seterusnya pada mesin itu.