Niyə server adı telefonla qoşulmadan sonra VPN ünvanına çevrilir

Ofis fayl serveri bütün səhər LAN ünvanı ilə cavab verir, sonra uzaq istifadəçi telefonla qoşulur və ad birdən tunel ünvanına çevrilməyə başlayır. DNS-də heç nə əl ilə dəyişdirilməyib və bu, ipucudur: qeydi maşının özü yayımlayıb. Üç şərt qeydiyyatçını, qeydi və ya müştərinin görünüşünü düzəltməyinizi müəyyən edir və sıranı səhv etsəniz qeyd növbəti bağlantıdan sonra geri qayıdır.

İki ünvan, bir ad, üç şərt

Çoxinterfeysli Windows serveri LAN ünvanı, bir və ya bir neçə telefonla qoşulma ünvanı və bəzən ikinci şəbəkə kartı saxlaya bilər. Hər interfeys dinamik qeydiyyata icazə verilirsə öz ünvanlarını DNS-də qeyd edə bilər. PPP adapteri qeydiyyatdan keçəndə eyni host adı yalnız tunel tərəfdaşının çata bildiyi ünvan qazanır və LAN müştəriləri onu etibarlı cavab kimi alır.

Üç şərt təmiri müəyyən edir. Birincisi, əlavə ünvan onu alan müştərilərdən əlçatandırmı? İkincisi, hər hansı istehlakçı hələ də həmin qeydiyyatdan asılıdır? Üçüncüsü, qeyd dinamikdir və buna görə geri qayıda bilərmi, yoxsa statikdir və buna görə qəsdən edilmiş girişdir?

Bir şeyə toxunmazdan əvvəl bunlara cavab verin. Ünvan sorğu göndərən şəbəkədən əlçatan deyilsə, müştəri keşinin təmizlənməsi problemi uzun müddət həll etmir. Bir şey ondan asılıdırsa, məsələn tunel tərəfdaşlarının özlərinin istifadə etdiyi idarəetmə yolu, onu silmək həmin yolu pozur. Və yayımlayıcısına toxunmadan silinən dinamik qeyd növbəti qeydiyyat hadisəsində yenidən görünəcək.

Qeydiyyatçını dəyişməzdən əvvəl qeydi oxuyun

Problemi bildirən şəbəkədən dəqiq tam kvalifikasiyalı adı sorğulayın və cavabları serverin faktiki interfeysləri və dinləyiciləri ilə müqayisə edin. Bir adın bir neçə ünvan qaytarması normaldır; sual budur ki, onların hər biri onu alan müştəri üçün istifadə oluna biləndirmi.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

Birinci sorğu yerli həlledicidən istifadə edir, ikincisi müəyyən DNS serverinə birbaşa müraciət edir, üçüncüsü isə Windows-da PowerShell-dən eyni şeyi edir. Onları müqayisə etmək köhnəlmiş müştəri keşini səlahiyyətli cavabdan ayırır. Birbaşa sorğu artıq tunel ünvanını qaytarırsa, problem yerli keşdə deyil, yayımlanmış məlumatdadır.

Qeydin vaxt ştampını və DNS konsolunun onu dinamik göstərib-göstərmədiyini yazın. Bu tək xüsusiyyət yuxarıdakı üç şərtdən hansının tətbiq olunduğunu bildirir və bu, beş dəqiqəlik təmizləmə ilə davamlı təmir arasındakı fərqdir.

Yayımlayıcını düzəldin və ya qeydi düzəldin, amma hansını etdiyinizi bilin

Qeyd dinamikdirsə və arzuolunmazdırsa, davamlı həll həmin interfeysin qeydiyyatdan keçməsini dayandırmaqdır. Windows hər interfeys üçün qeydiyyat parametrləri təqdim edir və DNS müştəri xidməti növbəti bağlantıda və ya ünvan dəyişikliyində yenidən yayımlayır. Telefonla qoşulma adapteri üçün qeydiyyatı söndürmək LAN adapterinin qeydiyyatını toxunulmaz saxlayır və bu, adətən istədiyinizdir.

Bütün maşına aid açarlarla diqqətli olun. Dinamik yeniləməni söndürən qlobal parametr həmin hostdakı hər interfeysə təsir edir, o cümlədən digər müştərilərin qeydiyyatına güvəndiyi interfeysə. Domen nəzarətçisində eyni ehtiyat daha güclü tətbiq olunur, çünki host müştərilərin daxil olma üçün asılı olduğu xidmət yeri qeydlərinə də sahib ola bilər.

Qeyd statikdirsə, o, qəsdən oraya yerləşdirilib və söhbət onu yerləşdirənlədir. Statik qeydi bu gün əlverişsiz olduğu üçün silmək onun niyə mövcud olduğunun yeganə sübutunu aradan qaldırır. Hər iki halda köhnəlmiş cavabı yalnız yayımlayıcı ilə iş bitdikdən sonra silin və nəyi dəyişdiyinizi qeyd edin ki, növbəti şəxs qəsdən edilmiş girişi təsadüfdən ayıra bilsin.

Uğursuz olan müştəri şəbəkəsindən yoxlayın

Yoxlama simptomu bildirən şəbəkədə aparılmalıdır, serverdə deyil. Müştəri həlledicisinin keşini dəstəklənən mexanizmlə təmizləyin, sonra ilkin axtarışı və ilkin xidmət bağlantısını adla təkrarlayın.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

Birinci əmr Windows həlledici keşini təmizləyir, ikincisi adın yenidən keşlənib-keşlənmədiyini və hansı ünvanın saxlandığını göstərir. Serverin özünə uğurlu qoşulması LAN müştərisi haqqında heç nə sübut etmir və arzuolunmaz ünvana gedən marşrutun silinməsi DNS-in yayımladığını düzəltmir.

Nəhayət, ünvanı əvvəl gətirən hadisəni təkrarlayın: VPN müştərini yenidən qoşun və ya telefonla qoşulma sessiyasını yeniləyin. Həmin həyat dövrü dəyişikliyindən sonra yayımlanmış adı yenidən yoxlayın. Yalnız növbəti bağlantıya qədər davam edən təmir təmizləmə idi, təmir deyil və hansını etdiyinizi bilmək bileti bağlamaqla onu gələn həftə yenidən açmaq arasındakı fərqdir.