DNS OpenVPN tertinggal setelah SIGKILL: periksa pemiliknya dulu

DNS berhenti meresolusi setelah klien OpenVPN dibunuh, dan naluri pertama adalah menulis ulang /etc/resolv.conf. Perubahan itu dapat merusak resolver yang berfungsi sementara keadaan usang yang sebenarnya ada di tempat lain. Pertanyaan yang harus diselesaikan lebih dulu adalah siapa pemilik pengaturan DNS yang dipasang terowongan, dan apakah keluaran yang melewati pembersihan benar-benar penting.

Tiga kondisi menentukan perbaikan: sinyal yang mengakhiri proses, komponen resolver yang menerima pengaturan, dan apakah tautan terowongan masih ada. Jawablah dalam urutan itu dan perbaikannya biasanya menyusul tanpa menyentuh berkas global.

Tentukan jenis keluaran yang terjadi

Dalam edisi Community OpenVPN, SIGINT dan SIGTERM keduanya permintaan keluar yang rapi. SIGKILL tidak dapat ditangkap: tidak dapat diblokir atau ditangani, jadi tidak ada rutin penghentian yang mendapat kesempatan berjalan. Ctrl+C biasa di terminal latar depan menghasilkan SIGINT, sedangkan pengawas yang menyerah menunggu biasanya meningkat ke SIGKILL. Perbedaannya penting karena hanya kasus kedua yang menjamin hook dilewati.

Menjalankannya di dalam screen atau tmux tidak mengubah sinyal apa yang dikirim Ctrl+C. Periksa apa yang benar-benar diterima proses, bukan apa yang biasanya dilakukan terminal.

Ketika layanan atau manajer koneksi menjalankan terowongan, hentikan satu koneksi itu melalui pemiliknya alih-alih membunuh pid. Manajer dapat menaikkan proses lagi, meninggalkan Anda dengan terowongan baru dan keadaan resolver yang membingungkan. Proses mandiri hanya perlu permintaan penghentian biasa agar pembersihan berjalan.

Tentukan siapa pemilik resolver

systemd-resolved, skrip bergaya resolvconf, dan penulisan ulang berkas biasa adalah tiga pemilik berbeda. Yang pertama menyimpan pengaturan per-tautan di memori dan membuangnya saat antarmuka hilang. Yang kedua menyimpan catatan yang bertahan sampai sesuatu menghapusnya. Yang ketiga menulis berkas dan menyerahkan pemulihan kepada siapa pun yang menulisnya.

Identifikasi pemilik sebelum memilih perintah perbaikan. Gejala yang sama memiliki tiga jawaban benar yang berbeda tergantung mana yang digunakan.

VPN yang dikelola NetworkManager mungkin sudah memiliki perubahan resolver. Menambahkan pembantu kedua di atasnya menciptakan dua pemilik yang bersaing atas tautan yang sama, dan keadaan pihak yang kalah muncul lagi pada penyambungan ulang berikutnya. Jika manajer yang bertanggung jawab, perbaiki pengaturan di manajer bukan di skrip.

Apa yang bisa dan tidak bisa dilakukan hook down

Skrip down berjalan sekali setelah perangkat TUN/TAP ditutup. Menambahkan down-pre membalik urutan itu dan menjalankan skrip selagi perangkat masih ada, yang dibutuhkan pembantu yang memerlukan tautan hidup.

Tidak ada arahan yang membuat hook berjalan setelah SIGKILL. Hak istimewa juga tidak dipulihkan oleh down-pre: jika daemon turun ke user atau group atau masuk ke chroot, hook berjalan dengan akses yang ditinggalkannya. Hook yang dipanggil tetap dapat gagal memperbarui resolver. Referensi OpenVPN mencakup sinyal dan siklus hidup panggilan balik.

Periksa kesalahan hook itu sendiri di samping status keluar proses. Pembersihan yang hilang dan pembersihan yang gagal terlihat sama di resolver dan berbeda di log.

Periksa keadaan yang benar-benar tersisa

Pada sistem yang memakai systemd-resolved, resolvectl status menunjukkan tautan mana yang masih membawa server DNS VPN atau domain perutean. Tautan itu bisa milik koneksi yang sudah pergi, atau milik terowongan lain yang masih hidup.

Antarmuka yang hilang membawa serta konfigurasi per-tautannya, sehingga hook yang dilewati dapat hidup berdampingan dengan DNS yang bersih. Jika tautan masih terdaftar dan hanya dimiliki oleh koneksi yang dihentikan, manajer pemiliknya harus menghapusnya. Jika skrip lama menulis ulang berkas resolver global, cari langkah pemulihan terdokumentasi skrip itu.

Pulihkan tanpa mencuri tautan lain

Ketika pengaturan per-tautan menjadi tanggung jawab Anda, resolvectl revert mengambil nama tautan dan membersihkan konfigurasi DNS waktu proses untuk antarmuka itu. Ini tindakan waktu proses, bukan penyuntingan profil, jadi konfigurasi koneksi yang persisten tetap tidak tersentuh. Sebut tautan yang salah dan Anda membersihkan DNS terowongan yang berfungsi, itulah sebabnya nama diambil dari keluaran status.

Pastikan bahwa /etc/resolv.conf adalah tautan simbolik terkelola sebelum menyuntingnya, lalu hentikan klien secara normal sekali lagi dan lihat DNS kembali. Jika penghentian kedua membersihkan, masalah sebelumnya adalah keluaran paksa, bukan konfigurasi.