Pritunl özəl DNS uğursuz olur? Dar həlledici marşrutu əlavə edin

Özəl adlar korporativ şəbəkədə hamı üçün həll olunur, VPN-də isə hamı üçün vaxtı bitir. Həlledici şlüzə cavab verir, ona marşrut mövcuddur, sorğu isə yenə cavab almır. Çatışmayan başqa bir ictimai həlledici və ya daha geniş marşrut deyil: özəl DNS serverinin cavab verməyə hazır olduğu mənbə ünvanıdır.

Həlledicinin müştəri hovuzunuzu rədd etdiyini təsdiqləyin

Uğursuzluğun əlçatanlıqla deyil, mənbə ilə bağlı olduğunu sübut etməklə başlayın. Qoşulmuş müştəridən özəl həllediciyə birbaşa sorğu göndərin və sorğunun vaxtının bitdiyini yoxsa rədd olaraq qayıtdığını izləyin. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 vaxtı bitdiyi halda şlüzdən eyni sorğunun uğur qazanması həlledicidəki giriş siyasətinə işarə edir. SERVFAIL cavabı tamamilə başqa yerə, adətən zonaya və ya yuxarı axın yönləndiricisinə işarə edir.

Sınaqdan əvvəl müştərinin ünvanını qeyd edin. Müştəridə ip -4 addr show tun0 və ya konsolda göstərilən icarə həlledicinin hansı hovuzu gördüyünü bildirir.

Sonra yolun ümumiyyətlə mövcud olduğunu təsdiqləyin. Həlledici ünvanını tunelə göndərən marşrut ilkin şərtdir, düzəliş deyil; paketlər heç vaxt çatmasa, mənbə siyasətinə heç müraciət olunmur. Bunu müştəridə ip route get 10.40.0.53 ilə yoxlayın.

Hər şeyi tərcümə etmək əvəzinə bir host marşrutu əlavə edin

Pritunl-in özəl DNS təlimatı dar həlli təsvir edir: həlledici ünvanı üçün NAT aktivləşdirilmiş /32 marşrutu və həmin ünvanın müştərilərin DNS serveri seçilməsi. Marşrut həlledicinin gördüyü mənbəyi yalnız DNS trafiki üçün dəyişir. Tətbiq trafiki onun üçün seçdiyiniz mənbə qoruyucu dizaynı saxlayır.

Onu serverin dəstəklənən marşrut sahibi vasitəsilə, mövcud marşrutları üst-üstə düşmə baxımından nəzərdən keçirdikdən sonra qurun. Yuxarıdakı nümunədə təyinat NAT aktivləşdirilmiş 10.40.0.53/32, müştəri hovuzu isə 10.90.0.0/24 olaraq qalır. Bir xidməti düzəltmək üçün bütün özəl diapazonu tərcümə etməyin, çünki müştərinin real ünvanına güvənən hər aşağı axın siyasəti bunun əvəzinə şlüzü görməyə başlayacaq. Sınaq axtarışı zamanı onun sorğu jurnalına baxaraq həlledicinin həqiqətən aldığı ünvanı təsdiqləyin. Tək bir host marşrutu tərcümə və ya icazə barədə heç nə sübut etmir.

Həlledici hələ də tərcümə olunmuş mənbəyə UDP və TCP üzərində icazə verməlidir, cavabları isə geri qayıda bilməlidir. Mənbəni dəyişmək itkin zona və ya qeyd yarada bilməz.

Sorğunu serverin yoxsa müştərinin göndərdiyinə qərar verin

Pritunl həmçinin VPN Client DNS Mapping ilə bağlı DNS-proxy quruluşunu sənədləşdirir, burada server müştərilər üçün yuxarı axın sorğularını yönləndirir. Bu modeldə yuxarı axın mənbəyi serverin öz şəbəkə kontekstinə aiddir və müştəri tərəfindəki istisna yanlış düzəlişdir.

Nəyisə əlavə etməzdən əvvəl hansı modelin aktiv olduğunu müəyyənləşdirin. Üç üst-üstə düşən düzəliş, bir proxy, müştəri tərəfində həlledici üstələməsi və əl ilə NAT skripti adətən o deməkdir ki, heç kim müəyyən etməyib: sorğunu hansı komponentin göndərməli olduğunu. Bootstrap da yoxlayın: yalnız özəl həlledici tunel mövcud olmadan əvvəl son nöqtəni tapmağın yeganə yolu ola bilməz və daimi həlledici dəyişikliyi bağlantıdan sonra da yaşamamalıdır.

İctimai veb səhifəni deyil, özəl axtarışı sınaqdan keçirin

Dəyişikliyi tətbiq edib yenidən qoşulduqdan sonra müştərinin effektiv həlledici konfiqurasiyasını yoxlayın, sonra yalnız özəl zonada mövcud olduğunu bildiyiniz adı həll edin. Açıq server göstərilmədən dig intranet.example.net müştərinin həqiqətən nədən istifadə etdiyini göstərir. Ardınca həmin axtarışın qaytardığı ünvana sorğu göndərin, çünki həll və xidmətə çıxış ayrı addımlardır. DNS-over-HTTPS ilə ictimai saytları açan brauzer əməliyyat sisteminin özəl həlledici yoluna dair heç nə sübut etmir. İctimai ikinci dərəcəli həlledici də daxili zona üçün səlahiyyətli deyil.

Həlledici ünvanını, /32 marşrutunu və müştərinin DNS parametrini birlikdə server qeydlərində yazın. Bu konfiqurasiyanın yalnız yarısı bərpa edilsə, ilkin uğursuzluq təkrarlanır.

Nəhayət, DNS uğurlu olduqdan sonra tunelin hələ də tətbiq təyinatına marşrut verdiyini təsdiqləyin. Marşrut, xidmətə çıxış və autentifikasiya ad həllindən asılı olmayaraq qalır və işləyən axtarış ötürmə qabiliyyəti barədə heç nə demir. Özəl səhifə yavaşdır, amma həll olunursa, həlledici öz işini görüb və problem yola keçib.