Windows NAT-T kayıt değeri: önce topolojiyi denetleyin

Bir Windows VPN bağlantısı başarısız olur, arama bir kayıt değeri döndürür ve bu değer yeniden başlatmayla birlikte girilir. Bu sıra bazen işe yarar ve hiçbir şeyi açıklamaz. Söz konusu ayar, sunucunun bir NAT aygıtına göre nerede olduğuna dair tek bir soruyu yanıtlar ve hangi protokolün hangi aşamada başarısız olduğunu bilene kadar anlamsızdır.

Değer gerçekte neyi seçer

AssumeUDPEncapsulationContextOnSendRule, Windows'un IPsec uygulamasının NAT aygıtının arkasındaki bir eşle ilişki kurmayı deneyip denemeyeceğini belirler. Belgelenen varsayılan 0 bu duruma izin vermez, 1 sunucu NAT'ın arkasındaki taraf olduğunda izin verir ve 2 her iki ucun da çevrildiği durumu kapsar. Bunlar kimin nerede olduğuna dair topoloji ifadeleridir.

Dizi olarak okunduğunda sayılar giderek artan güvenilirliği değil, giderek artan çeviriyi anlatır. Hiçbir şeyin çevrilmediği bir ağda 2 ayarlamak bağlantıyı daha hızlı veya daha kararlı yapmaz ve kimlik doğrulama hatasını onarmaz. Microsoft'un L2TP/IPsec için NAT kılavuzu politikayı ve tarihsel platform bağlamını belgeler. Bu bağlamı gerçekten çalıştırdığınız Windows sürümü ve rolüyle karşılaştırın, çünkü birkaç sürümü atlatan bir belge her güncel derleme hakkında bir ifade değildir.

Sayıdan önce topolojiyi eşleştirin

Yolu çizin ve çeviri noktalarını işaretleyin: istemci bir ev yönlendiricisinin arkasında mı, sunucu bir yük dengeleyicinin veya adresleri yeniden yazan bir güvenlik duvarının arkasında mı ve uçlardan biri denetlemediğiniz bir operatör çevirisinin arkasında mı. Ancak bu çizimden sonra değerin geçerli olup olmadığına ve hangi uca uygulanacağına karar verebilirsiniz.

Güncel Windows Server sürümlerinin NAT traversal kapalı olarak geldiği iddiası, üzerine hareket etmek için fazla geniştir. Önemli olan sisteminizdeki politika, önündeki topoloji ve başarısız olan alışveriştir; bu sırayla. İki ucun da genel adresi varsa ayar sizin sorununuz değildir. Bunun yerine teklife, sertifikaya veya hesaba bakın ve kayıt defterini rahat bırakın.

Önce hatanın aşamasını denetleyin

L2TP/IPsec en az üç farklı hata üretir: eşe ulaşılamıyor, IPsec koruması kurulamıyor ve tünel oluştuktan sonra PPP kullanıcı kimlik doğrulaması reddediliyor. Reddedilen bir hesap NAT politikası değiştirilerek onarılamaz ve teklif uyuşmazlığı yeniden başlatmayla onarılamaz.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

Yanıt veren olmadan zaman aşımı, politikadan çok erişilebilirliğe veya filtrelemeye işaret eder. Teklif mesajıyla hızlı ret, algoritmalara işaret eder. Tünel kalktıktan sonraki hata kimlik doğrulama aşamasına aittir; bu başka bir sahip ve başka bir çözümdür.

HTTPS üzerinden SSTP ve yerel IKEv2 kendi günlüklerine ve kendi denetimlerine sahiptir. Windows'ta da çalıştığı için hiçbiri NAT-traversal vakasına dönüşmez.

Değişikliği bir geri dönüş yoluyla yapın

Belgelenen politika ve gözlenen topoloji birlikte gerektiriyorsa önceki değeri kaydedin, değişikliği profil başına betik yerine yönetilen yapılandırma üzerinden uygulayın ve yeniden başlatmayı planlayın. Başka iş yüklerini destekleyen bir sunucuda bu zararsız bir düzenleme değildir.

NAT aygıtı kapsüllenmiş taşımayı ve dönüş trafiğini yine taşımak zorundadır. Bir kayıt değeri yönlendirme kuralı oluşturmaz, teklifleri hizalamaz ve kimliği doğrulamaz; bu yüzden değişiklikten sonra çalışmaya başlayan bir bağlantı tamamen başka bir nedenle çalışıyor olabilir. Özgün protokolü özgün topolojiyle yeniden test edin, sonra hangi aşamanın başarısız olduğunu ve değerin neden bunu çözeceğinin beklendiğini yazın. İnternet söylentisini savunulabilir bir yapılandırmaya dönüştüren şey o cümledir.