SSTP, HTTPS üzerinden PPP'dir, 443 portundaki bir web sayfası değildir

SSTP PPP'yi bir HTTPS bağlantısı içinde taşır, bu yüzden aradaki her şeye web trafiği gibi görünür. TLS ve HTTP dış kanalı kurar, ardından SSTP denetim iletileri tüneli hazırlar ve PPP oturum davranışını sağlar. Aynı adreste sayfa yükleyen bir tarayıcı ilk aşamanın yalnızca bir bölümünü tamamlamıştır. Bunu VPN testi saymak, çalışan bir proxy'nin protokol uyuşmazlığıyla suçlanmasının yoludur.

Dört aşamayı sırayla gezin, gördüğünüz arıza bunlardan birine düşer.

Aşama 1: TCP ve TLS

İstemci 443 portuna bir TCP bağlantısı açar ve TLS el sıkışması yapar. Sertifika zinciri, istemcinin yapılandırıldığı ana makine adıyla eşleşmelidir. Burada bir ad uyuşmazlığı, herhangi bir SSTP iletisi değiş tokuş edilmeden önce arıza üretir ve SSTP belirtimi bu dış HTTPS kanalının zaten var olduğunu varsayar. Sonraki aşamalarda hiçbir şey buradaki güven arızasını telafi edemez.

Sıradan bir web sunucusu bu aşamayı kusursuz tamamlayıp yine de sonrakinde başarısız olabilir. TLS başarısı sertifika hakkında kanıttır, arkasındaki protokol hakkında değil.

Aşama 2: HTTPS isteği

SSTP isteğini belirli bir yöntemle, SSTP_DUPLEX_POST ile yapar ve belge döndürmek yerine alışverişi açık tutar. Sıradan sayfa istekleri için yapılandırılmış bir sunucu veya proxy bağlantıyı kabul edip sonra yöntemi reddedebilir. Bu ret, insanların genellikle 443 portunun engellendiğini söyleyerek tanımladığı uyumluluk sorunudur.

Sunucu günlüğündeki yanıt kodunu ve yöntemi okuyun. Bu aşamadaki ret, TCP zaman aşımından farklı bir sorundur ve ikisi farklı düzeltmelere götürür.

Aşama 3: denetim iletileri

İstek kabul edildikten sonra SSTP, tüneli pazarlık eden ve hazırlayan denetim iletilerini değiş tokuş eder. Bunlar HTTP isteği değil, HTTPS gövdesi içindeki protokol iletileridir, bu yüzden gövdeleri inceleyip yeniden yazan bir proxy, sayfa isteklerini dokunulmadan bırakırken bunları bozabilir.

Derin denetim yapan ara kutu itibarını burada kazanır. Sayfalar yükleniyor ama VPN başarısız oluyorsa, portun açık olup olmadığını değil, gövdenin değiştirilip değiştirilmediğini kontrol edin.

Aşama 4: PPP devralır

Ardından PPP oturum davranışını sağlar: bağlantı pazarlığı, kimlik doğrulama ve onu izleyen ağ katmanı yapılandırması. PPP kimlik doğrulaması, istemcinin zaten geçtiği TLS denetiminden ayrıdır. İstemcinin kabul ettiği bir sunucu sertifikası, kullanıcının kimlik bilgilerinin geçerli olup olmadığı veya hesabın yetkili olup olmadığı hakkında hiçbir şey söylemez.

Kabul edilen bir sertifika ile reddedilen bir oturum açma çelişkili değildir. Bunlar bağımsız sonuçları olan ardışık aşamalardır.

Kimlik doğrulamanın birkaç rolü vardır

İstemci, TLS sunucusunun kimliğini kendi güven deposuna ve yapılandırılmış ada göre doğrular. Ardından PPP, dağıtıma bağlı olarak kullanıcıyı veya makineyi doğrular. Sunucu, kimin bağlanabileceği ve neye ulaşabileceği konusunda kendi ilkesini ekleyebilir. Ana makine adını sertifikanın kimliğiyle tutarlı tutun, çünkü ham bir adresle değiştirmek çalışan bir kurulumu ad denetimi arızasına dönüştürür.

Hangi aşamanın arızayı bildirdiğini yazın. Sertifika, yöntem, denetim iletisi, PPP kimlik doğrulaması, ardından yollar: beş yer, beş onarım.

Tarayıcı testinin gösterip gösteremeyeceği şeyler

Adreste bir sayfa yüklemek DNS çözümlemesini, TCP erişilebilirliğini ve HTTP konuşan bir şeyin dinlediğini kanıtlar. Yöntemin kabul edildiğini, denetim alışverişinin ayakta kaldığını veya PPP kimlik doğrulamasının yapılandırıldığını kanıtlamaz. Portu değiştirerek başka bir profili dönüştürmek yerine SSTP uygulayan bir istemci kullanın.

Oturum kurulduktan sonra bile yollar, DNS ve sunucu tarafı yönlendirme kullanıcının neye ulaşabileceğini belirler. Tünel bir yoldur, yetki değildir.