Tarayıcının HTTPS'i başarırken SSTP'nin başarısız olması: neden

Tarayıcı VPN ana bilgisayar adını HTTPS üzerinden sorunsuz açar, ancak SSTP istemcisi bağlanmayı reddetmeye devam eder. Bu çiftte çelişkili hiçbir şey yok. SSTP, TLS'i dış taşıma katmanı olarak kullanır ve ardından kendi isteğini ve PPP yükünü o bağlantının içinde yürütür, bu nedenle başarılı bir sayfa yüklemesi yalnızca dar bir şeyi kanıtlar: ana bilgisayar 443 numaralı bağlantı noktasında bir GET'e yanıt verir. İstemci başka bir soru soruyor ve sunucu ona kötü yanıt verebilir.

Sayfa yükleniyor, tünel yüklenmiyor

İnsanlar tarayıcı testine hızlı olduğu için başvurur ve sonucu sunucunun erişilebilir ve yapılandırılmış olduğunun kanıtı olarak alır. Bu, adres çubuğunun açtığı yola yapılan GET hakkında bir kanıttır, fazlası değil. VPN konuşması aynı TLS el sıkışmasından sonra başlar, ancak şunu gönderir: bir web sayfasının asla kullanmadığı bir yöntem ve yol. Bu nedenle tarayıcıya verilen 200 yanıtı, SSTP uç noktasının var olup olmadığı hakkında hiçbir şey söylemez.

İki gözlemi ayırın ve arama kısalır. Taşıma ve sertifika zinciri çalışıyor, üstlerindeki protokol alışverişinde bir şey çalışmıyor. Bu, bozuk bir bağlantı noktasından veya süresi geçmiş bir sertifikadan farklı bir soruşturmadır ve farklı kanıtlar gerektirir.

SSTP istemcisi gerçekte ne gönderir

İstemci, SSTP_DUPLEX_POST yöntemiyle /sra_{GUID}/ yoluna bir HTTP isteği gönderir, ardından bağlantı gövdesini PPP çerçevelerini taşıyan çift yönlü bir akış olarak açık tutar. Uygun bir sunucu HTTP/1.1 200 yanıtı verir ve web sunucusu gibi davranmayı bırakır. Geri kalan her şey bir imzadır: 405 veya 404 uç noktanın olmadığını, 301 veya 302 bir şeyin isteği yönlendirdiğini, ani bir FIN ise bir proxy veya sunucunun akışı kapattığını gösterir.

Bu nedenle hedef, TLS sertifikası takılmış bir web sunucusu değil, bir SSTP sunucusu olmalıdır. Yöntem, yol ve uzun ömürlü gövde protokol gereksinimleridir, bu nedenle ters proxy bunları yalnızca yapılandırmayla ekleyemez. Sıradan HTTPS'i kusursuz ileten bir proxy, tanımadığı bir yöntemi yine de reddedebilir.

Proxy veya web sunucusu akışı nerede bozar

Bir aracı, herhangi bir şeyi iletmeden önce HTTP istek satırını inceler ve alışılmadık yolu olan özel bir yöntem onun kurallarına takılabilir. Bazı cihazlar normal sayfa sunarken tüneli reddeder veya keser, bu nedenle istemci temiz bir ret yerine başlayıp sonra ölen bir bağlantı bildirir. Diğerleri isteği kabul eder, sonra PPP keepalive'larının dayanamayacağı bir gövde veya boşta kalma zaman aşımı uygular. İkisi de istemci tarafından aynı görünür, bu yüzden başarısız olan aşama hata metninden daha önemlidir.

443 numaralı bağlantı noktasını bir web sitesi ile SSTP arasında paylaşmak bir yönlendirme seçimidir, her atlamanın iki konuşmayı aynı şekilde ele alacağına dair bir söz değildir. Yolda bir yük dengeleyici, güvenlik duvarı veya TLS sonlandırıcı varsa, VPN yapılandırmasına dokunmadan önce onu şüpheliler listesine ekleyin.

Aşamaları ayrı ayrı test edin

Kontrolleri sırayla çalıştırın ve ilk hatada durun, çünkü her aşama farklı bir katmanı eler. Aşağıdaki TLS sondası sertifikanın kimliğini SSTP'nin yaptığı her şeyden ayırır. Ana bilgisayar adını kendi uç noktanızla değiştirin ve yazdırdığı subject ile zinciri okuyun.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com

Ardından kalan kanıtları istemci hatasından tahmin etmek yerine aşamalarla eşleştirin. Aşağıdaki tablo, bir başarısızlığı sonrakinden ayıran imzayla birlikte, kayda alıntılamak için kontrol listesidir.

Kayda "bağlanılamıyor" yazmak yerine son başarılı aşamayı not edin. MS-SSTP belirtimi TLS el sıkışmasından sonra gelen isteği ve PPP alışverişini belgeler ve bir tarayıcı testinin neden ikisinin de yerini tutamayacağının referansıdır.

Önce kimlik, sonra PPP

TLS kimliği ve PPP kimlik doğrulaması sıralıdır, alternatif değildir ve bunları karıştırmak insanları yanlış sunucu ayarına gönderir. İstemci önce sunucu sertifikasını ve amaçlanan kullanımını doğrular, sonra PPP kendi durumunu müzakere eder ve kullanıcıyı meydan okuma-yanıt yöntemi veya EAP ile doğrular. Sertifika sorunu reddedilen paroladan farklı bir hata üretir ve iki hatanın hiçbiri diğerinin kapsadığı aşamayı tanımlamaz.

Ana bilgisayar adını bir adresle değiştirmek veya sertifika uyarısını tıklayıp geçmek, başarısız aşamayı tanımlayacak kontrolü düzeltmek yerine kaldırır. Uyarıyı koruyun ve okuyun. HTTP alışverişi hiçbir zaman SSTP davranışına ulaşmadığında PPP parolasını sıfırlamayın, çünkü kimlik bilgileri hiç istenmedi.