Ev VPN-inizə nas.home.arpa üçün öz DNS qeydlərini verin

Tunel qalxdıqdan sonra son addım adətən əlfəcinə yapışdırdığınız ünvandan daha yaxşı işləyən bir addır. dnsmasq host qeydi və müştərinin çata bildiyi həlledici ünvanı bunu iki fayl və multicast olmadan edir. Həqiqətən düşünmək lazım olan qərar daha dardır: müştəri bütün DNS-i ev həlledicisi vasitəsilə göndərir, yoxsa yalnız home.arpa altındakı adları? Aşağıdakı hər şey Linux müştərisi və ev administratorunun artıq idarə etdiyi laboratoriya həlledicisi ilə təsdiqlənmiş WireGuard quruluşunu fərz edir.

Müştəriyə həlledici verməyin üç yolu

Tunelə arabir qoşulan noutbuk üçün split-DNS daha yaxşı standartdır: adi internet adlarını maşının artıq etibar etdiyi həlledicidə saxlayır. Ev xidmətlərinə çatmaq üçün mövcud olan maşın üçün həlledicini ötürmək daha sadədir və əhatə dairəsinin xərci əhəmiyyət daşımır.

Qeydi zonanın sahibi olan həlledicidə dərc edin

Konfiqurasiya yazmazdan əvvəl rolları ayrı saxlayın: VPN müştəri ünvanı, həlledici və xidmət üç fərqli işi olan üç fərqli hostdur. Bu laboratoriyada onlar müştəri üçün 10.77.0.2, dnsmasq üçün 192.168.50.53 və NAS üçün 192.168.50.20-dir, tunel isə ev LAN-ını marşrutlaşdırır.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

host-record sətri ünvanı verir, local= sətri isə naməlum home.arpa suallarını yuxarı ötürmək əvəzinə bu həlledicinin içində saxlayır. Əvvəlcə mövcud konfiqurasiyanı oxuyun və artıq server, interfeys və ya eyni lokal domeni təyin edən hər şeyi uzlaşdırın; ziddiyyətli bir parçanın üstünə parça yığmaq asanlıqla yüklənən və səhv cavab verən həlledici yaradır. dnsmasq təlimatı hər iki direktivi və dinləmə nəzarətlərini təyin edir.

Sonra faylı deyil, işləyən xidməti yoxlayın. Konfiqurasiya testi və yenidən başlatma minimumdur, faktiki cavab isə sorğunun qaytardığıdır.

Həlledicini marşrutlaşdırın, təkcə veb səhifəni deyil

WireGuard-ın AllowedIPs parametri hansı təyinatların tunelə girdiyini müəyyən edir. Həlledici ünvanı ondan kənarda qalırsa, sorğu adi marşrutla çıxır və dnsmasq-a heç vaxt çatmır, baxmayaraq ki, NAS-ın özü əlçatandır. Həlledicinin ünvanını və ya onu ehtiva edən LAN prefiksini daxil edin və qarşı tərəfdə şlüzün yönləndirmə siyasətini yoxlayın.

İcazəli tunel aralığından 53 portunda UDP və TCP-yə icazə verin, müştərinin tunel ünvanına geri yol olsun. Testi asanlaşdırmaq üçün 53 portunu WAN-dan yönləndirməyin: ev bağlantısında açıq rekursiv həlledici saatlar içində tapılır. İnterfeysə bağlanmaq özlüyündə giriş siyasəti deyil.

Cavabı tətbiqdən əvvəl yoxlayın

Əvvəlcə birbaşa həlledicidən soruşun, sonra sistemdən, sonra tətbiqdən. Hər addım zəncirdə bir halqanı təcrid edir və aralarındakı fərq diaqnozdur.

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

TCP sorğusunu işlətməyə dəyər, çünki kəsilmiş UDP cavabı təkrar cəhdi məcbur edir və TCP 53-ü atan siyasət fasiləli görünən nasazlıqlar yaradır. getent addımı maşının həlledici konfiqurasiyasının həqiqətən nə etdiyini göstərir, bu isə həmişə ötürdüyünüz şey deyil.

Tunel bağlı olanda nə olacağına qərar verin

Müştərinin ümumi DNS-i 192.168.50.53-ə yönəlirsə, tunel qalxmayanda bütün ad həlli dayanır. Bu, yalnız tunellə faydalı olan maşında məqbuldur və kafe Wi-Fi-dan da istifadə edən noutbukda qəbuledilməzdir. Split-DNS sualı tamamilə aradan qaldırır, çünki yalnız home.arpa axtarışları ev həlledicisindən asılıdır.

Adın nə olduğunu xatırlayın: home.arpa yaşayış şəbəkələri üçün ayrılıb və qlobal olaraq unikal deyil, ona görə başqa şəbəkə eyni adı qanuni şəkildə istifadə edə bilər. Bu, yerli rahatlıqdır, etibarlı identifikator deyil. Xidmət köçəndə qeydi aktual saxlayın və laboratoriya istismardan çıxarıldıqda həlledici siyasətini silin, artıq mövcud olmayan tunel vasitəsilə çata bildiyi ünvana işarə edən noutbuku qoyub getməyin.