LAN host adı VPN üzərindən işləmir: şəkilçi, mDNS yoxsa zona?

Cihazın yanında printer qısa ada, fayl serveri isə ləqəbə cavab verir. Tunelin içindən hər iki ad vaxt aşımına uğrayır, halbuki onların ünvanları hələ də işləyir. Marşrut öz işini görür; o qısa adları işlək edən adlandırma yolu heç vaxt tuneldən keçməyib. Bu davranışı üç mexanizm yaradır və hər biri fərqli düzəliş tələb edir.

Adın hansı mexanizmdən asılı olduğunu müəyyən etməklə başlayın.

Fərqli davranan üç növ ad

fileserver kimi tək etiketli ad adətən resolverin əlavə etdiyi DNS axtarış şəkilçisinə dayanır. Bu şəkilçi çox vaxt yerli DHCP icarəsi ilə gəlir, ona görə VPN-dən ünvan alan uzaq müştərinin onu bilməsinə heç bir səbəb yoxdur. Marşrut əlavə etmək şəkilçini çatdırmır. Qısa ad sadəcə ad kimi mövcud olmaqdan çıxır, baxmayaraq ki, arxasındakı ünvan əlçatandır.

.local ilə bitən ad adətən yerli keçiddə multicast DNS ilə həll olunur, RFC 6762-nin təsvir etdiyi kimi. Multicast, kimsə onu qəsdən körpüləmədikcə və ya proksiləmədikcə marşrutlaşdırılmış tuneldən keçmir, ona görə seqmentdən çıxdığınız anda ad həll olunmaqdan qalır.

Tam kvalifikasiyalı şirkət adı təşkilatın resolverləri tərəfindən xidmət edilən daxili zonaya aiddir. O ad VPN həmin resolverləri göndərdikdə və müştəri onlardan istifadə etmək üçün konfiqurasiya edildikdə uzaqdan işləyir. Və localhost RFC 6761-ə görə xüsusi istifadəlidir: qarşınızdakı maşına işarə edir, heç vaxt uzaq xidmətə yox.

Marşrutu dəyişməzdən əvvəl resolveri oxuyun

Hansı ad serverinin cavab verdiyini və hansı şəkilçinin əlavə olunduğunu soruşun. Eyni sorğu fərqli resolverlər vasitəsilə fərqli cavablar verir və bu fərq sizə lazım olan sübutdur.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Əgər tam kvalifikasiyalı sorğu həll olunursa, qısa olan isə yoxsa, problem serverdə deyil, şəkilçidədir. Əgər heç biri həll olunmursa və ünvan işləyirsə, müştəri daxili resolverdən ümumiyyətlə istifadə etmir. Resolver siyahısını VPN-in göndərməli olduğu ilə müqayisə edin, çünki hər sorğu üçün yerli resolverini saxlayan müştəri daxili zonanı heç vaxt görməyəcək.

Düzgün adı müştəriyə gətirin

İnzibatçıdan sənədləşdirilmiş uzaq giriş adını tam şəkildə istəyin və şəkilçiləri təxmin etmək əvəzinə profildə ondan istifadə edin. Əgər yerləşdirmə split DNS-i dəstəkləyirsə, daxili domeni daxili serverlər tərəfindən həll olunmaq üçün konfiqurasiya edin, qalan hər şey isə yerli resolveri saxlasın. Axtarış domenini müştərinin dəstəklədiyi yerdə VPN konfiqurasiyası vasitəsilə göndərin.

Nəticəni şlüzda deyil, müştəridə yoxlayın. Serverdə tətbiq olunan və müştəriyə heç vaxt çatmayan parametr heç nəyi dəyişmir.

Sertifikat şəxsiyyətini toxunulmaz saxlayın

Sertifikat xətasına məhəl qoymayan ünvana əsaslanan test yalnız soketin açıldığını sübut edir. Xidmət sertifikatı bir ad üçün verilir və müştəri uyğunsuzluğu haqlı səbəblə rədd etməyə davam edəcək. Əgər sertifikat yalnız daxili adı sadalayırsa, o addan istifadə edin və həlli düzəldin, ya da istifadə etmək istədiyiniz ünvanı əhatə edən sertifikat alın.

Uğurlu bağlantı yaradan adı, resolveri və şəkilçini qeyd edin. Bu qeyd növbəti şəxsi real problemi gizlədən ünvana əsaslanan müvəqqəti həlli təkrarlamaqdan xilas edir.