Dialoq server adının həll oluna bilmədiyini bildirir, sizin baxdığınız profil sahəsi isə ünvandır. Bu uyğunsuzluq deyil: müştəri sandığınız dəyərdən başqa bir şeyi həll edir. DNS-in pozulduğu qənaətinə gəlməzdən əvvəl onun həqiqətən nəyə qoşulduğunu müəyyənləşdirin. Müştərinin öz addımlarının sırası hara baxmalı olduğunuzu göstərir.

Müştəri qoşulmazdan əvvəl adı həll edir

Windows-un doğma VPN bağlantısı profilini oxuyur, server ünvanını həll edir, tuneli başladır və yalnız bundan sonra autentifikasiya edir. 868 xətası ikinci addıma aiddir. Sonrakı addımlar heç vaxt işləmədiyi üçün axtarış əvvəl uğursuz olduqda dialoq autentifikasiya problemi kimi görünə bilər.

Bu sıra faydalıdır, çünki yoxlanılacaq qatı daraldır. Eyni profil bir şəbəkədən işləyib digərindən uğursuz olduqda fərq adətən tunel növü və ya hesab deyil, ad həllidir. Axtarışı profilin qurulduğu yerdə deyil, nasazlığın baş verdiyi yerdə yoxlayın.

Sahə ünvan göstərdikdə hansı ad

Görünən ad yerinə saxlanılan dəyəri oxuyun. Bağlantının etiketi onun server ünvanı deyil və oxşar etiketli iki giriş sizi səhv birinin arxasınca göndərir:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

Profil bütün istifadəçilər üçün hazırlanıbsa, həmin əhatəni də sorğulayın: -AllUserConnection. Sonra əmrin çap etdiyi dəyəri məhz nasazlığın baş verdiyi şəbəkədən həll edin. Operatorun sənədləşdirilmiş şlüzünü istifadə edin, yalnız tunel qalxdıqdan sonra həll olunan daxili tətbiq adını deyil. Həmin ikinci sorğu gözlənilən səbəbdən uğursuz olur və qoşulma haqqında sizə heç nə demir:

Resolve-DnsName vpn.example.com

Saxlanılan dəyər həqiqətən rəqəmlidirsə, müştərinin ad oxuduğu ikinci yeri axtarın. EAP konfiqurasiyası serverə istinad edə bilər, başqa alətdən idxal edilmiş profil öz dəyərini daşıya bilər və əvvəlki quraşdırıcı təkrar giriş qoya bilər. Dialoqdakı sahə həmişə yeganə giriş deyil.

Windows 7 yenidənqoşulma nümunəsi

Bu xətanın arxasındakı mövzu bir dəfə qoşulub sonrakı cəhddə 868 ilə uğursuz olan, profildə heç nə dəyişməyən maşınları təsvir edir. İştirakçılar Remote Access Connection Manager xidmətini yenidən başlatmağın və ya hesabdan çıxıb yenidən daxil olmağın bağlantını müvəqqəti bərpa etdiyini bildirdilər. Bunlar müvəqqəti həllərdir, sübut edilmiş kök səbəb deyil.

Bu nümunəni ayrı bir fərziyyə kimi qəbul edin. Yenidən başlatma müştəri vəziyyətini sıfırlayır, ona görə sonrakı müvəqqəti uğur DNS qeydinin səhv olduğunu sübut etmir:

ObservationPoints towardWhat to do next
Fails from one network, works from anotherName resolution on that pathResolve the stored name from both networks
Fails after a disconnect, works after service restartClient state, not DNSRecord the sequence for the vendor
Fails only on a newly provisioned machineProfile content or scopeCompare ServerAddress and TunnelType

Cədvəli diaqnoz kimi deyil, fərqləndirici müşahidələr toplusu kimi oxuyun. Birinci sətir ad problemidir, ikincisi müştəri vəziyyətidir, üçüncüsü heç vaxt düzgün olmamış profildir. Hər biri başqa adama və başqa düzəlişə aparır.

Administrator üçün nə toplamaq lazımdır

Profilin adını, saxlanılan ünvanı, tunel növünü, müştərinin olduğu şəbəkəni və nasazlığın kəsilmədən sonra baş verib-vermədiyini yazın. Bu qeyd heç kimin təxmin etməsinə ehtiyac olmadan həqiqi axtarış nasazlığını tarixi yenidənqoşulma davranışından ayırır. Cəhd ətrafındaki müştəri hadisə jurnalını da saxlayın.

Köhnə buraxılışlardakı müvəqqəti həll davranışın mövcud olduğuna dəlildir, eyni xidmət yenidən başlatmasının cari maşını düzəldəcəyinə zəmanət deyil. Sənədləşdirilmiş host adını hərfi ünvanla əvəz etmək də təmir deyil.

Bəzi profillər konfiqurasiya edilmiş ada uyğun server kimliyi gözləyir, ona görə rəqəmli müvəqqəti həll bir xətanı başqası ilə dəyişə bilər. Ad qalmalıdırsa, profil mətnini deyil, həll yolunu düzəldin. Hər halda nəyi və niyə dəyişdiyinizi qeyd edin.

Əlaqəli məqalələr