AnyConnect Terputus Saat Terminal Ditutup: Pemeriksaan Sesi

Tunnel sudah aktif, Anda menutup satu terminal cadangan, dan VPN langsung turun tanpa satu pun tekanan tombol di klien. Pada klien AnyConnect di Linux, penyebab yang dilaporkan adalah pembukuan sesi, bukan perutean: klien mencatat sesi login mana yang ada saat tunnel naik dan menganggap berakhirnya salah satu dari sesi itu sebagai alasan untuk meruntuhkannya. Pemeriksaan di bawah dijalankan berurutan, dan yang pertama gagal memberi tahu Anda apakah Anda memang menghadapi perilaku ini. Tidak ada apa pun dalam keluaran biasa klien yang menyebut terminal, itulah sebabnya dorongan pertama, menyalahkan concentrator, biasanya usaha yang sia-sia.

Jangan mulai dengan menyunting berkas sistem. Setiap langkah entah menjelaskan pemutusan atau menyingkirkan satu kandidat, dan langkah murah datang lebih dulu.

Pisahkan pemutusan sesi dari pemutusan jaringan dasar

Sambungkan ulang segera setelah terputus. Tunnel yang kembali dalam hitungan detik, di jaringan yang sama, tanpa kredensial baru, menunjukkan pemicu lokal seperti sesi yang ditutup, bukan uplink yang mati, roaming Wi-Fi, atau batas waktu menganggur di concentrator. Tunnel yang menggantung pada Connecting, atau yang gagal sampai Anda berganti jaringan, adalah artikel lain.

Catat apa yang terbuka saat tunnel naik: terminal tempat Anda menjalankan klien, shell kedua mana pun, login grafis, dan sesi SSH mana pun dari mesin lain. Anda akan memerlukan daftar itu sebentar lagi, dan merekonstruksinya dari ingatan setelah pemutusan berikutnya tidak dapat diandalkan.

Periksa apa yang dicatat klien saat terhubung

Klien tidak memeriksa induk proses atau kepemilikan terminal. Ia mengambil cuplikan himpunan sesi login yang ada saat terhubung lalu membandingkan himpunan itu nanti; ketika satu anggota hilang, perbandingannya gagal dan tunnel ikut hilang. Itulah sebabnya menutup jendela tempat Anda terhubung bisa tidak berbahaya sementara menutup terminal cadangan yang tidak berkaitan mematikan koneksi: yang penting adalah apakah sesi itu ada dalam himpunan awal. Pemeriksaannya adalah perbandingan himpunan, bukan penghitungan, sehingga mengganti satu sesi bisa sama fatalnya dengan kehilangan satu sesi.

Sebutkan apa yang bisa dilihat klien sebelum Anda mengubah apa pun:

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

Setiap baris dari who adalah entri proses pengguna di utmp. Jika sesi Anda muncul dua kali, sekali untuk login grafis dan sekali untuk terminal, kedua entri itu ada saat terhubung dan keduanya kandidat.

Hapus hanya entri Anda sendiri dari utmp

Solusi yang dipublikasikan membuat sesi yang akan Anda pakai tidak terlihat di utmp sebelum klien mulai. Sebuah program C kecil menelusuri getutent(), mencocokkan rekaman yang ut_line-nya sama dengan TTY masukan standar, lalu menulis ulang rekaman itu. Urutannya disengaja: setutent(), baca entri, salin ut_id-nya, setel ut_type ke DEAD_PROCESS, kosongkan bidang pengguna dan baris, tulis kembali dengan pututline(), lalu endutent().

Kompilasi, lalu jalankan sebagai root dari shell yang akan memulai klien:

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

Dua mode kegagalan menjelaskan sebagian besar laporan bahwa alat itu tidak melakukan apa pun. Alat ini bekerja pada TTY yang terpasang pada masukan standar, jadi menjalankannya dari skrip atau tugas cron tanpa terminal tidak menyisakan apa pun untuk dicocokkan. Dan /run/utmp tidak dapat ditulisi oleh pengguna biasa, jadi menjalankan tanpa root gagal secara diam-diam kecuali Anda memeriksa status keluarnya.

Pastikan tunnel bertahan setelah terminal ditutup

Uji mekanismenya alih-alih menganggapnya. Hubungkan dari sesi yang ingin Anda pertahankan, buka terminal kedua, tutup terminal kedua, lalu pastikan tunnel masih aktif dengan vpn state dan sekilas pada daftar antarmuka. Jika tunnel bertahan, pemicunya adalah jenis sesi tertentu, bukan setiap sesi, dan Anda telah menemukan sesi yang harus tetap terbuka.

Jika masih terputus, sesi yang dipantau ada di tempat lain, paling sering login grafis yang melahirkan terminal Anda, dan mencabut satu entri TTY tidak akan membantu. Ulangi pengamatan dengan daftar lengkap dari langkah pertama alih-alih menambah operasi.

Saat menulis ulang utmp adalah jawaban yang salah

utmp adalah pembukuan bersama, bukan tabel pribadi. Menulis ulang entri sesi yang masih hidup membuat who, w, dan sebagian perkakas audit melaporkannya kurang dari yang sebenarnya, dan program yang nanti menutup entri yang sama bisa gagal total. Batasi alat itu pada sesi Anda sendiri, simpan salinan berkas asli, dan jangan menjadikannya layanan boot yang mencabut setiap rekaman.

Jika situs Anda mengumpulkan pembukuan sesi untuk kepatuhan, solusi ini bertentangan dengan persyaratan itu dan jawaban yang didukung adalah versi klien lain atau metode akses yang berbeda, bukan utmp yang ditambal. Bagi kebanyakan orang, perbaikan yang paling tidak mengganggu adalah sekadar memulai klien dari sesi yang akan tetap terbuka sepanjang hari dan membiarkan jendela itu.

Sebelum menutup tiket, catat sesi mana yang dipantau klien saat tunnel naik. Satu baris itulah yang mengubah pemutusan yang misterius menjadi kondisi yang dapat direproduksi bagi orang berikutnya di mesin itu.