Niyə şəxsi DNS adları VPN müştərilərində uğursuz olur və harada yoxlamaq lazımdır

Otel otağında noutbuku açırsınız, müştərini işə salırsınız, daxili fayl serverinin adını yazırsınız və heç nə almırsınız. Tunel bağlı olduğunu bildirir və eyni alt şəbəkədəki ünvana ping hələ də cavab verir, yəni nəqliyyat özü qaydasındadır. Yalnız ad uğursuz olur və bu boşluq problemi iki yerə daraldır: müştəri hansı həlledicidən soruşdu və aldığı cavab tuneldən geri qayıda bilirmi. Birini düzəldin, digərini buraxın və nasazlıq sadəcə yerini dəyişir.

Hər hansı profili redaktə etməzdən əvvəl müştərinin adla nə etdiyini təsdiqləyin. Linuxda resolvectl query files.corp.example cavabı hansı keçid və hansı həlledicinin yaratdığını göstərir. Windowsda Resolve-DnsName files.corp.example cavab verən serveri və qaytardığı ünvanı göstərir.

Nəyisə dəyişməzdən əvvəl cavabı oxuyun

Ad bir neçə millisaniyə içində NXDOMAIN kimi qayıdırsa, sorğu heç vaxt sizin zonanıza çatmayıb və yerinə hansısa ictimai və ya otel həlledicisi cavab verib. Uzun fasilədən sonra qayıdırsa, yolda nəsə UDP 53 portunu atır və müştəri sonda ehtiyat varianta keçib. Düzgün ünvanla cavab verir, amma bağlantı yenə ilişib qalırsa, axtarış qaydasındadır və probleminiz marşrutlaşdırma və ya xidmətin özündədir.

Bu üçə bölmə bir saat təxminə qənaət edir. Həm də VPN-ə ümumiyyətlə toxunmaq lazım olub-olmadığını deyir: düzgün şəxsi ünvana həll olunan ad artıq həlledici yolunu sübut edib, deməli qalan iş məlumat yolundadır.

Həlledicini tunelin içindən paylayın

Müştərilər iki qrupa bölünür. Birinə server bağlantı qurularkən həlledici təyin edə bilər; digəri parametri heç bir şlüzün uzaqdan dəyişə bilmədiyi yerli faylda saxlayır.

OpenVPN birinci qrupdadır. Serverdə push "dhcp-option DNS 10.8.0.53" və push "dhcp-option DOMAIN corp.example" idarəetmə kanalı ilə enir, ancaq müştəri konfiqurasiyasında pull hələ də aktivdirsə. Əl ilə düzəldilmiş və pull-filter ignore "dhcp-option" daşıyan müştəri onları heç vaxt görməyəcək və bu tək sətir «server bunu itələyir, amma noutbukum razı deyil» tipli heyrətamiz sayda halı izah edir.

WireGuard ikinci qrupdadır, çünki protokolda ümumiyyətlə seçim danışığı yoxdur. Həlledici və axtarış domeni müştərinin öz [Interface] blokuna DNS = 10.8.0.53, corp.example kimi yazılır. wg-quick bunu resolvconf və ya systemd-resolved vasitəsilə tətbiq edir və Windowsda rəsmi müştəri yalnız tunel qalxanda mövcud olan NRPT qaydaları quraşdırır: Get-DnsClientNrptPolicy onları sadalayır, bu da müştərinin faylınızı heç tətbiq edib-etmədiyini görmək üçün sürətli üsul yaradır.

IPsec/IKEv2 ortadadır. strongSwan-un attr plaqini hovuzdan götürülmüş DNS serveri qaytara bilər və Windows müştərisi buna adətən razılıq verir, ancaq öz ad serverini bərkitmiş profil şlüzün təklif etdiyi hər şeydən üstün olur. Linux müştərisində ekvivalent əl addımı resolvectl dns wg0 10.8.0.53 və ardınca resolvectl domain wg0 '~corp.example'-dur; ikisi də interfeyslə birlikdə yox olur, bu da tunelə bağlı parametr üçün tam istədiyinizdir.

Hər sorğunu udmaq əvəzinə şəkilçini məhdudlaşdırın

Müştərinin bütün həlledici siyahısını daxili serverinizə yönəltmək asandır və çox vaxt səhvdir. Onda hər ictimai ad məlumat mərkəzinizin çıxışından həll olunur, CDN-lər uzaq ünvanlar qaytarır və həlledicinin bir nasazlığı istifadəçinin gəzintisini də özü ilə aparır.

İçəriyə yalnız şəxsi şəkilçini göndərin. systemd-resolved-da ~ ilə başlayan domen yalnız marşrutlaşdırma üçündür, yəni ~corp.example o şəkilçi altındakı sorğuların həmin keçidin serverlərinə getdiyini, qalan hər şeyin isə fiziki şəbəkədən istifadə etməyə davam etdiyini bildirir. Windows eyni işi ad məkanına məhdudlaşdırılmış NRPT qaydaları ilə, macOS isə /etc/resolver/ altında əlavə həlledici faylı ilə görür.

Multicast adları öz cavabına layiqdir. .local adları dizaynına görə link-local-dır (RFC 6762) və nöqtədən nöqtəyə tun interfeysi bu multicast qrupunu daşımır, buna görə əlavə ictimai həlledici onları yayımlamır və daxili unicast həlledicidən onlar barədə soruşanda NXDOMAIN qayıdır. avahi kimi reflektor reflektor rejimində iki seqmenti birləşdirə bilər, ancaq bu, heç bir müştərinin tələb edə bilmədiyi server tərəfli qərardır. Printer və ya NAS adla əlçatan olmalıdırsa, əvəzində zonanızda ona A qeydi verin.

Cavabın geri qayıda bildiyini sübut edin

Əlçatmaz ünvana işarə edən düzgün cavab, marşrutu yoxlamayana qədər tam bir həlledici problemi kimi görünür. Nüvədən soruşun ki, cavab hara gedərdi: ip route get 10.20.5.20 interfeysi və daha faydalısı, istifadə edəcəyi mənbə ünvanını adlandırır.

Həlledicinin ünvanının özünə nəzarət edin. DNS = 10.8.0.53 yanında AllowedIPs = 10.20.0.0/16 olan müştəri sorğularını fiziki NIC-dən çölə göndərir, orada isə onlar səssizcə ölür, çünki həlledici tunelin iddia etdiyi heç bir prefiksin içində deyil. Bu uyğunsuzluq bütün bu sahədə ən çox rast gəlinən tək səbəbli nasazlıqdır və DNS parametrini icazə verilən prefikslərlə sətir-sətir müqayisə etməsəniz görünməz qalır.

Üst-üstə düşən diapazonlar əks nasazlığa səbəb olur. Cavab düzdür, marşrut var və səhv hostu göstərir, çünki evdə 192.168.0.0/24 tunelin həmin diapazona marşrutundan daha dəqiqdir. Bir tərəfi yenidən nömrələyin və ya daha dar marşrut itələyin, sonra xidmət hostunun firewallunu və qayıdış yolunu təsdiqləyin; strongSwan-ın yönləndirmə ilə bağlı qeydləri həmin yolun sysctl tərəfini əhatə edir.

Sertifikatlar insanların DNS-ə yazdığı ayrı bir şəxsiyyət yoxlamasıdır. Brauzer həll xətası əvəzinə ad uyğunsuzluğu bildirirsə, axtarış artıq işləyib və düzəldilməli olan sertifikatdakı SAN-dır. HTTPS-i adla sınayın, heç vaxt çılpaq IP ilə yox.

Şlüzdən deyil, müştəridən yenidən sınayın

İstifadəçinin şikayət etdiyi tətbiqin içində sınayın, çünki əmr sətrindəki axtarış brauzerin eyni yolla getdiyini sübut etmir. Chrome-un təhlükəsiz DNS-i və Firefox-un network.trr.mode parametri sistem həlledicisini tamamilə yan keçə bilər və bunu etdikdə şəxsi ad ya uğursuz olur, ya da ictimai həllediciyə sızır. resolvectl query-i əl ilə işə salınmış dig @10.8.0.53 files.corp.example ilə müqayisə etmək ikisindən hansının baş verdiyini deyir.

Sonra düzəldi deməzdən əvvəl bağlantını kəsin və yenidən qoşun. İnterfeysə əl ilə qoyulmuş parametrlər interfeyslə birlikdə yox olur və yalnız yaddan çıxmış yerli dəyişikliyə görə düzgün görünən profil növbəti açılışda sıradan çıxacaq.

Növbəti maşın üçün qısa yoxlama siyahısı: ad tunelin həlledicisi vasitəsilə həll olunur, şəkilçi qlobal deyil, məhduddur, həlledicinin ünvanı icazə verilən prefikslərin içindədir, cavabdakı host xidmətin portunda cavab verir və sertifikat istifadəçinin yazdığı adı əhatə edir.