openconnect terbunuh: laluan dan DNS masih menunjuk ke terowong

Terowong sudah mati, tetapi mesin masih berkelakuan seolah-olah ia hidup: carian tergantung sehingga tamat masa, dan laluan menunjuk ke antara muka yang tidak lagi wujud. Itulah tanda proses openconnect yang mati tanpa menjalankan pembantu putusnya. Keadaan rangkaian yang diciptanya masih dipasang, dan tiada apa-apa lagi dalam sistem yang tahu cara membuangnya.

Ikut mesin mengikut urutan keadaan itu dicipta: proses, pautan, laluan, resolver. Setiap langkah memberitahu sama ada klien benar-benar pergi atau hanya terlepas dari terminal anda, dan perbezaan itulah yang menentukan sama ada anda perlu membaiki apa-apa.

Mulakan dengan proses, bukan konfigurasi

Buka terminal dan tanya apa yang masih berjalan sebelum menyentuh laluan. pgrep -a openconnect menyenaraikan setiap instans dengan argumennya, yang menunjukkan fail pid dan skrip yang diberikannya. Proses yang tidak anda jangkakan menerangkan terowong hantu lebih cepat daripada mana-mana log.

Jika tiada apa yang berjalan, lihat pautan itu. ip link show tun0 memberitahu sama ada antara muka itu terselamat, dan ip route show dev tun0 menyenaraikan laluan yang masih terikat padanya. Kemudian periksa resolver dengan resolvectl status. Catat ketiga-tiga keluaran sebelum mengubahnya, kerana catatan itulah cara anda nanti membezakan entri lapuk daripada entri baharu.

Antara muka yang hilang biasanya membawa laluannya bersama. Laluan yang bertahan selepas pautan biasanya bermakna proses itu masih hidup atau klien kedua memiliki peranti itu.

Skrip pembantu itulah yang membatalkan perubahan

openconnect tidak membuang antara muka, laluan atau entri resolver itu sendiri. Ia memanggil pembantu luaran, /etc/vpnc/vpnc-script dalam build upstream dan /usr/share/vpnc-scripts/vpnc-script dalam pakej Debian dan Ubuntu, dipilih dengan -s. Skrip yang sama yang menaikkan terowong juga yang merobohkannya.

Jika proses keluar tanpa memanggil pembantu itu, keadaan itu kekal. manual OpenConnect menyatakan secara jelas bahawa penghalaan dan perkhidmatan nama tidak akan berfungsi dengan betul tanpa skrip itu, dan ia menerangkan pembantu sebagai komponen yang merobohkan keadaan antara muka semasa keluar. Itulah sebabnya laluan itu penting apabila anda melancarkan klien dengan -s.

Isyarat mana yang sampai ke laluan itu berubah antara versi. Manual 7.06 menganggap SIGTERM sebagai keluar segera yang melangkau skrip. Build semasa mendokumenkan INT dan TERM sebagai hentian bersih, di mana sesi dilog keluar dan pembantu dijalankan. Baca bahagian SIGNALS binari yang benar-benar anda miliki dan bukan menganggap mana-mana satu tingkah laku.

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

Hantar isyarat yang didokumenkan build anda

Setelah tahu isyarat itu, hentikan proses mengikut pid dan bukan mengikut corak.

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

Kemudian ulangi tiga pemeriksaan dari bahagian pertama dan bukan mempercayai status keluar. ip link show tun0 sepatutnya gagal, ip route show dev tun0 sepatutnya tidak mencetak apa-apa, dan resolvectl status sepatutnya tidak lagi menyenaraikan pautan VPN.

SIGHUP bukan butang henti: ia memutuskan sambungan, menjalankan skrip dan membiarkan sesi boleh disambung semula dengan --cookie. SIGUSR2 memaksa sambungan semula segera. SIGKILL melangkau pembersihan sepenuhnya, dan itulah keadaan yang dibincangkan artikel ini.

Baiki resolver tanpa menggantikan resolv.conf

Pada kebanyakan sistem Ubuntu /etc/resolv.conf ialah pautan simbolik ke systemd-resolved, bukan fail yang patut anda edit. Menggantikannya memecahkan penyelesaian nama untuk setiap rangkaian, bukan hanya VPN. Sebaliknya, buang pendaftaran terowong itu:

resolvectl revert tun0
resolvectl query example.com

Jika sistem menggunakan resolvconf dan bukan systemd-resolved, rekod setiap antara muka kekal sehingga ia diberitahu melepaskan pautan, dan resolvconf -d tun0 ialah tindakan yang setara. Periksa resolver mana yang digunakan sebelum memilih arahan itu.

Carian yang masih menuju pelayan di sebalik pautan mati tergantung sehingga tamat masa, dan kelewatan itu kelihatan seperti pelayan DNS rosak dan bukan laluan sisa.

Jadikan putusan seterusnya membosankan

Kekalkan laluan fail pid sama semasa mula dan tutup dengan memberikan --pid-file setiap kali, atau jalankan openconnect di bawah unit yang KillSignal sepadan dengan isyarat yang didokumenkan versi anda. Menguji dahulu di latar hadapan menunjukkan mesej penutupan yang dicetak pembantu.

Sambung, putuskan sambungan dan jalankan tiga pemeriksaan sekali. Keluar bersih tidak meninggalkan pautan VPN, laluan VPN atau entri resolver VPN. Jika satu daripada tiga bertahan, anda kini tahu komponen mana yang gagal membersihkan. Siasatan seterusnya kemudian bermula daripada jawapan itu dan bukan daripada carian yang tergantung.