VPN host adları uğursuz olur, IP ünvanları işləyir: hara baxmalı

Paylaşımı ünvanla aça bilirsiniz, eyni paylaşım adla uğursuz olur, bu da tunelin paket daşıdığını və adlar qatının daşımadığını göstərir. Bu tək müşahidə firewall və marşrut dəyişiklikləri ilə əlaqədar bir dövrə vurmağa ehtiyac qoymur. Adlar şəkilçiyə, resolverə və sorğu üçün yola ehtiyac duyur, VPN müştərisi isə heç birini quraşdırmadan marşrut quraşdıra bilər. Aşağıdakı dörd yoxlamanı sıra ilə gedin və pozulan ilk birində dayanın.

Ad ünvanın vermədiyi sualı verir

Ünvan yığının dərhal istifadə edə biləcəyi hədəfdir. Qısa ad şəkilçi ilə genişləndirilməli, resolverə göndərilməli və zonası bilən bir şey tərəfindən cavablandırılmalı sualdır. Marşrutları quraşdıran amma resolveri olmayan tunel birincini işlək, ikincini sınıq qoyur. Buna görə simptom çox fərqli VPN məhsullarında bu qədər ardıcıl görünür.

Ünvandan xaricə doğru işləyin: əvvəlcə tam ad, sonra çılpaq host adı, və üçündən hansının işlədiyini qeyd edin. Naxış bir konfiqurasiya ekranı açmadan hansı qatı yoxlamaq lazım olduğunu sizə deyir. Tam ad həll olunanda marşrutlar haqqında təxmin yürütmək boşa səydir.

Tunelin həqiqətən quraşdırdığı resolveri oxuyun

Əməliyyat sistemindən daxili zona üçün sorğuları hansı resolverin idarə etdiyini soruşun, VPN müştərisinin interfeysinin elan etdiyini deyil. Daxili zonası olmayan açıq resolveri göndərən server məhz bu uğursuzluğu yaradır və bu, marşrut xətası deyil, konfiqurasiya xətasıdır.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Domenə qoşulmuş Windows müştərisində adlar sahəsinin marşrut siyasəti hansı sorğunun hansı resolverə getdiyini müəyyən edir və VPN adapterinin öz DNS parametrləri adapter təfərrüatlarında görünür. Profili deyil, qüvvədə olan siyasəti oxuyun, çünki keşlənmiş siyasət onu quraşdıran bağlantıdan daha uzun yaşaya bilər. Resolver tam adı cavablandırır və qısa adı cavablandırmırsa, problem artıq şəkilçi siyahısına keçib.

Get-DnsClientNrptPolicy
ipconfig /all

Daxili zona düzgün server vasitəsilə həll olunursa, dayanın. Resolver sizin probleminiz deyil.

Şəkilçilər uğursuz olan qısa adları izah edir

Tək etiketli ad sorğu göndərilməzdən əvvəl bağlantının şəkilçi siyahısı ilə genişləndirilir. VPN daxili şəkilçini çatdırmırsa, fileserver heç vaxt fileserver.corp.example olmur və sorğu heç bir açıq resolverin tanımadığı ad kimi çıxır. Şəkilçini göndərmək və ya tam adı yazmaq serverdə heç nəyi dəyişmədən fərziyyəni yoxlayır.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Linuxda resolver xidməti DNS serverini bir linkə və marşrut domenləri dəstinə bağlayır, beləliklə tunelin linki ilə əlaqələndirilməyən göndərilmiş server sanki orada deyil kimi davranır. Yalnız lokal resolverə işarə edə bilən stub faylı deyil, link üzrə statusu yoxlayın. Eyni bölünmə əks istiqamətdə də görünür: mövcud olan amma tunel interfeysinə tətbiq edilməyən axtarış domeni təsadüfi görünən qısa ad uğursuzluqları yaradır.

Şəkilçinin əlavə edilməsi bunu düzəldirsə, qalan iş hər istifadəçidən onu yazmağı xahiş etmək əvəzinə həmin şəkilçini VPN profili vasitəsilə çatdırmaqdır.

NetBIOS və WINS fərqli mexanizmdir

Köhnə SMB hələ də çılpaq adı NetBIOS ad xidməti ilə axtara bilər, o, yayım üzərindən və ya WINS serveri vasitəsilə cavab verir. Yayım bir yayım domeninin içində qalır və ilk marşrutlaşdırıcıda dayanır, buna görə tunelin o tərəfinə keçə bilməz; WINS işləyir, çünki müştərinin qeydiyyatdan keçəcəyi və sorğu göndərəcəyi unikast ünvanı var. Buna görə yalnız IP daşıyan VPN, WINS konfiqurasiya edilib əlçatan olduqda köhnə adları dəstəkləyə bilər.

nbtstat -n
nbtstat -R

Müasir SMB üçün DNS və tam ada güvənin və köhnə yolu təqaüdə çıxarın. Əgər həqiqətən köhnədirsə, WINS təmin edin və ya tətbiqi dəyişdirin; orta yol heç vaxt boşalmayan bir dəstək növbəsidir.

Gəzinti hansı qatın uğursuz olduğunu deyə bildiyiniz zaman bitir: resolver, şəkilçi və ya köhnə kəşf. Cavab verən resolveri və işləyən ad formasını qeyd edin, çünki növbəti şəxs eyni simptomdan başlayacaq.