İletişim kutusu sunucu adının çözülemediğini söylüyor ve baktığınız profil alanı bir adres. Bu birleşim çelişki değil: istemci, okuduğunu sandığınız değerden başka bir şeyi çözüyor. DNS’in bozuk olduğu sonucuna varmadan önce gerçekte neyi aradığını belirleyin. İstemcinin kendi adımlarının sırası size nereye bakmanız gerektiğini gösterir.

İstemci bağlanmadan önce bir adı çözer

Yerleşik Windows VPN bağlantısı profilini okur, sunucu adresini çözer, tüneli başlatır ve ancak ondan sonra kimlik doğrular. 868 hatası ikinci adıma aittir. Sonraki adımlar hiç çalışmadığı için, arama ilk başta başarısız olduğunda iletişim kutusu kimlik bilgisi sorunu gibi görünebilir.

Bu sıra, incelenecek katmanı daralttığı için yararlıdır. Aynı profil bir ağdan çalışıp başka bir ağdan başarısız olduğunda, fark genellikle tünel türü veya hesap değil ad çözümlemesidir. Aramayı hatanın oluştuğu yerde test edin, profilin oluşturulduğu yerde değil.

Alan bir adres gösterdiğinde hangi ad

Görünen ad yerine saklanan değeri okuyun. Bir bağlantının etiketi onun sunucu adresi değildir ve benzer etiketli iki girdi sizi yanlış olanın peşine takar:

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

Profil tüm kullanıcılar için hazırlandıysa o kapsamı da şununla sorgulayın: -AllUserConnection. Ardından komutun yazdırdığı değeri tam olarak, hatanın oluştuğu ağdan çözün. Operatörün belgelenmiş ağ geçidini kullanın, tünel açıldıktan sonra çözülen dahili uygulama adını değil. O ikinci sorgu beklenen bir nedenle başarısız olur ve arama hakkında size hiçbir şey söylemez:

Resolve-DnsName vpn.example.com

Saklanan değer gerçekten sayısalsa, istemcinin ad okuduğu ikinci yeri arayın. Bir EAP yapılandırması bir sunucuya başvurabilir, başka bir araçtan içe aktarılan profil kendi değerini taşıyabilir ve önceki bir yükleyici yinelenen bir girdi bırakabilir. İletişim kutusundaki alan her zaman tek girdi değildir.

Windows 7 yeniden bağlanma deseni

Bu hatanın arkasındaki başlık, bir kez bağlanıp sonraki bir denemede 868 ile başarısız olan, profilde hiçbir şey değişmeyen makineleri anlatır. Katkıda bulunanlar, Remote Access Connection Manager hizmetini yeniden başlatmanın veya oturumu kapatıp yeniden açmanın bağlantıyı geçici olarak geri getirdiğini bildirdi. Bunlar geçici çözümlerdir, kanıtlanmış bir kök neden değil.

Bu deseni ayrı bir hipotez olarak ele alın. Yeniden başlatma istemci durumunu sıfırlar, bu yüzden sonrasındaki geçici başarı DNS kaydının yanlış olduğunu kanıtlamaz:

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

Tabloyu tanı olarak değil, ayırt edici gözlemler kümesi olarak okuyun. İlk satır ad sorunu, ikincisi istemci durumu, üçüncüsü ise hiç doğru olmamış bir profildir. Her biri farklı bir kişiye ve farklı bir düzeltmeye götürür.

Yönetici için neler toplanmalı

Profil adını, saklanan adresi, tünel türünü, istemcinin bulunduğu ağı ve hatanın bir bağlantı kopmasından sonra gelip gelmediğini yazın. Bu kayıt, kimsenin tahmin etmesine gerek kalmadan gerçek arama hatasını geçmişteki yeniden bağlanma davranışından ayırır. Denemenin çevresindeki istemci olay günlüğünü de saklayın.

Eski sürümlerdeki geçici çözüm, davranışın var olduğunun kanıtıdır; aynı hizmet yeniden başlatmasının güncel bir makineyi onaracağına dair bir söz değildir. Belgelenmiş bir ana makine adını düz bir adresle değiştirmek de onarım değildir.

Bazı profiller yapılandırılmış adla eşleşen bir sunucu kimliği bekler, bu yüzden sayısal geçici çözüm bir hatayı başka bir hatayla değiştirebilir. Ad kalması gerekiyorsa profil metnini değil çözümleme yolunu düzeltin. Her durumda neyi neden değiştirdiğinizi yazın.

İlgili makaleler