VPN DNS-i ələ keçirdi və yerli adları sındırdı: siyahını düzəldin

Tunel qalxır, intranet yüklənir, və printerin adı həll olunmaqdan qalır. Ya da əksi: yerli adlar işləməyə davam edir, halbuki korporativ şəbəkənin içində hər şey vaxt aşımına uğrayır. Hər iki simptom eyni yerdən gəlir: VPN müştərisinin qoşularkən yenidən yazdığı həlledici siyahısından.

Siyahını qəsdən bərpa edin, sonra təkan mexanizmini ayrıca həll edin. Marşrutlar üçüncü mövzudur və burada düzəldilən deyil.

Tətbiqlər əslində hansı siyahıdan istifadə edir

Windows hər hansı dialoqun göstərdiyindən deyil, interfeys səviyyəsindəki parametrlərdən həll edir, ona görə hər interfeys üzrə effektiv siyahılardan başlayın. Alias göstərilən addan daha vacibdir, çünki aşağıdakı hər əmr bir interfeysə müraciət edir. Aliası səhv tutsanız, bərpa yanlış adapterə düşəcək. Növbəti yenidən qoşulmaya qədər işləyirmiş kimi görünəcək, o zaman tunelin öz girişi qayıdır.

Sual odur ki, hansı serverlər önə keçdi və onlar statik girişlər kimi, yoxsa DHCP icarəsi kimi gəldi. Hər iki fakt hansı bərpanın sizin üçün mövcud olduğunu müəyyən edir.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Tunel adapteri və fiziki adapter üçün çıxışı oxuyun və hər birindəki bütün ünvanları qeyd edin. Statik giriş siyasət və ya skriptlə silinə bilər; DHCP ilə verilən giriş icarəyə bağlıdır və qayıdacaq, bu da seçməli olduğunuz bərpanı dəyişir. Uzaq şəbəkədəki adlar elan olunan həlledicidən, yerli LAN-dakı adlar fiziki adapterdən həll olunur və sorğu ilk baxılan siyahıya gedir.

İtilən serverləri silin və ya onları daha aşağı sıralayın

Tunelin içində heç nə onlara ehtiyac duymursa, itilən serverləri silin, çünki fiziki adapterin öz həllediciləri yenidən işə düşür. Onları yalnız uzaq şəbəkənin yalnız öz serverlərinin cavab verə bildiyi zonaları varsa saxlayın və bu halda onların qarşısına yerli həlledici qoyun. Aşağıdakı iki əmr hər iki seçimi əhatə edir, ona görə ikisini də işə salmaq əvəzinə vəziyyətə uyğun olanı seçin.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

1-ci indeksə ilk baxılır, yəni itilən ünvanlar əlçatan qalır, lakin hər sorğu üçün susmaya görə cavab olmaqdan çıxır. validate=no bayrağı tunel hələ oturuşarkən tez-tez uğursuz olan əlçatanlıq yoxlamasını atlayır, ona görə çıxış koduna güvənmək əvəzinə nəticəni show əmri ilə təsdiqləyin.

Buna güvənməzdən əvvəl bilməyə dəyər iki məhdudiyyət var. Windows DHCP ilə netsh vasitəsilə gələn serverləri silməyəcək və həmin dəyərlər interfeysin qeyd açarı altında DhcpNameServer kimi qalır, ona görə qeyd redaktəsi son çarədir və növbəti icarədən sonra yenidən yoxlanmalıdır. Adapter bağlama sırası da etibarlı sıralama mexanizmi deyil, çünki VPN müştərisi öz girişini siyahının başına yerləşdirə bilər.

Təkan harada süzülə bilər

Daha yaxşı bərpa seçimi tətbiq olunmadan əvvəl aradan qaldırır. Community OpenVPN müştərisi itilən direktivi adla süzə bilir, bu da serverin konfiqurasiyasını toxunulmaz saxlayır.

pull-filter ignore "dhcp-option DNS "

Sondakı boşluq uyğunluğa aiddir və süzgəc server ünvanını deyil, seçimi adlandırır. Profildə həmçinin block-outside-dns direktivi varsa, onun silinməsi ad həllini deyil, sızma müdafiəsini dəyişir, ona görə iki düzəlişi birləşdirmək əvəzinə bunu ayrıca qərarlaşdırın.

Tək inadkar host adı üçün Windows hosts faylındakı bir sətir bütün maşın üçün həllediciləri yenidən sıralamaqdan daha sabitdir. O, növbəti şəxs üçün də görünməzdir, ona görə maşının konfiqurasiyası harada sənədləşdirilibsə, orada qeyd edin.

Bərpanı yenidən qoşulmaya davamlı edin

Ad həlli iki dəfə yoxlanmalıdır, bir dəfə seçilmiş serverə qarşı, bir dəfə də tətbiqin istifadə etdiyi formada. Bu cüt həlledici sırası problemini heç cavab verməyən serverdən ayırır. Birinci yoxlamanı atlamaq iki səbəbi bir-birinə qarışdırır.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Tuneli yenidən qoşun və hər iki əmri təkrarlayın. Əl ilə dəyişdiyiniz hər şey yalnız növbəti bağlantıya qədər qalır, çünki müştəri adapteri qaldırarkən həlledici vəziyyətini yenidən qurur. netsh sətirlərini müştəriniz üçün dəstəklənən qoşulma skriptinə qoyun, o skriptin uğurla bitməsinə icazə verin və o işə düşməzdən əvvəl qısa gözləmə əlavə edin. Skriptdən sonra DNS tətbiq edən müştəri nəticəni hər halda üzərinə yazacaq.

Bərpadan sonra ictimai adlar həll olunur, daxili adlar isə hələ də uğursuz olursa, həlledici siyahısı artıq şübhəli deyil. Sorğu çox güman ki, serverə heç çatmır, bu da başqa bir DNS parametrinə deyil, marşruta və ya firewall qaydasına işarə edir. İnterfeys aliasını və üzərində dayandığınız ünvanları qeyd edin, çünki hər ikisi maşınlar arasında fərqlənir və heç biri yenidənqurmadan təkbaşına keçmir.