Mengapa nslookup berhasil lewat VPN tetapi peramban tidak

nslookup mengirim kueri ke server yang Anda sebutkan dan mencetak jawabannya, itulah sebabnya ia bisa berhasil sementara setiap tab peramban gagal. Peramban meminta sistem operasi untuk menyelesaikan, dan sistem operasi menimbang resolver per antarmuka, aturan kebijakan penyelesaian nama, dan lokasi jaringan adaptor. Lalu peramban dapat menambahkan DNS terenkripsinya sendiri di atasnya. Tiga jalur berbeda, satu gejala, dan terowongan biasanya bukan bagian yang rusak.

Pemeriksaan di bawah mengikuti jalur itu dari sistem ke luar. Jangan menyunting profil VPN sebelum Anda tahu jalur mana yang menjawab dan mana yang gagal.

Tiga kebijakan menentukan jawabannya

Setiap antarmuka membawa daftar resolver dan akhiran pencariannya sendiri. Adaptor VPN menambahkan server sementara adaptor fisik mempertahankan miliknya, dan sistem dapat mengambil yang menjawab lebih dulu, sehingga pencarian dapat dilayani di luar terowongan tanpa ada yang memilihnya. Aturan tabel kebijakan penyelesaian nama dapat mengirim domain terpilih ke server terpilih, begitulah split DNS biasanya diungkapkan di Windows. Dan klien atau gateway VPN dapat mendorong alamat resolver yang hanya ada di dalam jaringan privat.

Ketiganya berinteraksi dengan cara yang tampak semena-mena dari peramban. Resolver yang didorong pada alamat privat tanpa rute melalui terowongan terpisah membuat setiap pencarian tersendat lalu gagal. Aturan kebijakan yang mencakup akhiran internal dan menunjuk ke server yang mati menghasilkan galat yang terlihat sama dengan rute yang hilang. Akhiran pencarian yang hilang dari adaptor VPN mengubah nama pendek menjadi kueri publik untuk domain yang salah. Masing-masing perlu perbaikan berbeda.

Mengapa peramban menanyakan pertanyaan lain

nslookup mengeluarkan kuerinya sendiri ke server yang dipilihnya dan tidak mengikuti kebijakan ruang nama maupun pengaturan DNS terenkripsi peramban. Itulah sebabnya kueri manual ke resolver publik dijawab sementara peramban melaporkan situs tidak ada. Anda membandingkan dua program, bukan dua keadaan satu program.

Preferensi keluarga alamat menjelaskan penundaan, bukan kegagalan. Peramban yang meminta catatan IPv6 lebih dulu pada terowongan yang hanya membawa IPv4 menunggu batas waktu habis sebelum mundur. Firefox membawa preferensi justru untuk ini, dan mematikannya adalah langkah diagnostik, bukan perbaikan.

Baca daftar resolver dan aturannya

Di Windows, cetak apa yang dipegang sistem sebelum berteori. Get-DnsClientServerAddress menampilkan server per antarmuka, Get-DnsClientNrptRule mendaftar aturan ruang nama, dan Resolve-DnsName menjawab nama persis melalui jalur sistem. Bandingkan jawaban itu dengan kueri langsung ke server VPN berdasarkan alamat. Saat Resolve-DnsName gagal dan kueri langsung berhasil, tersangka adalah daftar resolver atau aturan ruang nama.

Periksa namanya juga. Nama pendek internal mungkin memerlukan akhiran privat yang hanya disediakan adaptor VPN, sedangkan nama berkualifikasi penuh terselesaikan dengan baik. Peringatan sertifikat setelah pencarian berhasil termasuk masalah lain.

Resolver terdorong yang tidak terjangkau

Gateway atau klien dapat mendorong alamat resolver, dan alamat itu harus terjangkau melalui terowongan. Pada terowongan terpisah, rentang privat yang memuat resolver mungkin tidak termasuk rute yang disertakan, sehingga menghasilkan pencarian yang tidak pernah mendapat jawaban. Pastikan rutenya ada, lalu tanyakan alamat itu secara khusus, melalui terowongan. Inilah kegagalan di balik galat domain di peramban sementara resolver publik masih menjawab.

Jika resolver tidak terjangkau, perbaikannya adalah rute atau subnet yang disertakan, bukan server DNS lain.

DNS terenkripsi melewati seluruh jalur

Peramban dengan DNS-over-HTTPS menyelesaikan nama sendiri melalui koneksi HTTPS ke penyedia pilihan. Saat itu aktif, resolver sistem dan aturan split DNS dilewati sepenuhnya untuk pencarian tersebut, sehingga nama internal gagal di peramban sementara sistem operasi menyelesaikannya dengan benar. Sebaliknya juga terjadi: nama internal berhasil di peramban melalui penyedia yang seharusnya tidak pernah melihatnya, dan itu masalah kebijakan, bukan konektivitas.

Putuskan dengan sadar apakah DNS terenkripsi diizinkan pada perangkat terkelola, lalu konfigurasikan melalui permukaan manajemen peramban agar pilihannya terlihat. Menyerahkannya pada preferensi individu menghasilkan armada di mana VPN yang sama berperilaku berbeda di setiap laptop.

Perbaikan yang sesuai dengan kegagalan

Jika VPN mendorong resolver-nya, buat terowongan membawa lalu lintas ke sana dan buat pengaturan yang sama terlihat pada adaptor yang berpartisipasi dalam penyelesaian. Jika situs lokal berhenti terselesaikan saat terhubung, tambahkan pengecualian ruang nama eksplisit atau penerus bersyarat alih-alih mengganti resolver sepenuhnya. Jika DNS terenkripsi peramban melewati kebijakan, itulah pengaturan yang harus diubah. Jangan pernah menambahkan resolver publik untuk memperbaiki nama internal: itu membocorkan kueri privat dan tidak menyelesaikan nama.

Lalu pisahkan pencarian dari koneksi. Nama yang terselesaikan ke alamat yang benar tetapi menolak koneksi adalah masalah layanan, tembok api, atau sertifikat, dan perubahan DNS tidak akan memperbaikinya.

Catat jalur mana yang menjawab, mana yang gagal, dan apa yang Anda ubah. Laporan berikutnya atas gejala yang sama kemudian hanya perlu satu perintah, bukan satu sore.