Mengedit resolv.conf tidak memperbaiki DNS setelah VPN terputus

Anda memutus VPN, ping 1.1.1.1 masih menjawab, dan setiap pencarian nama menggantung sebelum halaman akhirnya menyerah. Lalu cat /etc/resolv.conf menampilkan server nama yang pernah ada hanya di dalam terowongan, biasanya yang pertama dalam daftar. Menghapus baris itu tampak memperbaikinya selama sekitar sepuluh menit, sampai suspend, roaming Wi-Fi, atau mulai ulang mengembalikannya. Berkas yang Anda edit bukanlah pengaturannya; itu adalah penggambaran status tautan yang dimiliki komponen lain.

Mengapa satu entri usang memakan waktu beberapa detik per pencarian

Resolver glibc menelusuri daftar server nama secara berurutan dan menunggu batas waktu habis sebelum mencoba yang berikutnya, dan resolv.conf(5) membatasi daftar itu menjadi tiga entri. Letakkan resolver sisi terowongan seperti 10.8.0.1 di puncak setelah terowongan hilang, dan setiap pencarian membayar batas waktu sebelum jatuh ke server yang menjawab. Itulah sebabnya gejalanya tampak seperti koneksi mati dan bukan kesalahan DNS: peramban memblokir, kehabisan waktu, dan kadang menyajikan alamat cache yang kemudian menjadi usang.

Itu juga menjelaskan mengapa keluhannya datang sebagai «internet rusak». Ping ke alamat IP membuktikan tautannya baik, yang membuat kesalahan tampak ada di aplikasi. Daftar resolver adalah hal pertama yang harus dibaca dan hal terakhir yang harus diedit.

Mitos: resolv.conf adalah berkas pengaturan

Tanyakan apa sebenarnya jalur itu sebelum mengubahnya:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

Pada host systemd-resolved itu adalah symlink ke berkas stub yang menunjuk ke 127.0.0.53, dan server sungguhan hidup di status per tautan yang dicetak resolvectl. Pada host NetworkManager itu bisa berupa berkas yang ditulis NetworkManager dari koneksi aktif. Pada beberapa klien vendor itu berkas biasa yang ditulis ulang di tempat saat terhubung dan, jika Anda kurang beruntung, tidak pernah dipulihkan saat terputus. Itu tiga pemilik berbeda, dan mengedit dua yang pertama dengan tangan entah tidak melakukan apa-apa atau bertahan sampai peristiwa jaringan berikutnya.

resolvectl status adalah tampilan yang mengatakan kebenaran: server DNS per tautan, domain perutean, dan apakah tautan terowongan masih ada. resolvectl query example.com melangkah lebih jauh dan menunjukkan antarmuka mana yang menjawab. Gunakan keduanya sebelum menyentuh berkas, dan ingat bahwa peramban dengan DNS aman sendiri mengabaikan semua itu.

Temukan pemiliknya sebelum mengedit apa pun

Biasanya tiga komponen bersaing untuk pengaturan yang sama: systemd-resolved, NetworkManager, dan apa pun yang dipasang klien VPN. Identifikasi yang hidup dulu:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Jika resolved aktif dan symlink menunjuk ke stub-nya, berkas global adalah keluaran yang dihasilkan dan editan Anda bersifat kosmetik. Jika NetworkManager memiliki koneksinya, server menjadi milik profil koneksi, jadi perbaikannya adalah perubahan properti nmcli, bukan pengeditan berkas. Jika daemon vendor berjalan, hanya jalur pemulihannya sendiri yang bertahan sampai koneksi berikutnya.

Bersihkan status tautan yang ditinggalkan klien

Klien yang dimatikan tidak dapat menjalankan kait pembersihannya. SIGKILL sama sekali tidak dapat ditangkap, sedangkan SIGINT dan SIGTERM bisa, jadi terowongan yang «tiba-tiba berhenti» setelah pembunuhan paksa sering meninggalkan pendaftaran antarmuka dan entri resolver di tempatnya. Temukan PID yang tepat dan kirim sinyal hanya ke PID itu:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Jangan langsung meraih pkill -f vpn atau killall vpn sebelum membaca daftar kecocokan lengkap. -f mencocokkan seluruh baris perintah, jadi ia dapat mengakhiri skrip pembungkus, sesi editor, atau proses tak terkait yang jalurnya memuat string itu. Mengakhiri proses yang salah di tengah pekerjaan adalah cara masalah resolver menjadi berkas yang hilang.

resolvectl revert menyetel ulang konfigurasi DNS waktu proses tautan itu, yang lebih sempit daripada memulai ulang resolver dan jauh lebih sempit daripada mengedit berkas global. Jika tautan terowongan benar-benar hilang, systemctl restart NetworkManager membangun ulang status koneksi dan itulah langkah yang terus dituju utas sumber. Waspadai manajer layanan dengan Restart=always, karena ia dapat mengembalikan klien yang dimatikan, beserta pengaturan DNS-nya, langsung ke tempatnya.

Arah lain: DNS yang didorong namun tidak pernah tiba

Cermin dari entri usang adalah terowongan tanpa resolver yang dapat dipakai sama sekali. Opsi DNS di profil adalah permintaan; komponen yang mengelola koneksi harus menyerahkannya ke resolver. Jika log menunjukkan server diterima tetapi tautan terowongan tidak membawa pengaturan DNS, yang hilang adalah integrasinya, bukan servernya.

Uji penyerahannya dengan melakukannya secara manual, yang memisahkan «servernya salah» dari «tidak ada yang menerapkannya»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Domain perutean yang menangkap semua mengirim setiap nama ke tautan itu, yang diinginkan klien terowongan penuh dan yang tidak boleh dipakai DNS terpisah. Pengaturan ini hilang pada koneksi berikutnya. Untuk menjadikannya permanen di NetworkManager, nonaktifkan DNS otomatis, setel server pada koneksi, dan tambahkan domainnya:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Untuk terowongan perusahaan yang seharusnya hanya menjawab nama internal, daftarkan zona itu dengan tilde di awal alih-alih penangkap semua, agar nama publik tetap memakai resolver lokal.

Solusi sementara yang menjadi gangguan berikutnya

Menyalin resolv.conf sebelum terhubung dan memulihkannya sesudahnya adalah baris yang sah dalam runbook, dan itu solusi sementara, bukan perbaikan. Ia gagal tepat saat paling penting, karena crash atau mulai ulang paksa melewati pemulihan. Catat sebagai solusi sementara agar orang berikutnya tidak membangun di atasnya.

Menonaktifkan systemd-resolved dan mengodekan server publik secara keras adalah langkah populer lainnya. Ini membuat koneksi dan pemutusan menjadi dapat diprediksi dan menghapus DNS per tautan untuk setiap jaringan lain, yang merusak DNS terpisah untuk nama internal dan menggagalkan tujuan terowongan yang dimaksudkan untuk menahan kueri di dalamnya. Memasang resolvconf dan memakukan server publik memakan biaya yang sama dengan lapisan tambahan. Perlakukan salah satunya sebagai diagnosis: jika memulihkan penjelajahan, Anda telah belajar bahwa integrasi resolver yang bersalah, bukan bahwa server publik itu benar.

Perbaikan yang bertahan adalah satu pemilik per lapisan: tentukan komponen mana yang memiliki DNS tautan terowongan dan mana yang memiliki bawaan global, catat, dan hapus yang lain dari jalurnya. Lalu verifikasi setelah terputus dengan nama yang hanya diresolusi VPN. Jika nama privat masih menjawab, pendaftarannya belum dihapus; jika tidak ada yang diresolusi sama sekali, berkas menunjuk ke server yang tidak lagi ada. Keduanya terlihat di resolvectl sebelum Anda membuka peramban.