Mengedit resolv.conf tidak membaiki DNS selepas VPN terputus

Anda memutuskan VPN, ping 1.1.1.1 masih menjawab, dan setiap carian nama tergantung sebelum halaman akhirnya mengalah. Kemudian cat /etc/resolv.conf menunjukkan pelayan nama yang hanya pernah wujud di dalam terowong, biasanya yang pertama dalam senarai. Memadam baris itu kelihatan membaikinya selama kira-kira sepuluh minit, sehingga penggantungan, perayauan Wi-Fi atau permulaan semula meletakkannya kembali. Fail yang anda edit bukan tetapannya; ia ialah paparan keadaan pautan yang dimiliki komponen lain.

Mengapa satu entri lapuk memakan beberapa saat bagi setiap carian

Penyelesai glibc menelusuri senarai pelayan nama mengikut urutan dan menunggu tamat masa berlalu sebelum mencuba yang seterusnya, dan resolv.conf(5) mengehadkan senarai itu kepada tiga entri. Letakkan penyelesai sebelah terowong seperti 10.8.0.1 di bahagian atas selepas terowong hilang, dan setiap carian membayar tamat masa sebelum jatuh ke pelayan yang menjawab. Itulah sebabnya simptom kelihatan seperti sambungan mati dan bukan ralat DNS: pelayar menyekat, kehabisan masa dan kadangkala menyajikan alamat cache yang kemudian menjadi lapuk.

Itu juga menjelaskan mengapa aduan datang sebagai «internet rosak». Ping ke alamat IP membuktikan pautan baik, yang membuatkan kerosakan kelihatan seperti pada aplikasi. Senarai penyelesai ialah perkara pertama yang perlu dibaca dan yang terakhir untuk diedit.

Mitos: resolv.conf ialah fail tetapan

Tanya apa sebenarnya laluan itu sebelum mengubahnya:

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

Pada hos systemd-resolved ia ialah pautan simbolik ke fail stub yang menunjuk ke 127.0.0.53, dan pelayan sebenar hidup dalam keadaan setiap pautan yang dicetak resolvectl. Pada hos NetworkManager ia mungkin fail yang ditulis NetworkManager daripada sambungan aktif. Pada sesetengah klien vendor ia ialah fail biasa yang ditulis semula di tempatnya semasa bersambung dan, jika anda tidak bernasib baik, tidak pernah dipulihkan semasa terputus. Itu tiga pemilik berbeza, dan mengedit dua yang pertama dengan tangan sama ada tidak melakukan apa-apa atau bertahan sehingga peristiwa rangkaian seterusnya.

resolvectl status ialah paparan yang memberitahu kebenaran: pelayan DNS setiap pautan, domain penghalaan dan sama ada pautan terowong masih wujud. resolvectl query example.com pergi lebih jauh dan menunjukkan antara muka mana yang menjawab. Gunakan kedua-duanya sebelum menyentuh fail, dan ingat bahawa pelayar dengan DNS selamat sendiri mengabaikan semua ini.

Cari pemiliknya sebelum mengedit apa-apa

Biasanya tiga komponen bersaing untuk tetapan yang sama: systemd-resolved, NetworkManager dan apa sahaja yang dipasang klien VPN. Kenal pasti yang hidup dahulu:

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

Jika resolved aktif dan pautan simbolik menunjuk ke stubnya, fail global ialah output yang dijana dan suntingan anda bersifat kosmetik. Jika NetworkManager memiliki sambungan, pelayan tergolong dalam profil sambungan, jadi pembaikan ialah perubahan sifat nmcli dan bukan suntingan fail. Jika daemon vendor berjalan, hanya laluan pemulihannya sendiri yang bertahan pada sambungan seterusnya.

Bersihkan keadaan pautan yang ditinggalkan klien

Klien yang dibunuh tidak boleh menjalankan cangkuk pembersihannya. SIGKILL tidak boleh ditangkap sama sekali, manakala SIGINT dan SIGTERM boleh, jadi terowong yang «tiba-tiba berhenti» selepas pembunuhan paksa sering meninggalkan pendaftaran antara muka dan entri penyelesai di tempatnya. Cari PID tertentu dan hantar isyarat hanya kepadanya:

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

Jangan mencapai pkill -f vpn atau killall vpn sebelum membaca senarai padanan penuh. -f memadankan keseluruhan baris arahan, jadi ia boleh menamatkan skrip pembalut, sesi editor atau proses tidak berkaitan yang laluannya mengandungi rentetan itu. Menamatkan proses yang salah di tengah-tengah kerja ialah cara masalah penyelesai menjadi fail yang hilang.

resolvectl revert menetapkan semula konfigurasi DNS masa jalan pautan itu, yang lebih sempit daripada memulakan semula penyelesai dan jauh lebih sempit daripada mengedit fail global. Jika pautan terowong hilang sepenuhnya, systemctl restart NetworkManager membina semula keadaan sambungan dan itulah langkah yang sentiasa dituju oleh benang sumber. Perhatikan pengurus perkhidmatan dengan Restart=always, kerana ia boleh meletakkan semula klien yang dibunuh dan tetapan DNS-nya terus ke tempatnya.

Arah lain: DNS yang ditolak tetapi tidak pernah tiba

Imej cermin entri lapuk ialah terowong tanpa penyelesai yang boleh digunakan langsung. Pilihan DNS dalam profil ialah permintaan; komponen yang mengurus sambungan mesti menyerahkannya kepada penyelesai. Jika log menunjukkan pelayan diterima tetapi pautan terowong tidak membawa sebarang tetapan DNS, yang hilang ialah integrasi, bukan pelayan.

Uji penyerahan dengan melakukannya secara manual, yang memisahkan «pelayan salah» daripada «tiada siapa yang menggunakannya»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Domain penghalaan tangkap-semua menghantar setiap nama ke pautan itu, iaitu apa yang dikehendaki klien terowong penuh dan apa yang tidak boleh digunakan oleh DNS terbelah. Tetapan ini hilang pada sambungan seterusnya. Untuk menjadikannya kekal dalam NetworkManager, lumpuhkan DNS automatik, tetapkan pelayan pada sambungan dan tambah domain itu:

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 terowong syarikat yang sepatutnya hanya menjawab nama dalaman, senaraikan zon itu dengan tilde di hadapan dan bukan tangkap-semua, supaya nama awam terus menggunakan penyelesai tempatan.

Penyelesaian sementara yang menjadi gangguan seterusnya

Menyalin resolv.conf sebelum bersambung dan memulihkannya selepas itu ialah baris sah dalam runbook, dan ia penyelesaian sementara, bukan pembaikan. Ia gagal tepat apabila ia penting, kerana ranap atau but semula paksa melangkau pemulihan. Catat sebagai penyelesaian sementara supaya orang seterusnya tidak membina di atasnya.

Melumpuhkan systemd-resolved dan mengekod keras pelayan awam ialah langkah popular yang lain. Ia menjadikan sambungan dan pemutusan boleh diramal dan membuang DNS setiap pautan bagi setiap rangkaian lain, yang merosakkan DNS terbelah untuk nama dalaman dan menggagalkan tujuan terowong yang bertujuan menyimpan pertanyaan di dalamnya. Memasang resolvconf dan memakukan pelayan awam berharga sama dengan lapisan tambahan. Layan mana-mana satu sebagai diagnosis: jika ia memulihkan pelayaran, anda telah belajar bahawa integrasi penyelesai yang bersalah, bukan bahawa pelayan awam itu betul.

Pembaikan yang tahan lama ialah satu pemilik setiap lapisan: tentukan komponen mana yang memiliki DNS pautan terowong dan mana yang memiliki lalai global, catat dan buangkan yang lain dari laluan itu. Kemudian sahkan selepas terputus dengan nama yang hanya diselesaikan VPN. Jika nama peribadi masih menjawab, pendaftaran tidak dibuang; jika tiada apa-apa diselesaikan, fail menunjuk kepada pelayan yang tidak lagi wujud. Kedua-duanya kelihatan dalam resolvectl sebelum anda membuka pelayar.