DNS peribadi Pritunl gagal? Tambah laluan resolver yang sempit

Nama peribadi diselesaikan untuk semua orang di rangkaian korporat dan tamat masa untuk semua orang di VPN. Resolver menjawab gateway, laluan ke sana wujud, dan pertanyaan itu masih tidak pernah mendapat balasan. Yang hilang bukan resolver awam lain atau laluan yang lebih luas: ia alamat sumber yang sanggup dijawab oleh pelayan DNS peribadi.

Sahkan resolver menolak kumpulan klien anda

Mulakan dengan membuktikan kegagalan itu berkaitan sumber, bukan ketercapaian. Daripada klien yang bersambung, tanya resolver peribadi secara langsung dan perhatikan sama ada permintaan tamat masa atau kembali sebagai penolakan. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 tamat masa manakala pertanyaan yang sama dari gateway berjaya menunjukkan dasar akses pada resolver. Balasan SERVFAIL menunjukkan tempat yang sama sekali berbeza, biasanya zon atau pemaju huluan.

Catat alamat klien sebelum menguji. ip -4 addr show tun0 pada klien, atau pajakan yang dipaparkan dalam konsol, memberitahu anda kumpulan mana yang dilihat resolver.

Kemudian sahkan laluan itu memang wujud. Laluan yang menghantar alamat resolver ke dalam terowong ialah prasyarat, bukan penyelesaian; jika paket tidak pernah tiba, dasar sumber tidak pernah dirujuk. Semak dengan ip route get 10.40.0.53 pada klien.

Tambah satu laluan hos dan bukannya menterjemah semuanya

Panduan DNS peribadi Pritunl menerangkan ubat yang sempit: laluan /32 dengan NAT untuk alamat resolver, dengan alamat itu dipilih sebagai pelayan DNS klien. Laluan mengubah sumber yang dilihat resolver hanya untuk trafik DNS. Trafik aplikasi mengekalkan reka bentuk yang memelihara sumber yang anda pilih untuknya.

Konfigurasikannya melalui pemilik laluan yang disokong pelayan, selepas menyemak laluan sedia ada untuk pertindihan. Dalam contoh di atas destinasinya ialah 10.40.0.53/32 dengan NAT aktif, dan kumpulan klien kekal 10.90.0.0/24. Jangan terjemahkan seluruh julat peribadi untuk membaiki satu perkhidmatan, kerana setiap dasar hiliran yang bergantung pada alamat sebenar klien akan mula melihat gateway sebagai gantinya. Sahkan alamat yang benar-benar diterima resolver dengan memerhati log pertanyaannya semasa carian ujian. Laluan hos sahaja tidak membuktikan apa-apa tentang terjemahan atau kebenaran.

Resolver masih perlu membenarkan sumber yang diterjemahkan pada UDP dan TCP, dan balasannya mesti boleh kembali. Menukar sumber tidak boleh mencipta zon atau rekod yang hilang.

Tentukan sama ada pelayan atau klien yang menghantar pertanyaan

Pritunl juga mendokumenkan susunan proksi DNS yang berkaitan dengan VPN Client DNS Mapping, di mana pelayan memajukan pertanyaan huluan untuk klien. Dalam model itu sumber huluan milik konteks rangkaian pelayan itu sendiri, dan pengecualian di pihak klien ialah pembetulan yang salah.

Kenal pasti model mana yang aktif sebelum menambah apa-apa. Tiga pembaikan bertindih, proksi, penggantian resolver pada klien dan skrip NAT manual biasanya bermakna tiada siapa yang menetapkan: komponen mana yang sepatutnya menghantar pertanyaan. Semak bootstrap juga: resolver peribadi semata-mata tidak boleh menjadi satu-satunya cara mencari titik akhir sebelum terowong wujud, dan perubahan resolver kekal tidak sepatutnya hidup lebih lama daripada sambungan.

Uji carian peribadi, bukan halaman web awam

Selepas menggunakan perubahan dan menyambung semula, periksa konfigurasi resolver berkesan klien, kemudian selesaikan nama yang anda tahu hanya wujud dalam zon peribadi. dig intranet.example.net tanpa pelayan eksplisit menunjukkan apa yang sebenarnya digunakan klien. Ikutinya dengan permintaan ke alamat yang dikembalikan carian itu, kerana penyelesaian dan akses perkhidmatan ialah langkah berasingan. Pelayar yang memuatkan tapak awam melalui DNS-over-HTTPS tidak membuktikan apa-apa tentang laluan resolver peribadi sistem pengendalian. Resolver sekunder awam juga bukan pihak berkuasa untuk zon dalaman.

Catat alamat resolver, laluan /32 dan tetapan DNS klien bersama-sama dalam nota pelayan. Separuh konfigurasi itu jika dipulihkan sendiri akan menghasilkan semula kegagalan asal.

Akhir sekali, sahkan terowong masih menghalakan destinasi aplikasi selepas DNS berjaya. Laluan, akses perkhidmatan dan pengesahan kekal bebas daripada penyelesaian nama, dan carian yang berfungsi tidak mengatakan apa-apa tentang daya pemprosesan. Jika halaman peribadi perlahan tetapi diselesaikan, resolver telah melakukan tugasnya dan masalah berpindah ke laluan.