OpenVPN DNS göndərdikdən sonra yerli Samba paylaşımı itdi

Samba yerli paylaşımları OpenVPN qoşulanda itirir, və tunel demək olar ki heç vaxt səbəb deyil. Mount qaydasındadır, NAS işləyir və tunelin quraşdırdığı həlledici heç vaxt görmədiyi bir ad haqqında suallara cavab verir. Samba bu həllediciyə axtarış sırasının əvvəlində müraciət edir, cavaba inanır və heç nəyin dinləmədiyi ünvana qoşulur. Paylaşımı düzəltmək, mount-u deyil, cavabı düzəltmək deməkdir.

Hər addımda ən çox ehtimalı aradan qaldıran sıra ilə beş yoxlama.

Qısa ad üçün kim cavab verir

Fayl menecerindən deyil, əməliyyat sistemindən soruşun. resolvectl status hər keçidə bağlı DNS serverlərini göstərir və hansı keçidin standart marşrut olduğunu işarələyir, qısa ad üçün sorğu isə cavab verən serveri bildirir. Onu bir dəfə NAS adı üçün, bir dəfə də ofis domenində olduğunu bildiyiniz bir ad üçün işə salın. İki cavab fərqli serverlərdən gəlirsə, bölünməni tapmısınız.

Cavabın mənfi cavab, yoxsa ünvan olduğunu yoxlayın. Mənfi cavab Samba-nın başqa mexanizmə keçməli olduğunu bildirir və nasazlıq başqa yerdədir. Ünvan isə Samba-nın həqiqi bir yerə qoşulduğunu və heç nə almadığını bildirir.

Samba niyə səhv cavaba inanır

Samba adları name resolve order ilə təyin olunan sabit ardıcıllıqla həll edir. Əksər paylamalarda standart olaraq host var, yəni DNS, və o, NetBIOS yayımı kimi yalnız yerli şəbəkə mexanizmlərindən əvvəl işləyir. Buna görə həlledici göndərən tunel hər paylaşım adı üzərində ilk imtina hüququ alır, o cümlədən binadan heç vaxt çıxmamalı olan tək etiketli adlar üzərində.

Adətən bilinməyən ad mənfi cavab qaytarır və növbəti mexanizm növbə alır. Bəzi həlledicilər, xüsusən provayder və ictimai olanlar, bilinməyən adlara axtarış səhifəsi və ya reklam ünvanı ilə cavab verir. Bu cavab həlledici kitabxanası üçün uğur kimi görünür, ona görə Samba axtarışı dayandırır və şəbəkənizlə heç bir əlaqəsi olmayan ünvana zəng edir.

Nəticə xəta dialoqu olmadan yoxa çıxan paylaşımdır. Bu ardıcıllıqda heç nə VPN marşrutlaşdırma nasazlığı deyil, buna görə NAS-ı ping etmək hələ də işləyir, ona baxmaq isə işləmir.

Fərqli əhatəli iki təmir

Dar təmir göndərilən həlledicini saxlayır və Samba-nın ona nə soruşmasına icazə verildiyini dəyişir. Demonun həqiqətən oxuduğu Samba konfiqurasiyasına iki sətir əlavə edin, sonra xidməti yenidən başladın:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

Bu siyahıda host olmadıqda DNS paylaşım axtarışlarının yolundan çıxır və tək etiketli adlar yerli seqmentdə qalır. Ofis adları hər başqa proqram üçün normal həll olunur, çünki bu yalnız Samba-nı dəyişir. Qiyməti odur ki, Samba artıq DNS-dən ümumiyyətlə istifadə edə bilməz, ona görə tam kvalifikasiyalı ofis adı ilə ünvanlanan paylaşım problemə çevrilir.

Geniş təmir səbəbi aradan qaldırır: sahibi olmadığı adlara cavab verən həlledici göndərməyi dayandırın və ya yalnız ofis şəkilçilərinin ofis həlledicisinə çatdığı bölünmüş DNS siyasəti göndərin. Bu, idarə olunan şəbəkədə daha yaxşı uzunmüddətli cavabdır, çünki brauzeri və paket menecerini də qoruyur, amma server tərəfinə inzibati giriş və göndərilən parametrlərə tabe olan müştəri.

Birini qəsdən seçin. Həlledici dəyişikliyi bütün tətbiqlər üçün ad həllini eyni anda dəyişir, bu isə dəyişiklik qeydidir, dəstək zəngi üçün redaktə deyil.

Şəkilçi hər şeyi izah edə bilər

Müştəri həm də axtarış şəkilçisi göndərirsə, qısa yerli ad sorğulanmadan əvvəl ofis domeninə yenidən yazılır. Onda həlledici heç yalan danışmır: ondan ofis adı haqqında ədalətli sual soruşulub və düzgün cavab verib. Bunu reklam ünvanı halından ayırmaq üçün həlledici çıxışında sorğulanan adı oxuyun, çünki iki nasazlıq fayl menecerində eyni görünür.

Buradakı həll ya tam kvalifikasiyalı yerli addan istifadə etmək, ya da yerli şəkilçiyə sahib olan bölünmüş DNS qaydası əlavə etməkdir. Heç biri Samba-ya toxunmağı tələb etmir.

Yenidən qoşulmadan sonra bunu sübut edin

Bir sessiyada üç adı yoxlayın: yerli paylaşımı qısa adla, ofis hostunu adla və adi vebsaytı. Birinci işləyib ikinci pozulursa, təmir nasazlığı aradan qaldırmaq əvəzinə yerini dəyişib. Üçüncü pozulursa, həlledici dəyişikliyi nəzərdə tutulandan uzağa gedib və hər axtarış artıq şübhəlidir.

Sonra tuneli ayırın və yenidən qoşun, üçünü də təkrarlayın. Göndərilən parametrlər hər qoşulmada yenidən tətbiq olunur, ona görə yalnız işləmə vaxtında mövcud olan düzəliş konfiqurasiya faylı dəyişmədən yoxa çıxa bilər. Hər şəkilçiyə sahib həlledicini və qüvvədə olan axtarış sırasını qeyd edin, tarixi də yazın, çünki bu qayıdanda növbəti müştəri yeniləməsi açıq şübhəlidir.

Paylaşım bütün beş yoxlamadan sonra hələ də uğursuz olursa, başqa heç nəyi dəyişməzdən əvvəl dəqiq sorğunu və dəqiq cavabı yazın. Bu iki sətir həlledici nasazlığını həqiqətən mövcud olmayan addan ayırır və yaza biləcəyiniz ən sürətli təhvil qeydidir.