openconnect yang terbunuh: rute dan DNS masih menunjuk ke terowongan

Terowongannya mati, tetapi mesin masih berperilaku seolah-olah hidup: pencarian menggantung sampai waktu habis, dan sebuah rute menunjuk ke antarmuka yang sudah tidak ada. Itu adalah ciri proses openconnect yang mati tanpa menjalankan pembantu pemutusannya. Keadaan jaringan yang dibuatnya masih terpasang, dan tidak ada hal lain di sistem yang tahu cara menghapusnya.

Telusuri mesin sesuai urutan keadaan itu dibuat: proses, tautan, rute, resolver. Setiap langkah memberi tahu apakah klien benar-benar pergi atau hanya terlepas dari terminal Anda, dan perbedaan itulah yang menentukan apakah Anda perlu memperbaiki apa pun.

Mulailah dari proses, bukan dari konfigurasi

Buka terminal dan tanyakan apa yang masih berjalan sebelum menyentuh rute. pgrep -a openconnect mendaftar setiap instans beserta argumennya, yang menunjukkan berkas pid dan skrip yang diberikan kepadanya. Proses yang tidak Anda duga menjelaskan terowongan hantu lebih cepat daripada log mana pun.

Jika tidak ada yang berjalan, lihat tautannya. ip link show tun0 memberi tahu apakah antarmuka bertahan, dan ip route show dev tun0 mendaftar rute yang masih terikat padanya. Lalu periksa resolver dengan resolvectl status. Catat ketiga keluarannya sebelum mengubahnya, karena catatan itulah cara Anda nanti membedakan entri lama dari entri baru.

Antarmuka yang hilang biasanya membawa rutenya serta. Rute yang bertahan setelah tautan biasanya berarti prosesnya masih hidup atau klien kedua memiliki perangkat itu.

Skrip pembantu itulah yang membatalkan perubahan

openconnect tidak menghapus antarmuka, rute, atau entri resolver itu sendiri. Ia memanggil pembantu eksternal, /etc/vpnc/vpnc-script dalam build upstream dan /usr/share/vpnc-scripts/vpnc-script dalam paket Debian dan Ubuntu, dipilih dengan -s. Skrip yang sama yang memasang terowongan juga yang membongkarnya.

Jika proses keluar tanpa memanggil pembantu itu, keadaannya tetap. manual OpenConnect menyatakan secara eksplisit bahwa perutean dan layanan nama tidak akan bekerja dengan benar tanpa skrip itu, dan menggambarkan pembantu sebagai komponen yang membongkar keadaan antarmuka saat keluar. Itulah sebabnya jalur itu penting ketika Anda meluncurkan klien dengan -s.

Sinyal mana yang mencapai jalur itu berubah antar versi. Manual 7.06 memperlakukan SIGTERM sebagai keluar segera yang melewati skrip. Build saat ini mendokumentasikan INT dan TERM sebagai penghentian bersih, di mana sesi dikeluarkan dan pembantu berjalan. Bacalah bagian SIGNALS dari biner yang benar-benar Anda miliki alih-alih menganggap salah satu perilakunya.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Kirim sinyal yang didokumentasikan build Anda

Setelah tahu sinyalnya, hentikan proses berdasarkan pid, bukan berdasarkan pola.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Lalu ulangi ketiga pemeriksaan dari bagian pertama alih-alih memercayai status keluar. ip link show tun0 seharusnya gagal, ip route show dev tun0 seharusnya tidak mencetak apa pun, dan resolvectl status seharusnya tidak lagi mendaftar tautan VPN.

SIGHUP bukan tombol berhenti: ia memutus, menjalankan skrip, dan meninggalkan sesi dapat dilanjutkan dengan --cookie. SIGUSR2 memaksa penyambungan ulang segera. SIGKILL melewati pembersihan sepenuhnya, dan itulah tepatnya keadaan yang dibahas artikel ini.

Perbaiki resolver tanpa mengganti resolv.conf

Pada sebagian besar sistem Ubuntu /etc/resolv.conf adalah tautan simbolik ke systemd-resolved, bukan berkas yang seharusnya Anda sunting. Menggantinya merusak resolusi nama untuk semua jaringan, bukan hanya VPN. Sebagai gantinya, hapus pendaftaran terowongan:

resolvectl revert tun0
resolvectl query example.com

Jika sistem memakai resolvconf alih-alih systemd-resolved, catatan per antarmuka tetap ada sampai diperintahkan melepaskan tautan, dan resolvconf -d tun0 adalah tindakan yang setara. Periksa resolver mana yang dipakai sebelum memilih perintah.

Pencarian yang masih mengarah ke server di balik tautan mati menggantung sampai waktu habis, dan keterlambatan itu tampak seperti server DNS rusak alih-alih rute sisa.

Buat pemutusan berikutnya membosankan

Jaga jalur berkas pid tetap sama saat mulai dan mati dengan memberikan --pid-file setiap kali, atau jalankan openconnect di bawah unit yang KillSignal cocok dengan sinyal yang didokumentasikan versi Anda. Menguji lebih dulu di latar depan menunjukkan pesan penghentian yang dicetak pembantu.

Sambungkan, putuskan, dan jalankan ketiga pemeriksaan sekali. Keluar bersih tidak meninggalkan tautan VPN, rute VPN, atau entri resolver VPN. Jika salah satu dari tiga bertahan, Anda kini tahu komponen mana yang gagal membersihkan. Investigasi berikutnya lalu dimulai dari jawaban itu alih-alih dari pencarian yang menggantung.