DNS OpenVPN tertinggal selepas SIGKILL: periksa pemilik dahulu

DNS berhenti menyelesaikan selepas klien OpenVPN dibunuh, dan naluri pertama ialah menulis semula /etc/resolv.conf. Perubahan itu boleh merosakkan penyelesai yang berfungsi sementara keadaan lapuk sebenar berada di tempat lain. Soalan yang perlu diselesaikan dahulu ialah siapa memiliki tetapan DNS yang dipasang oleh terowong, dan sama ada keluaran yang melangkau pembersihan benar-benar penting.

Tiga keadaan menentukan pembaikan: isyarat yang menamatkan proses, komponen penyelesai yang menerima tetapan, dan sama ada pautan terowong masih wujud. Jawab dalam urutan itu dan pembaikan biasanya menyusul tanpa menyentuh fail global.

Tentukan jenis keluaran yang berlaku

Dalam edisi Community OpenVPN, kedua-dua SIGINT dan SIGTERM ialah permintaan keluar yang tenang. SIGKILL tidak boleh ditangkap: ia tidak boleh disekat atau dikendalikan, jadi tiada rutin penutupan mendapat peluang berjalan. Ctrl+C biasa dalam terminal latar hadapan menghasilkan SIGINT, manakala penyelia yang berhenti menunggu biasanya meningkat kepada SIGKILL. Perbezaan itu penting kerana hanya kes kedua menjamin cangkuk dilangkau.

Menjalankannya dalam screen atau tmux tidak mengubah isyarat yang dihantar oleh Ctrl+C. Periksa apa yang sebenarnya diterima oleh proses, bukan apa yang biasa dilakukan oleh terminal.

Apabila perkhidmatan atau pengurus sambungan menjalankan terowong, hentikan sambungan itu melalui pemiliknya dan bukannya membunuh pid. Pengurus boleh menaikkan proses semula, meninggalkan anda dengan terowong baharu dan keadaan penyelesai yang mengelirukan. Proses berdiri sendiri hanya memerlukan permintaan penamatan biasa untuk pembersihan berjalan.

Tentukan siapa memiliki penyelesai

systemd-resolved, skrip bergaya resolvconf dan penulisan semula fail biasa ialah tiga pemilik berbeza. Yang pertama menyimpan tetapan setiap pautan dalam ingatan dan menggugurkannya apabila antara muka hilang. Yang kedua menyimpan rekod yang kekal sehingga sesuatu mengalihkannya. Yang ketiga menulis fail dan menyerahkan pemulihan kepada sesiapa yang menulisnya.

Kenal pasti pemilik sebelum memilih arahan pembaikan. Gejala yang sama mempunyai tiga jawapan betul yang berbeza bergantung pada yang mana sedang digunakan.

VPN yang diurus oleh NetworkManager mungkin sudah memiliki perubahan penyelesai. Menambah pembantu kedua di atasnya mencipta dua pemilik yang bersaing untuk pautan yang sama, dan keadaan pihak yang kalah muncul semula pada penyambungan semula seterusnya. Jika pengurus bertanggungjawab, betulkan tetapan dalam pengurus dan bukan dalam skrip.

Apa yang boleh dan tidak boleh dilakukan oleh cangkuk down

Skrip down berjalan sekali selepas peranti TUN/TAP ditutup. Menambah down-pre membalikkan urutan itu dan menjalankan skrip semasa peranti masih wujud, yang diperlukan oleh pembantu yang memerlukan pautan hidup.

Tiada arahan menjadikan cangkuk berjalan selepas SIGKILL. Keistimewaan juga tidak dipulihkan oleh down-pre: jika daemon turun ke user atau group atau masuk ke chroot, cangkuk berjalan dengan akses yang ditinggalkannya. Cangkuk yang dipanggil masih boleh gagal mengemas kini penyelesai. Rujukan OpenVPN merangkumi isyarat dan kitaran hayat panggilan balik.

Periksa ralat cangkuk itu sendiri di sebelah status keluar proses. Pembersihan yang hilang dan pembersihan yang gagal kelihatan sama dalam penyelesai dan berbeza dalam log.

Periksa keadaan yang benar-benar tinggal

Pada sistem yang menggunakan systemd-resolved, resolvectl status menunjukkan pautan mana yang masih membawa pelayan DNS VPN atau domain penghalaan. Pautan itu mungkin milik sambungan yang telah pergi, atau terowong lain yang masih hidup.

Antara muka yang hilang membawa bersama konfigurasi setiap pautannya, jadi cangkuk yang dilangkau boleh wujud bersama DNS yang bersih. Jika pautan masih didaftarkan dan dimiliki secara eksklusif oleh sambungan yang dihentikan, pengurus pemiliknya harus mengalihkannya. Jika skrip lama menulis semula fail penyelesai global, cari langkah pemulihan berdokumen skrip itu.

Pulihkan tanpa mencuri pautan lain

Apabila tetapan setiap pautan menjadi tanggungjawab anda, resolvectl revert mengambil nama pautan dan mengosongkan konfigurasi DNS masa jalan untuk antara muka itu. Ia tindakan masa jalan dan bukan penyuntingan profil, jadi konfigurasi sambungan berterusan kekal tidak tersentuh. Namakan pautan yang salah dan anda mengosongkan DNS terowong yang berfungsi, itulah sebabnya nama diambil daripada keluaran status.

Sahkan bahawa /etc/resolv.conf ialah pautan simbolik terurus sebelum menyuntingnya, kemudian hentikan klien seperti biasa sekali lagi dan lihat DNS semula. Jika penghentian kedua membersihkan, masalah sebelumnya ialah keluaran paksa dan bukan konfigurasi.