OpenVPN DNS göndərir, amma DNS həlledicisi onu görməyə bilər

Müştəri jurnalı göndərilən DNS serverini göstərir, tunel qoşulub, daxili ad isə hələ də heç nəyə çevrilmir. Göndərmənin özündə heç nə pozulmayıb. Seçim gəlib, lakin əməliyyat sisteminin həlledicisi ondan heç vaxt istifadə etməyib, çünki əksər Unix müştərilərində OpenVPN dəyəri verir və tətbiqi platformaya buraxır.

Simptom: jurnal DNS göstərir, adlar isə hələ də uğursuz olur

OpenVPN dhcp-option DNS və domen məlumatını daşıyır, müştəri isə aldığını qeyd edir. Bəzi tətbiqlərdə müştəri bu parametrləri daxildə tətbiq edir; digərlərində isə onları inteqrasiya skripti və ya şəbəkə xidməti istehlak etsin deyə ixrac edir. Jurnal sətri hekayənin yalnız birinci yarısını təsvir edir. İkinci yarı müştərinin nəzarət etmədiyi yerdə baş verir. Uğursuzluq adətən orada yaşayır.

Buna görə qoşulmuş tunel və uğursuz daxili ad bu qədər tez-tez birgə mövcud olur. Dəyər var, istehlakçı yoxdur və ya səhv konfiqurasiya edilib, həlledici isə sakitcə qoşulmadan əvvəl istifadə etdiyi ictimai serverdən istifadə etməyə davam edir.

Alınma tətbiq demək deyil

Müştəri göndərilən DNS dəyərini jurnala yaza bilər, sistem həlledicisi isə başqa xidmətə məxsus qalır. Brauzerin sistem həlledicisini tamamilə yan keçən öz şifrəli DNS siyasəti də ola bilər və bu, bir tətbiqin daxili adları həll etdiyi, digərinin etmədiyi yadda qalan vəziyyəti yaradır.

Hər Unix müştərisinin eyni faylı yenidən yazdığını güman etmək əvəzinə tətbiqin dəstəklənən inteqrasiyasını yoxlayın. Bu güman insanların heç nəyin oxumadığı həlledici konfiqurasiyasını redaktə etməsinin səbəbidir.

Hər platformada həlledicinin sahibini tapın

Windows-da ad həlli siyasəti cədvəli müəyyən şəkilçiləri müəyyən serverlərə yönəldə bilər və VPN müştərisi orada qaydalar quraşdıra bilər. Yalnız adapterin DNS siyahısını deyil, siyasəti yoxlayın. Linux-da konfiqurasiyaya NetworkManager və ya systemd-resolved sahib ola bilər və hansının sahib olması yenidən qoşulmanın nəyi saxlayacağını müəyyən edir.

Effektiv vəziyyəti sorğulara həqiqətən cavab verən alətlə oxuyun: systemd-resolved hostunda resolvectl query internal.example.net və ya platformanın ekvivalenti. Sonra bu cavabı müştəri jurnalının göndərdiyini iddia etdiyi DNS serveri ilə müqayisə edin.

Həlledici parametrlərini əlaqələndirmədən üzərinə yazan bir neçə xidməti işə salmaqdan çəkinin. İki sahib aralıqlı görünən nəticə yaradır və hər yenidən qoşulma onu təsadüfi olaraq düzəldir və ya pozur kimi görünür.

Skriptlər və foreign_option

OpenVPN göndərilən seçimləri foreign_option_N adlı dəyişənlər vasitəsilə skriptlərə ixrac edir və skript onları həlledici əmrlərinə çevirə bilər. Bu quruluş dəstəklənən inteqrasiyadır, avtomatik davranış deyil, və müştəridə quraşdırılıb çağırılmalıdır.

Skriptə güvənirsinizsə, onun icrasını və çıxış statusunu jurnala yazın. İşləyən, lakin səssizcə uğursuz olan skript heç skript olmaması ilə eyni simptomu buraxır və konfiqurasiya tam göründüyü üçün fərq etmək daha çətindir. Skript faylını deyil, skriptin çıxışını yoxlayın. Mövcud olan fayl işləmiş skript deyil.

Jurnalı deyil, adı sınayın

Qoşulduqdan sonra müştəridən yalnız daxili host adını sorğulayın, sonra ictimai adı sorğulayın, sonra hansı serverin cavab verdiyini yoxlayın. İşləyən qurmada iki cavab fərqli yerlərdən gəlir və hər ikisi dizayna uyğun olmalıdır.

Ad həll olunursa, lakin xidmət uğursuz olursa, DNS-i yenidən dəyişmək əvəzinə marşrutlaşdırma və tətbiq girişinə keçin. OpenVPN təlimatı dhcp-option və skript mühitini sənədləşdirir; başqa həlledici faylını redaktə etməzdən əvvəl müştərinizin nəyi tətbiq etməsi gözlənildiyini təsdiqləmək üçün ondan istifadə edin.