VPN tersambung tetapi nama gagal: di mana DNS sebenarnya rusak

Tunnel menyala, ikon hijau, dan setiap tab peramban melaporkan kegagalan resolusi nama. Tiga mekanisme berbeda menghasilkan gambaran itu: resolver mungkin tidak terjangkau, klien mungkin menanyakan resolver yang tidak Anda duga, atau hanya nama privat yang gagal. Pisahkan ketiganya sebelum Anda mengubah apa pun pada protokol tunnel, karena masing-masing diperbaiki di tempat berbeda. Urutan di bawah dimulai dari pengamatan yang memisahkan ketiganya.

Apa yang sebenarnya dibutuhkan sebuah pencarian

Sebuah pencarian membutuhkan tiga hal: alamat resolver, rute ke alamat itu, dan jawaban yang cocok dengan pertanyaan. Masing-masing bisa gagal sendiri-sendiri, dan gejala yang terlihat adalah halaman yang sama yang tidak dimuat. Itulah sebabnya halaman galat hampir tidak memberi tahu apa pun sampai Anda tahu mana dari ketiganya yang rusak.

Klien mempelajari resolver-nya dari profil VPN, dari DHCP di tunnel, atau dari konfigurasinya sendiri, dan sumber mana yang menang bergantung pada platform. Di Windows, ipconfig /all mencetak server DNS per adaptor, jadi Anda bisa melihat apakah nilai yang didorong benar-benar tiba. Nilai yang didorong tetapi tidak pernah sampai ke sistem operasi adalah kegagalan senyap yang umum. Baca nilai yang dikonfigurasi sebelum menyentuh profil.

Linux dan macOS menjawab pertanyaan yang sama dengan perintah berbeda, dan jawabannya layak dibaca dengan cara yang sama: resolvectl status dan scutil --dns keduanya mencantumkan server per antarmuka. Bandingkan daftar itu dengan alamat yang diklaim profil didorong. Ketidakcocokan di sini menjelaskan semua hal di hilir, jadi selesaikan sebelum menguji nama.

Uji satu nama publik dan satu nama privat

Tanyakan nama host publik biasa dan nama host privat yang terdokumentasi dari mesin yang sama, lalu catat server mana yang menjawab masing-masing. Jika keduanya gagal, resolver atau rutenya rusak. Jika hanya nama privat yang gagal, resolver menjawab dan pertanyaannya menjadi zona atau perutean. Jalankan kedua kueri dalam selisih satu menit agar perubahan rute tidak dapat menjelaskan perbedaannya.

Jauhkan nama internal dari tangkapan layar publik dan dari resolver publik. Waktu tunggu dan jawaban domain tidak ada adalah pengamatan berbeda: yang pertama mengatakan tidak ada yang kembali, yang kedua mengatakan otoritas menjawab bahwa nama itu tidak ada. Memperlakukan keduanya sebagai satu galat membawa Anda ke lapisan yang salah, dan peringatan sertifikat adalah hal ketiga lagi, bukan kegagalan DNS.

nslookup mencetak server yang ditanyai dan jawaban yang diterima, dan itulah tepat pasangan yang Anda butuhkan. Jalankan dua kali di shell yang sama dan tuliskan alamat yang menjawab di samping setiap jawaban.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Pastikan klien benar-benar dapat menjangkau server itu

Resolver privat yang didorong profil hanya berguna jika klien dapat menjangkaunya selagi tunnel menyala. Alamat yang tampak benar tanpa rute menghasilkan waktu tunggu, dan status tersambung tunnel tidak mengatakan apa pun tentang rute itu. Pemeriksaannya adalah pencarian rute yang diarahkan ke resolver itu sendiri, bukan ke titik akhir VPN.

Setiap platform menjawabnya dalam satu baris, dan antarmuka yang disebut di keluaran adalah seluruh jawabannya. Jika ia menunjuk ke adaptor fisik sementara resolver berada di belakang tunnel, profil tidak mendorong prefiks yang mencakupnya.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Pada profil tunnel terpisah, resolver bisa berada di luar rute yang didorong, yang merupakan masalah profil dan bukan masalah server. Bandingkan alamat resolver dengan prefiks yang didorong dan pastikan salah satunya mencakupnya. Ketidakcocokan yang sama menjelaskan mengapa DNS bekerja di satu jaringan dan gagal di jaringan lain dengan profil identik.

Ingat bahwa peramban dapat melewati resolver sistem

Peramban dengan DNS aman aktif dapat mengirim kueri melalui HTTPS ke penyedia pilihannya sendiri dan mengabaikan resolver sistem operasi sepenuhnya. Sistem lalu tampak benar sementara peramban gagal, atau sebaliknya. Itu pertanyaan kebijakan bagi peramban, bukan bagi tunnel.

Periksa setelan DNS aman peramban dan kebijakan terkelola apa pun yang mengendalikannya, lalu coba aplikasi atau peramban kedua dengan tunnel tanpa perubahan. Jika hanya satu aplikasi yang gagal, perbaikannya ada di aplikasi itu. Jendela privat bukan perbandingan bersih, karena dapat menonaktifkan ekstensi secara bawaan di satu peramban dan tidak di peramban lain, dan tidak pernah melewati kebijakan terkelola. Gunakan profil peramban kedua atau aplikasi lain sebagai gantinya.

Bersihkan cache dan uji ulang tugas yang sebenarnya

Setelah memperbaiki setelan, bersihkan cache resolver lokal agar jawaban lama tidak bertahan melewati perbaikan. Pemulihan singkat yang diikuti kegagalan lain berarti penyebabnya masih ada, bukan bahwa pembersihan gagal. Pilih baris yang sesuai dengan mesin yang Anda pakai, karena ketiga cache terpisah.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Lalu ulangi tugas semula alih-alih pencarian sintetis, karena tugas itulah yang penting bagi pengguna. Sambungkan ulang sekali juga, agar pengujian ulang mencakup keadaan yang benar-benar akan dialami pengguna. Referensi nslookup dari Microsoft adalah halaman yang sebaiknya disimpan untuk argumen kueri.

Jika nama gagal hanya setelah memutus koneksi, klien tidak memulihkan konfigurasi sebelumnya, yang merupakan bug siklus hidup untuk dilaporkan, bukan server DNS untuk diganti. Pencarian yang berhasil juga bukan uji kebocoran, karena negara keluar tidak memberi tahu resolver mana yang menjawab.