TLS’i denetleyen bir proxy arkasında SSTP: oturum nerede kopar

Tarayıcınız kurumsal intraneti yükler, proxy sertifikası güvenilirdir ve yine de SSTP istemcisi bağlantının sonuna yakın düşer. Bu örüntü yanlış parolaya değil, bir web isteği ile tünellenmiş oturum arasındaki farka işaret eder. Bağlantıyı TCP’den yukarı doğru izleyin ve ilk başarısız olan aşamayı not edin. Proxy’nin neden olup olmadığını hata kodu değil, aşama söyler.

İstemcinin durduğu yerden başlayın

İstemci sabit bir sıradan geçer: 443 portuna TCP bağlantısı, TLS el sıkışması, sertifika doğrulaması, SSTP’nin HTTP alışverişi, PPP pazarlığı ve kimlik doğrulaması, ardından IP yapılandırması. Her aşamadaki hata farklı bir iz bırakır ve bunları karıştırmak sizi yanlış yapılandırma sayfasına götürür.

TCP hatası, herhangi bir TLS baytı görünmeden önceki bir zaman aşımı veya sıfırlamadır. TLS hatası bir uyarı veya el sıkışma zaman aşımıdır. Sertifika hatası zincir veya ad hakkında uyarı üretir. HTTP hatası başarılı el sıkışmadan sonra gelir, çoğu zaman durum kodu veya anında kapanma olarak. PPP hatası tünel teknik olarak kurulduktan sonra gelir, bu yüzden kimlik doğrulama sorunu gibi görünür.

İlk hata satırı yerine istemci günlüğünde son başarılı aşamayı okuyun. Hata satırı genelde sonucu bildirir, aşama sınırı ise reddeden bileşeni adlandırır.

SSTP ağdan ne taşımasını ister

SSTP TCP 443 üzerinde TLS ile çalışır ve ardından SSTP belirtiminde tanımlanan SSTP_DUPLEX_POST adlı HTTP isteğini /sra_{GUID}/ biçimindeki bir yola gönderir. İstek pratikte sınırsız bir içerik uzunluğu bildirir ve akışı oturum boyunca iki yönde açık tutar. PPP çerçeveleri o akışın içinde hareket eder.

Bu yüzden sıradan gezinmeyi yöneten bir proxy bile başarısız olabilir. Sonlu gövdeye sahip GET veya POST tamponlanabilir, denetlenebilir ve iletilebilir; asla bitmeyen gövdeye sahip çift yönlü akış iletilemez. Gövdenin bitmesini bekleyen proxy sonsuza kadar bekler ve istemci sonunda zaman aşımına uğrar.

Yöntem filtreleme ve kimlik doğrulama kendi hata kiplerini ekler. Proxy istek için kimlik bilgisi isterse, tarayıcı yanıt verecekken VPN istemcisi vermeyebilir. Yöntemi kaldırır veya yeniden yazarsa, ağ geçidi PPP başlamadan isteği reddeder.

Denetim kimliği neden değiştirir

TLS’i denetleyen proxy istemcinin TLS bağlantısını sonlandırır ve ağ geçidine ayrı bir bağlantı açar. Bu yüzden istemci ağ geçidinin değil proxy’nin sertifikasını doğrular ve ağ geçidi proxy’yi kendi ortağı olarak görür. Kuruluş kendi kökünü dağıttığında hem tarayıcı hem de VPN istemcisi bu zinciri kabul edebilir, böylece el sıkışma başarılı olur ve sorun sonraki aşamaya geçer.

Başarılı doğrulama, proxy’nin oturumu taşıyabileceği anlamına gelmez. Hâlâ sınırsız iki yönlü POST’u tamponlamadan iletmeli ve iki bağlantıyı saatlerce canlı tutmalıdır. Birçok denetim ürünü istek-yanıt trafiği için üretilmiştir ve bu durumu kötü ya da hiç yönetmez.

Bu yüzden bilinmeyen bir kök eklemek veya doğrulamayı kapatmak yanlış onarımdır. İstemcinin hangi sertifikayı kabul ettiğini değiştirir; oturumu gerçekte bozan akış işleme konusunda hiçbir şey yapmaz.

Ayarları değiştirmeden önce vereni belirleyin

Uç noktaya hangi sertifikayı sunduğunu ve kimin imzaladığını sorun. Aşağıdaki komutlar VPN oturumu başlatmadan zinciri ve vereni gösterir:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Veren bir genel CA ise bu ana makine için bağlantı büyük olasılıkla dinlenmiyordur ve hata başka yerdedir. Veren kuruluşun kendi CA’sı ise denetim etkindir ve ağ geçidine proxy üzerinden erişilir. Yalnızca ada bakarak sonuca varmadan önce parmak izini ağ ekibinin beklediğiyle karşılaştırın.

Aynı ana makineye tarayıcı testi yalnızca proxy’nin GET kabul ettiğini kanıtlar. SSTP yöntemi, isteğin URI’si veya gövdenin ömrü hakkında hiçbir şey söylemez, bu yüzden çalışan bir intranet sayfasını tünel yolunun desteklendiğinin kanıtı saymayın.

Desteklenen yolu seçin

Ağ sahibine tek ve somut bir soru sorun: proxy bu ağ geçidine 443 portunda tamponsuz çift yönlü POST’a izin veriyor mu? Evet yanıtı proxy’de bir istisnaya veya VPN ana makinesi için belgelenmiş bir atlatmaya yol açar. Hayır yanıtı denetlenen yolun SSTP taşıyamadığı anlamına gelir ve desteklenen düzeltme istemciyi kurcalamak değil, başka bir yol veya protokoldür.

Seçenekler genelde VPN ağ geçidi için denetlenmeyen bir çıkışı, yalnızca kurumsal trafiği proxy üzerinden gönderen bölünmüş tünel tasarımını veya kuruluşun başka bir portta desteklediği alternatif protokolü içerir. Her biri ağ tasarımına aittir ve her biri aynı cihaz ve profille test edilmelidir ki karşılaştırma yolu yalıtsın.

Sonucu belgeleyin: veren, başarısız aşama, proxy kuralı ve seçilen yol. Aynı yüzde 98 duraklamasını gören bir sonraki kişi tüm geçişi yinelemek yerine tek bir olguyu kontrol edebilecek.