Windows VPN hatası 720: adres havuzu mu, istemci bağlaması mı?
Hata 720, bağlantıya hiçbir zaman kullanılabilir bir adres verilmediği anlamına gelir. Bağdaştırıcıyı yeniden yüklemeden önce tek ana bilgisayardaki hataları çok sayıda ana bilgisayardaki hatalardan ayırın.
Hata 720, kimlik bilgileri kabul edildikten sonra görünür ve bu yüzden insanları parola alanına geri gönderir. Bağlantı, bir adresin pazarlığa açıldığı noktaya ulaştı ve bir tane alamadı. İki çok farklı arıza aynı iletişim penceresini üretir: sunucunun dağıtacak bir şeyi yoktu ya da tam olarak bu istemci pazarlığı tamamlayamadı. Bu ikisini herhangi bir şeye dokunmadan ayırmak onarımın büyük kısmıdır ve ayrım Microsoft'un hata 720 sorun giderme sayfasında belgelenmiştir.
İletişim penceresinin söylemediği
İleti, PPP pazarlığındaki bir arızayı anlatır ve kasıtlı olarak belirsizdir çünkü istemci sunucunun neden reddettiğini göremez. Bu bir kimlik bilgisi hatası değildir ve tünelin şifrelemesine dair bir ifade de değildir. Adresin veya pazarlık parametrelerinin teslim edilmediği anlamına gelir.
Sunucu tarafında olağan neden atamadır: boş adresi olmayan statik bir RRAS havuzu veya kapsamı tükenmiş ya da erişilemez bir DHCP yapılandırması, deneyen her istemcide tam olarak bu belirtiyi üretir. İstemci tarafında olağan neden bir bağlamadır. PPP taşıyan WAN Miniport doğru bileşenlere bağlanmalıdır ve devre dışı bir bağlama veya eklenmiş bir ağ filtresi, görünür bir aygıt sorunu olmadan pazarlığı durdurabilir. İki aile farklı kanıtlara ihtiyaç duyar ve aralarında seçim yapmanın en hızlı yolu kaç istemcinin etkilendiğini saymaktır.
Önce topluluğu, sonra havuzu ayırın
Herhangi bir yapılandırmayı okumadan önce etkilenen istemcileri sayın. Aynı anda herkesi vuran bir arıza sunucu durumu, makineler arasında tek bir makineyi izleyen bir arıza istemci durumudur. Bu sayım bir sohbet kanalında tek mesaja mal olur ve bir öğleden sonrayı kurtarır.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
Ardından başarısız bir denemeyi sunucunun kendi kaydıyla ilişkilendirin, çünkü RRAS atama yapamadığında bir olay kaydeder ve o olay belirtiyi değil arızayı adlandırır. Arıza belirli bir istemciyi izliyorsa sunucu günlüğü o deneme için hiçbir şey göstermez, bu da kendi başına bilgilendiricidir. Atama hatasının olmaması sorunu o istemcideki pazarlığa daraltır ve sırada hangi komutları çalıştıracağınızı söyler.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Sunucunun atama durumunu okuyun
RRAS tarafında, belgelerin varsaydığı yöntem yerine gerçekte hangi atama yönteminin yapılandırıldığını doğrulayın. Statik havuz ile DHCP üzerinden iletilen yapılandırma farklı biçimlerde başarısız olur ve düzeltme hangisi kullanılıyorsa ona aittir. Statik havuzda boş adresleri sayın ve kimsenin hatırlamadığı bir kiralama tutan kullanıcı başına atamaları arayın, çünkü büyük görünen bir havuz tamamen dolu olabilir. DHCP'de aktarıcının bir sunucuya ulaştığını ve kapsamda boş kiralamalar olduğunu kontrol edin.
Sıradan istemciler tarafından tüketilen bir kapsam, yanlış yapılandırılmış bir havuzla aynı 720'yi üretir ve RRAS konsolu her iki durumda da tamamen sağlıklı görünür. Bir havuzu daha küçük aralıklara bölme yönündeki miras alınan geçici çözüme direnin: özgün tavsiye bir yöneticinin sonucunu anlatıyordu ve sunucunun kendi olaylarının doğrudan adlandırabileceği bir atama arızasını onarmıyor.
İstemcinin bağlamalarını bozmadan okuyun
Kanıtlar tek bir istemciyi işaret ediyorsa, yığını yeniden yüklemek yerine gizli bağdaştırıcıyı inceleyin. İlk komut WAN Miniport arabirimlerini ve adlarını listeler; ikincisi döndürdüğü adı alır, bir kılavuzdan kopyalanmış adı değil.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsListeyi adres çözümleme bağlaması ve üçüncü taraf filtreleri açısından okuyun. Devre dışı bir bağlama hedefli bir onarımdır, oysa bir filtrenin varlığı o yazılımın sahibine bir sorudur, bir güvenlik ürününü devre dışı bırakma izni değil. Tüm bağdaştırıcıları silmek, arıza geri dönerse ihtiyaç duyacağınız kanıtları yok eden tek hamledir.
Düzeltmeden sonra aynı profili yeniden deneyin ve bu özgün belirtiyse iki istemci vakasını yineleyin, çünkü başarılı bir ilk bağlantı ikinci bir istemcinin ortaya çıkardığı atama sorununu gizler. Notu dört alanda tutun: hangi istemci, hangi bağlama, hangi olay ve ne değişti. Deneme başına tek katman değiştirin, çünkü birlikte uygulanan istemci düzeltmesi ve havuz değişikliği atfedilemez ve sonraki arıza aynı olduğunda yeni görünecektir.