Windows’un yerleşik VPN’i bir sağlayıcı SSL ağ geçidine ulaşamıyor: neden

Windows dört tünel türüyle gelir ve sağlayıcı ağ geçidi bunlardan biri değildir. Yine de yerleşik bir profili böyle bir ağ geçidine yönlendirin, bağlantı kimlik bilgileri istenmeden önce başarısız olur, genellikle bağlantının yerel sistem tarafından sonlandırıldığına dair bir mesajla. Bu metin bir uyumsuzluk işaretidir, teşhis değil. Profil türü ile protokolün sahibi olan istemcinin uyuşması gerekir ve bunlardan biri eksiktir.

Dört tür ve bir iletişim kutusu

Kaydedilen her profil bir tünel türü taşır. Yerleşik istemci PPTP, L2TP, IKEv2 ve SSTP kabul eder, ayrıca bunları sırayla deneyen otomatik bir mod sunar. Genel bir SSL VPN girdisi yoktur ve iletişim kutusundan bir tane eklemenin yolu yoktur. Sağlayıcı ağ geçidi TLS üzerinde kendi uygulama protokolünü konuşur; bunu yalnızca o sağlayıcının istemcisi uygular.

Liste bir komut uzaklıkta ve başka herhangi bir sorun gidermeden önce çalıştırmaya değer, çünkü bir saniye sürer ve yanlış varsayımlardan oluşan koca bir sınıfı ortadan kaldırır:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

Profil SSTP diyorsa ve ağ geçidi bir RRAS sunucusu değilse, uyumsuzluk zaten kanıtlanmıştır. Hiçbir sertifika veya güvenlik duvarı çalışması bunu değiştirmez.

SSTP ile sağlayıcı TLS’i 443 numaralı bağlantı noktasında aynı görünür

SSTP bir PPP oturumunu TLS içine sarar ve TCP 443 üzerinden gider. Microsoft yığınında bunu RRAS sonlandırır ve istemcinin doğruladığı bir sunucu sertifikası sunar. Bir Fortinet, Citrix veya Pulse cihazı da 443’te TLS’i sonlandırır ve portalı her tarayıcıda şikâyet olmadan açılır.

O tarayıcı testi erişilebilirliği kanıtlar, uyumluluğu değil. Portalın arkasındaki oturum protokolü sağlayıcıya aittir ve yerleşik istemcinin onun hiçbir uygulaması yoktur. Sağlayıcının kendi istemcisini sunup sunmaması, uyumsuzluğun hangi yarısıyla uğraştığınızı söyler.

Ters karışıklık da olur. Gerçek bir RRAS sunucusuna karşı SSTP olarak yapılandırılmış bir profil, portal düzgünken sertifika doğrulamasında başarısız olabilir ve bu bir sertifika sorunudur, protokol sorunu değil.

Tünel oluşmadan önce görünen hatalar

800 serisi kodlar herhangi bir tünel kurulmadan önce bildirilir, bu yüzden güvenlik duvarı kuralları onları nadiren hareket ettirir. Hata 812, istemcinin sunduğu kimlik doğrulama yöntemini reddeden sunucu tarafı ilkesidir. Aralıktaki diğerleri ağdan değil, yerel bağlantı yöneticisinden gelir.

Herhangi bir şeyi yeniden kurmadan önce izlemeyi açın. İzleme, başarısız olan aşamayı adlandırır ve bir aşama adı iletişim kutusu metninden daha değerlidir:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

İzlemeler izleme dizini altına düşer ve siz temizleyene kadar orada kalır, bu yüzden haftalarca açık bırakmak yerine sonra kapatın.

Bağlı bir profil yine de her şeyi bozabilir

Bağlanan ve sonra taramayı, yerel paylaşımı veya konteyner motorunu bozan bir profilin sorunu tünel değil, yönlendirmedir. Varsayılan ağ geçidi tünele taşındı, bu yüzden her hedef artık onu yönlendirmeyebilecek bir eş üzerinden gider.

Bunu iki ayar belirler. Biri profildeki split tunneling özelliğidir. Diğeri, IPv4 gelişmiş ayarlarında bulunan, her bağdaştırıcı için uzak ağdaki varsayılan ağ geçidini kullanma seçeneğidir.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Rota eklemeden split tunneling’i açmak, bağlanan ama hiçbir yere ulaşmayan bir tünel üretir. DNS’i kontrol etmeden kapatmak, bağdaştırıcının kendi sonek ve sunucuları kullanılmadığı için ortak yanıtlara çözülen iç adlar üretir.

Önce tesisatı, sonra türü doğrulayın

Bu sırayla çalışın ve her şeyi aynı anda ayarlamak yerine bir adım başarısız olduğunda durun:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

İlk komut erişilebilirliği protokolden ayırır. İkincisi profilin ne olduğunu iddia ettiğini doğrular. Yönlendirme tablosu tünelin varsayılan rotayı alıp almadığını gösterir. Arama komutu bağlantı yöneticisinin kendi hatasını bildirir, bu genellikle iletişim kutusundan daha açıktır.

Kayda tünel türünü, ağ geçidi ürününü ve tam hatayı yazın. Böylece sıradaki kişi bir dakika içinde bunun protokol uyumsuzluğu, sertifika arızası mı yoksa yönlendirme kararı mı olduğunu bilir, “VPN çalışmıyor” diye başlamak yerine.