dnsmasq-də VPN domeniniz zona köçürməsi deyil

Müştərinin dnsmasq konfiqurasiyasında korporativ zonanı axtarır, tapmırsınız və VPN-in öz domenini göndərmədiyi nəticəsinə gəlirsiniz. Göndərilən şey marşrutlaşdırma işarəsidir, zona deyil. Müştəri domeni və onun üçün cavab verməli olan resolver-i qeyd edir, idarə olunan backend isə bunu şərti yönləndirməyə çevirir. Yanlış yerdə axtarış əmin və tamamilə yanlış diaqnoz verir.

Müştərinin qəbul etdiyi şey şlüzün təklif etdiyi şey deyil

Şlüz resolver, domen və həmin resolver-ə çatmaq üçün lazım olan marşrutu təklif edə bilər, müştəri isə hər üçünü və ya heç birini qəbul edə bilər. İdxal edilmiş profil, köməkçi skript və ya göndərilən seçimlərə məhəl qoymayan siyasət qəbul edilmiş çoxluğu boş qoya bilər, halbuki server tərəfi doğru görünür. Serverin konfiqurasiyasından deyil, müştərinin qeydə alınmış vəziyyətindən başlayın, çünki resolver-in həqiqətən aldığı şey həmin vəziyyətdir. Qəbul edilmiş domen yoxdursa, daha sonrakı heç nə əhəmiyyətli olmayacaq. Hər hansı keşi yoxlamadan əvvəl bağlantının DNS xassələrini yoxlayın.

Bu fərq heç vaxt gəlməyən domen haqqında hesabatların çoxunu izah edir. O, təklif edildi və tətbiq olunmadı.

İki növ domen qeydi

Bağlantı adi axtarış domenlərini və yalnız marşrut domenlərini daşıya bilər, ikinci növ isə tilda ilə başlayır. Axtarış domeni həm sorğuları yönləndirir, həm də qısa adların genişlənməsinə imkan verir, bu iş stansiyasında rahat, serverdə isə təəccüblüdür. Yalnız marşrut domeni bildirir ki, bu şəkilçi üçün sorğular qısa adların necə həll olunduğunu dəyişmədən müəyyən serverlərə getməlidir. Eyni domeni hər iki üsulla yazmaq artıqlıq deyil, çünki iki qeyd fərqli işlər görür.

Şəxsi ad məkanı üçün adətən istədiyiniz forma yalnız marşrut formasıdır. O, korporativ şəkilçini korporativ resolver-ə yönəldir və qalan hər şeyi sərbəst buraxır.

resolv.conf-da localhost səhv deyil

Yerli keş resolver-i istifadə edildikdə, sistem faylı loopback ünvanına və başqa heç nəyə işarə etmir. Bu qeyd yerli dinləyicini müəyyən edir, idarəçinin ona verdiyi yuxarı serverləri deyil. Korporativ ünvan faylda qanuni olaraq olmayacaq.

Bu qeydi ictimai resolver ilə əvəz etmək klassik səhv düzəlişdir. O, ictimai ad həllini bərpa edir və həmin redaktədə şərti siyasəti atır.

Backendləri qarışdırmayın

İdarə olunan dnsmasq nüsxəsi və sistem resolver-i fərqli konfiqurasiya və fərqli status görünüşləri olan fərqli proqramlardır. Birinin status əmri digəri haqqında faydalı heç nə demir.

İdarəçinin hansı backend-dən istifadə etmək üçün konfiqurasiya edildiyini müəyyən edin, sonra həmin backend-in yaradılmış konfiqurasiyasını oxuyun, təsadüfən mövcud olan bütün distribusiya faylını deyil. İdarəçi öz nüsxə konfiqurasiyasını yazır və həmin nüsxə üçün fərdi seçimləri dəstəkləyir, ona görə də əlaqəsiz qlobal faylı redaktə etmək heç nəyi dəyişmir və effektsiz dəyişiklik kimi görünür. 53 portunda ikinci daemon işə salmaq faydasızdan da pisdir, çünki indi iki proqram portun kimə aid olduğu barədə razılaşmır. Əvvəlcə sahibi müəyyənləşdirin, sonra həmin sahibin oxuduğu yerdə redaktə edin.

Ad məkanını sınayın, yalnız cavabı deyil

Tətbiqin adi yolu ilə bir icazəli şəxsi ad və bir ictimai nəzarət adı sorğulayın. Korporativ serverə birbaşa sorğu qeydin mövcud olduğunu sübut edir; müştərinin həmin serveri seçdiyini sübut etmir. İkinci sorğu siyasəti sınayan sorğudur.

Sonra yenidən qoşulmadan və ayrıldıqdan sonra təkrarlayın. Əlaqə bağlantının həyat dövrünü izləməlidir və şəxsi adlar tunel olmadıqda həll olunmağı dayandırmalıdır, eyni şəkilçiyə cavab verən ictimai resolver-ə geri dönmək əvəzinə. Əgər geri dönürlərsə, sızma tapdınız, bu da qırılmış axtarışdan fərqli qüsurdur. Hansı backend-in işlədiyini, hansı domenlərin tətbiq olunduğunu və hər sorğunun nə qaytardığını yazın.