Windows VPN adres alanındaki bağlantı noktası yalnızca SSTP ile çalışır

Bir VPN sunucusu TCP 10443 üzerinde yanıt veriyor, yerleşik Windows istemcisinin kimlik bilgileri doğru, ancak bağlantı yine de DNS zaman aşımına benzeyen bir duraklamadan sonra kopuyor. Nedeni genellikle adres alanıdır: Sunucu adı veya adres alanına vpn.example.com:10443 yazmak, Windows’un tüm dizeyi bir ana bilgisayar adı olarak okumasına neden olur, çünkü bu kutu genel bir host:port girişi değildir. Bir bağlantı noktasının orada ifade edilip edilemeyeceği profilin kullandığı tünel türüne bağlıdır ve dört türden yalnızca biri değeri ayrıştırabildiği bir şey olarak ele alır.

Adres alanı neden host:port kutusu değildir

Bu alanın arkasındaki profil özelliği ServerAddress’tir ve her tünel türü dizeyle ne yapacağına kendisi karar verir. Üçünün doldurulacak bir bağlantı noktası parametresi yoktur, bu yüzden iki nokta üst üste ve bir sayı yalnızca hiçbir zaman çözümlenmeyecek bir addaki karakterlerdir. Dördüncüsü, bağlantı noktasının URL’nin parçası olduğu HTTPS üzerinden çalışır, bu yüzden değer URL olarak ayrıştırılan bir biçimde yazılmalıdır.

Bu yüzden hata ad çözümlemesi gibi görünür, reddedilen bir bağlantı gibi değil. Bildirilecek kötü bir bağlantı noktası yoktur, yalnızca var olmayan bir ana bilgisayar adı vardır ve hata, çözümleyici pes ettikten sonra gelir. Sunucuya dokunmadan önce profilin hangi tünel türünü kullandığını söylediğini kontrol edin.

Sabit bağlantı noktalı üç tür

PPTP, TCP 1723’e bağlanır ve ardından tüneli GRE, IP protokolü 47 içinde taşır. L2TP/IPsec, tünel için UDP 1701 ve IPsec için UDP 500 artı 4500 kullanır; 4500, NAT geçiş bağlantı noktasıdır. IKEv2 de UDP 500 ve 4500 kullanır. Bu profillerin hiçbiri arayüzün hiçbir yerinde bağlantı noktası alanı göstermez ve hiçbiri standart olmayan bir bağlantı noktası üzerinde anlaşmaz.

Özel bir bağlantı noktasını dinleyen bir sunucu bu nedenle adres nasıl yazılırsa yazılsın o profiller için erişilemezdir. Pratik yanıtlar dardır: standart bağlantı noktasını sunucuda yayınlayın veya standart bağlantı noktasını önündeki yönlendiricide özel olana çevirin. Her ikisi de istemci profilini dokunulmadan bırakır; bu, profil elle yazılmak yerine ilkeyle dağıtıldığında çok değerlidir.

SSTP ad değil URL gerektirir

SSTP istisnadır çünkü bir TLS oturumu içinde çalışır. Alan bir URL olarak ayrıştırılmalıdır: önce https:// şeması, sonra ana bilgisayar, sonra iki nokta üst üste ve bağlantı noktası. Şema olmadan Windows değeri sıradan bir ad olarak görmeye devam eder ve bağlantı herhangi bir TLS alışverişi gerçekleşmeden önce başarısız olur.

Bunun insanları şaşırtmasının nedeni, varsayılan bağlantı noktasının çıplak ana bilgisayar adını kabul etmesidir. Hiç özel bağlantı noktasına ihtiyaç duymamış bir profil kuralı asla öğretmez ve bir tane ekleyen ilk kişi bunu başarısız olarak keşfeder. Kaydettikten sonra iletişim kutusuna güvenmek yerine saklanan değeri geri okuyun:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress tam olarak neyin saklandığını gösterir. İçinde iki nokta üst üste bulunan çıplak bir ana bilgisayar adı olarak okunuyorsa, profil hiçbir zaman URL almadı ve kaç kez yeniden denense de bu düzelmez.

Aynı kutuya yapıştırılan üretici sözdizimi

Bazı ağ geçitleri bu alan için ek kurallar belgeler; örneğin bağlantı noktasından sonra eklenen bir realm veya sertifika işlemeyi değiştiren sorgu parametreleri. Bunlar o üreticinin sunucusu ve bazı derlemelerde kendi istemcisi tarafından anlaşılır. Windows profil biçiminin parçası değildirler ve yerleşik bir profile yapıştırılmaları genellikle aynı sessiz ad hatasını üretir.

Sertifika doğrulamasını devre dışı bırakan bir parametreyi düzeltme değil uyarı olarak görün. Bir profil yalnızca o parametreyle bağlanıyorsa sertifika kullanılan adla eşleşmiyordur ve doğru onarım istemcide değil ağ geçidindedir. Bağlantı noktasından sonraki bir realm aynı özelliğe sahiptir: yalnızca karşı taraftaki sunucu onu bekliyorsa bir şey yapar.

Bağlantı noktasını kanıtlayın, sonra başarısız aşamayı okuyun

Profili suçlamadan önce istemcinin ağından bu bağlantı noktasında TCP’yi bir şeyin kabul ettiğini doğrulayın:

Test-NetConnection vpn.example.com -Port 10443

Başarı bir dinleyiciyi kanıtlar, SSTP’yi değil. Bir web sunucusu, ters proxy veya yük dengeleyici TCP el sıkışmasını tamamlayıp yine de SSTP konuşmayabilir, bu yüzden yeşil bir testle kırmızı bir VPN gerçek bir kombinasyondur. Sertifikanın konusunu profildeki adla karşılaştırın ve onu içeren derlemelerde RasClient günlüğüne bakın, çünkü genel bir zaman aşımı yerine başarısız olan aşamayı kaydeder.

Ardından sorunu belgelemek yerine ortadan kaldıran seçeneği düşünün: dışarıdan TCP 443’ü VPN sunucusunda 10443’e yönlendirin. İstemci o zaman hiç bağlantı noktası olmayan varsayılan profili kullanır; bu genellikle yönetilen bir filo için en temiz düzenlemedir ve özel bağlantı noktasını iç ayrıntı olarak bırakır.