SSTP zaman aşımı mı sertifika hatası mı: ikisini nasıl ayırt edersiniz

Bir SSTP bağlantısı, kullanıcının koltuğundan aynı görünen iki şekilde başarısız olur ve her birinin onarımı farklı bir katmanda durur. Zaman aşımı, gereken bir değiş tokuşun hiç bitmediği anlamına gelir; sertifika hatası, kimlik malzemesinin gelip reddedildiği anlamına gelir. İkincisini birincisi gibi ele almak sizi hiç sorun olmayan güvenlik duvarlarına ve parolalara gönderir. Ayırt edici kanıt, herhangi bir şeyi değiştirmeden önce okursanız istemcinin kendi günlüğündedir.

İki arıza, iki farklı değiş tokuş

SSTP tüneli HTTPS biçimli bir oturumun içinde taşır, bu yüzden yalnızca 443'e izin veren ağlarda hayatta kalır. İstemci TLS el sıkışmasını tamamlar, protokole özgü bir yöntemle HTTP isteği gönderir ve ardından tünel o akışın içinde çalışır. Bu adımlardan herhangi birindeki arıza bağlantıyı durdurur ve yalnızca sonraki adımlar kimlik bilgilerini ilgilendirir.

Bu sıra tanının kendisidir. TLS el sıkışması hiç tamamlanmazsa hiçbir kimlik bilgisi gönderilmedi, dolayısıyla parola sıfırlama yardımcı olamaz. El sıkışma tamamlanıp sonra takılırsa kimlik kabul edildi ve istek yolundaki bir şey onu reddetti. El sıkışma bir doğrulama iletisiyle başarısız olursa sunucu yanıt verdi ve istemci duyduğunu beğenmedi. Üç sonuç, üç katman.

Günlük satırı genellikle üçünden hangisinde olduğunuzu söyler, bu yüzden ilk değişiklikten önce onu kaydetmeye değer.

Zaman aşımı, bir aşamanın hiç tamamlanmadığı anlamına gelir

Ad çözümlemesi ve TCP erişilebilirliği ile başlayın, çünkü oradaki zaman aşımı sonraki bir zaman aşımıyla aynı görünür. 443'ün açık olduğunu bildiren bir bağlantı noktası denetleyicisi yalnızca bir dinleyicinin bağlantıyı kabul ettiğini kanıtlar, daha fazlasını değil.

Sıradaki şüpheli ana makine değil, yoldur. Proxy'ler ve uygulama farkında olan güvenlik duvarları bazen SSTP'nin kullandığı istek yöntemini reddeder ya da saatlerce açık kalan bir akışı düşürür ve her iki davranış da istemci tarafından zaman aşımı gibi görünür. Aynı ana makinenin sunduğu sıradan bir HTTPS sayfası tünel yöntemi reddedilirken kusursuz yüklenir, bu yüzden uç noktaya tarayıcıyla gitmek çok az şey kanıtlar. Bu iki durumu ayırmak için proxy'siz bir ağdan test edin.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Karşı tarafın herhangi bir yanıtından önceki zaman aşımı hesap hakkında hiçbir şey söylemez ve o anda parolayı değiştirmek yalnızca bir değişken ekler.

Sertifika hatası, kimliğin reddedildiği anlamına gelir

Burada sunucu gerçekten yanıt verdi, yani ağ çalışıyor ve soru kimliğe kayıyor. İstemcinin aradığı adı sertifikanın gerçekten iddia ettiği adlarla karşılaştırın, ardından geçerlilik tarihlerini ve veren zincirini denetleyin.

İstemcinin güvenmediği özel bir CA, süresi geçmiş bir sertifikayla aynı hata sınıfını üretir; saatlerce yanlış giden bir saat de öyle. Ham adresi aramak yeni bir uyuşmazlık yaratır, çünkü sertifika adresleri değil adları iddia eder. Yönetilen bir kurulumda, hata sayfasının sunduğu yedek kökü kabul etmek yerine amaçlanan güven yapılandırmasını yöneticisinden alın. Nedeni düzeltirken doğrulama açık kalır.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Başarılı TLS aşamasını geçtikten sonra dokunulmadan bırakın, çünkü sonradan geri almak tüneli gerçekten hangi değişikliğin onardığını gizler.

İkisinin karıştığı yer

Her iki arıza da açılmayan bir bağlantı olarak görünür ve ikisi de kullanıcı ilgisiz bir şeyi değiştirdikten sonra gelir. O tesadüf, yanlış onarımı bir süre akla yatkın gösterir.

İki alışkanlık onları ayrı tutar. Yapılandırmaya dokunmadan önce istemci günlüğünü kaydedin, ilk durum korunsun. Her denemede tek bir katmanı değiştirin, sonraki sonuç bilinen bir değişkene ait olsun. Bağlantı noktası denetleyicisi ve tarayıcı tam sıra değil, kısmi gözlemlerdir ve hiçbiri istemcinin kendi raporunun yerini tutmaz. Alışkanlıkların hiçbiri bir şeye mal olmaz ve ikisi de soruşturmayı kısaltır.

Sertifika sorusu ile erişilebilirlik sorusu bir nedenle ayrı belgelenmiştir.

Gerçek istemciyle yeniden test edin, sonra içeri doğru ilerleyin

Somut düzeltme yerine oturduğunda tarayıcı sekmesiyle değil, gerçek SSTP istemcisi ve gerçek profille yeniden deneyin.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Oturum bağlanıp kaynaklar hâlâ başarısız olursa tünel artık şüpheli değildir: yönlendirme, DNS ve hizmet erişimine geçin. Bu, başka kanıtları olan başka bir soruşturmadır. Çalışan TLS ve kimlik doğrulama aşamalarını korumak, bunun ilkinin tekrarına dönüşmesini önler. Başarısız olan aşamayı bilete yazın, yoksa bir sonraki kişi yine baştan başlar.