Daxili adlar VPN-də uğursuz olur, açıq saytlar isə açılır

Bir istifadəçi intranet host adının VPN üzərindən həll olunmadığını bildirir. Eyni noutbukdan gələn ikinci hesabat deyir ki, sızma testi hələ də sorğuların yerli resolver tərəfindən cavablandırıldığını göstərir. Bir problem kimi səslənirlər, amma ikidirlər, dəlilləri fərqlidir və birincinin adi təmiri ikincini daha da pisləşdirir. Hər hansı parametrə toxunmazdan əvvəl onları ayırın.

Bir nasazlıq olmayan iki simptom

Daxili adı həll edə bilməmək o deməkdir ki, sual cavabı olmayan bir yerə gedib. Sorğuların tuneldən çıxması isə cavab mövcud olanda belə sualın yanlış yerə getdiyini göstərir. Bunlar əks nasazlıqlardır: biri itkin cavab, digəri artıq təyinatdır.

Tələ isə budur: ofis resolverini hər yerə əlavə etmək birincini düzəldir və ikincini zəmanətlə yaradır. Açıq resolveri hər yerə əlavə etmək bunun əksini edir.

Hər iki müşahidəni vaxt qeydi ilə birlikdə yazın, sonra aşağıdakı dörd yoxlamanı sıra ilə keçin.

Sualı hansı adapterin resolveri alır

Windows-da DNS müştərisi serverləri adapter bağlama sırasına görə seçir və tunel adapteri avtomatik olaraq birinci deyil. Adapterin qabaqcıl parametrlərini açın, uzaq giriş bağlantısını fiziki adapterin üstünə köçürün, sonra dəyişikliyin yeni sessiyada qüvvəyə minməsi üçün yenidən qoşulun.

Bağlama sırası yalnız birinci yarıdır. Müştəri həm də hansı adların o adapterə aid olduğunu bilməlidir və bu, sıra deyil, şəkilçi məsələsidir.

İşləyən maşının ipconfig /all çıxışını noutbukun çıxışının yanına qoyun, hər ikisi tunel açıqkən götürülməlidir. İşləyən maşın ofis adapterində bağlantıya xas DNS şəkilçisi göstərəcək, noutbuk isə tuneldə heç nə göstərməyə bilər. Bu fərq server elə buradadır, ad isə yenə uğursuz olur tipli bütöv bir hesabat sinfini izah edir, çünki şəkilçi olmadan qısa ad heç vaxt ofis resolverinin xidmət etdiyi zonaya tamamlanmır.

Qısa ada marşrutdan əvvəl şəkilçi lazımdır

Kvalifikasiya olunmamış host adı yazmaq resolverdən domeni təxmin etməsini istəyir. Təxmin bağlantıya bağlanmış şəkilçi siyahısından gəlir və bu siyahı boşdursa, sorğu heç bir özəl zonanın uyğun gəlmədiyi tək etiket kimi çıxır.

İşləyən maşının şəkilçisini DNS nişanında VPN adapterinin IPv4 xassələrinə köçürün, sonra yenidən qoşulun. Linux-da ekvivalent tunel linkindəki axtarış domenidir və systemd-resolved bunu qlobal deyil, hər link üzrə göstərir.

Qeydlərinizdə iki parametri ayrı saxlayın. Şəkilçi nəyin soruşulduğunu dəyişir; resolver ünvanı kimin soruşulduğunu dəyişir. Birini düzəldib digərini səhv qoymaq təsadüfi görünən nəticə verir.

Əvvəlcə resolverdən, sonra addan soruşun

Ofis resolverinə birbaşa sorğu ad problemini yol problemindən ayırır, çünki müştərinin resolver seçimini tamamilə yan keçir.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Birinci əmr konkret serverdən tam kvalifikasiya olunmuş ad soruşur. Cavab verirsə, resolver və ona gedən marşrut qaydasındadır, nasazlıq seçimdə və ya şəkilçidədir. Vaxt aşımı olarsa, ünvan səhvdir və ya əlçatmazdır və problem DNS-də deyil, marşrutlaşdırmadadır. İkinci əmr qısa adla nə baş verdiyini göstərir, üçüncü isə systemd hostunda hər link üzrə resolver konfiqurasiyasını çap edir.

Bəzi şəbəkələrin naməlum adlar üçün qaytardığı wildcard cavablarına diqqət edin. Ağlabatan görünən cavab nəzərdə tutulan serverin cavab verdiyinə dəlil deyil, ona görə qaytarılan ünvanı daxili xidmətin həqiqətən istifadə etdiyi ünvanla müqayisə edin. Ünvan parkinq səhifəsinə və ya proxy-ə aiddirsə, resolver cavab verib, amma cavab heç vaxt sizin olmayıb. Bu fərq bütün müddət işləyən tunelin arxasınca bir saat itirməyin qarşısını alır.

Linux-da /etc/resolv.conf faylını yenidən yazan VPN müştərisi yerli resolverləri tamamilə əvəz edir. vpnc bunun qarşısını almaq üçün DNSUpdate no seçimini açır, systemd-resolved isə yalnız siyahıdakı domenləri tunel linkinə yönləndirə bilir. Hər iki yanaşma açıq adları yerli resolverdə saxlayır və daxili adları ofisə göndərir.

Sızma qaydadır, onay qutusu deyil

Ad həlli 53 portuna UDP mübadiləsidir, ona görə veb trafiki daşıyıb UDP daşımayan tunel sorğunu fiziki yolda qoyur. Bunu açıq ad həll olunarkən fiziki şəbəkə kartında tutmaqla sübut edin. Həmin interfeysdə oxunaqlı formada görünən sorğu tunelin onu daşımadığını göstərir.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Sorğu həmin interfeysdə oxunaqlı formada görünürsə, tunel onu daşımır. Təmir 53 portuna yalnız VPN-in ötürdüyü resolverə icazə verən və digər təyinatları atan qayda, üstəgəl ötürülən seçimi səssizcə atmadan müştəri konfiqurasiyasıdır.

Bu son hissə göründüyündən daha vacibdir. OpenVPN-i route-nopull ilə başladın və ötürülən DNS seçimi marşrutlarla birlikdə yox olur, əgər çəkmə filtri onu saxlamaq üçün genişləndirilməyibsə. dhcp-option DNS seçimini nəzərə almayan müştəri isə əvvəl nə varsa onu işlətməyə davam edəcək. Server tərəfindəki hər dəyişiklik qüvvəyə minmək üçün yeni sessiya tələb edir, çünki resolver siyahısı tunel qalxanda verilir və köhnə sessiya köhnə vəziyyəti göstərməyə davam edir.

Bileti bağlamazdan əvvəl hansı nasazlığı həqiqətən müşahidə etdiyinizi qeyd edin. İtkin daxili cavab və tuneldən qaçan sorğu fərqli təmir tələb edir, birincini düzəldən şəkilçi dəyişikliyi isə ikincini səssizcə pisləşdirə bilər. Bileti sonra götürən etiketə güvənəcək, ona görə etiketi dəqiq edin.