DNS privat Pritunl gagal? Tambahkan rute resolver yang sempit

Nama privat diresolusikan untuk semua orang di jaringan perusahaan dan kedaluwarsa untuk semua orang di VPN. Resolver menjawab gateway, rute ke sana ada, dan kueri tetap tidak pernah mendapat balasan. Yang hilang bukan resolver publik lain atau rute yang lebih luas: melainkan alamat sumber yang bersedia dijawab oleh server DNS privat.

Pastikan resolver menolak kumpulan klien Anda

Mulailah dengan membuktikan bahwa kegagalan itu soal sumber, bukan keterjangkauan. Dari klien yang terhubung, kueri resolver privat secara langsung dan amati apakah permintaan habis waktu atau kembali sebagai penolakan. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 yang habis waktu sementara kueri yang sama dari gateway berhasil menunjukkan kebijakan akses pada resolver. Balasan SERVFAIL menunjukkan tempat yang sama sekali lain, biasanya zona atau penerus hulu.

Catat alamat klien sebelum menguji. ip -4 addr show tun0 pada klien, atau sewa yang ditampilkan di konsol, memberi tahu Anda kumpulan mana yang dilihat resolver.

Lalu pastikan jalurnya memang ada. Rute yang mengirim alamat resolver ke dalam terowongan adalah prasyarat, bukan solusinya; jika paket tidak pernah tiba, kebijakan sumber tidak pernah ditinjau. Periksa dengan ip route get 10.40.0.53 pada klien.

Tambahkan satu rute host alih-alih menerjemahkan semuanya

Panduan DNS privat Pritunl menjelaskan obat yang sempit: rute /32 dengan NAT untuk alamat resolver, dengan alamat itu dipilih sebagai server DNS klien. Rute mengubah sumber yang dilihat resolver hanya untuk lalu lintas DNS. Lalu lintas aplikasi mempertahankan desain yang mempertahankan sumber yang Anda pilih untuknya.

Konfigurasikan melalui pemilik rute yang didukung server, setelah meninjau rute yang ada untuk tumpang tindih. Dalam contoh di atas tujuannya adalah 10.40.0.53/32 dengan NAT aktif, dan kumpulan klien tetap 10.90.0.0/24. Jangan menerjemahkan seluruh rentang privat untuk memperbaiki satu layanan, karena setiap kebijakan hilir yang bergantung pada alamat asli klien akan mulai melihat gateway sebagai gantinya. Pastikan alamat yang benar-benar diterima resolver dengan mengamati log kuerinya selama pencarian uji. Rute host saja tidak membuktikan apa pun tentang penerjemahan atau izin.

Resolver tetap harus mengizinkan sumber yang diterjemahkan pada UDP dan TCP, dan balasannya harus dapat kembali. Mengubah sumber tidak dapat membuat zona atau catatan yang hilang.

Tentukan apakah server atau klien yang mengirim kueri

Pritunl juga mendokumentasikan pengaturan proksi DNS yang terkait dengan VPN Client DNS Mapping, di mana server meneruskan kueri hulu untuk klien. Dalam model itu sumber hulu milik konteks jaringan server sendiri, dan pengecualian di sisi klien adalah perbaikan yang salah.

Identifikasi model mana yang aktif sebelum menambahkan apa pun. Tiga perbaikan yang tumpang tindih, sebuah proksi, penggantian resolver di klien, dan skrip NAT manual biasanya berarti tidak ada yang menetapkan: komponen mana yang seharusnya mengirim kueri. Periksa juga bootstrap: resolver yang hanya privat tidak bisa menjadi satu-satunya cara menemukan titik akhir sebelum terowongan ada, dan perubahan resolver permanen tidak boleh bertahan lebih lama dari koneksi.

Uji pencarian privat, bukan halaman web publik

Setelah menerapkan perubahan dan menyambung ulang, periksa konfigurasi resolver efektif klien, lalu resolusi nama yang Anda tahu hanya ada di zona privat. dig intranet.example.net tanpa server eksplisit menunjukkan apa yang benar-benar digunakan klien. Ikuti dengan permintaan ke alamat yang dikembalikan pencarian itu, karena resolusi dan akses layanan adalah langkah terpisah. Peramban yang memuat situs publik melalui DNS-over-HTTPS tidak membuktikan apa pun tentang jalur resolver privat sistem operasi. Resolver sekunder publik juga bukan otoritas untuk zona internal.

Catat alamat resolver, rute /32, dan pengaturan DNS klien bersama-sama di catatan server. Setengah dari konfigurasi itu bila dipulihkan sendiri akan mereproduksi kegagalan awal.

Terakhir, pastikan terowongan masih merutekan tujuan aplikasi setelah DNS berhasil. Rute, akses layanan, dan autentikasi tetap independen dari resolusi nama, dan pencarian yang berfungsi tidak mengatakan apa pun tentang throughput. Jika halaman privat lambat tetapi berhasil diresolusikan, resolver telah melakukan tugasnya dan masalahnya berpindah ke jalur.