Bir VPN istemcisinin SSTP'yi gerçekten destekleyip desteklemediği nasıl anlaşılır

Bir ürüne VPN istemcisi demek, onun SSTP konuşup konuşmadığı hakkında hiçbir şey söylemez; adresteki 443 bağlantı noktası ise daha da az şey kanıtlar. SSTP, TCP 443 üzerinde TLS çalıştırır, ardından bir SSTP denetim alışverişi, ardından bağlantının kendisi için PPP gelir; üstünde de sertifika doğrulaması ve bir PPP kimlik doğrulama yöntemi bulunur. Bir istemci protokolü yalnızca belirtilen uygulama, kurulu sürümde, sunucunuzun gereksinimlerine göre bu katmanların her birini tamamladığında destekler. Aşağıdaki kontrolleri sırayla yapın ve ilk başarısız olanda durun, çünkü çözülmeye değer olan odur.

Uygulamayı, sürümü ve platformu eşleştirin

Platformla, uygulamayla ve kurulu derlemeyle başlayın, çünkü tek bir üretici adı birbirinden tamamen farklı iki uygulamanın üzerinde olabilir. Yerleşik VPN türleri ile üçüncü taraf istemcileri aynı şey değildir ve bir eklenti, altındaki protokolü tanımlamayan bir bağdaştırıcı etiketi gösterebilir. Geçerli sürümün belgeleri, önünüzdeki makinede çalışan derlemeyi tanımlamaz. Sürüme özgü sayfayı okuyun, sonra istemcinin kendisi hakkında bildirdikleriyle karşılaştırın.

Windows'ta tünel türü GUI'den değil platformdan gelir, bu yüzden platforma sorun. Yerel istemci protokolü deneyeceğinde Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress Sstp gösterir ve bağlantı türleri başvurusu bunu yerleşik tünel türleri arasında sayar. Linux'ta yerel bir SSTP istemcisi hiç yoktur, bu nedenle soru sstp-client paketindeki sstpc gibi ayrı bir uygulamanın kurulu ve güncel olup olmadığına dönüşür.

Etiketten önce profil biçimini okuyun

Profiller birbirinin yerine geçmez ve size verilen dosya genellikle soruyu herhangi bir özellik listesinden daha hızlı çözer. OpenVPN yönergeleri, WireGuard anahtarları ve SSTP bağlantı ayarları birbiriyle ilgisiz üç protokolü tanımlar ve hiçbir içe aktarma penceresi birini diğerine dönüştürmez. TCP 443 bağlantı noktasını paylaşmak hiçbir şeyi çevirmez, çünkü SSTP, TLS üzerinden OpenVPN ve sıradan bir HTTPS hizmeti aynı bağlantı noktasını kullanabilir ve bunun üstünde ortak hiçbir yanları yoktur.

Dosya bir .ovpn veya WireGuard yapılandırmasıysa yanıt zaten açıktır: o istemciden SSTP konuşması istenmiyor. Yalnızca SSTP yapan bir istemciye içe aktarmak, profil aşamasında başarısız olur; herhangi bir protokol görüşmesi başlamadan çok önce.

TLS'in dağıtım hakkında kanıtlamadıkları

Tamamlanmış bir TLS el sıkışması, sunucunun bir sertifikası olduğunu kanıtlar ve istemcinizin veren zincirine güvenip güvenmediği ya da içindeki adın eşleşip eşleşmediği hakkında hiçbir şey kanıtlamaz. Doğrulama, amaçlanan sunucuya karşı başarılı olmalıdır; kuruluşun işlettiği özel bir CA da buna dahildir; sertifika hatalarını atlamayı öneren bir istemci ise protokol desteği kazanmak yerine denetimi kaldırmıştır. Zincir doğrulaması ve ad eşleşmesi iki ayrı testtir ve birini geçen bir yığın diğerinde başarısız olabilir. İkisi de kabul ölçütlerine aittir, sorun giderme ekinde değil.

Ardından PPP kimlik doğrulama yöntemini doğrulayın, çünkü EAP-TLS kullanan bir dağıtım PPP içinde sertifika sunabilen bir istemci gerektirirken parola tabanlı bir yöntem o alışverişin desteğini gerektirir. Bir sunucu adresi ve parola, kuruluşun gerçek gereksinimini tanımlamaz; özellikle de önünde ikinci bir etken ya da cihaz denetimi varsa. İstemcinin bunu karşılayabileceğini varsaymadan önce sunucunun hangi yöntemi zorunlu tuttuğunu sorun.

Oturumu dört aşamada izleyin

Bağlantının dört sınırı nasıl aştığını izleyin: sunucuya TCP ve TLS, SSTP denetim alışverişi, PPP görüşmesi ve ardından gerçekten gereksinim duyduğunuz kaynak. TLS'ten sonra duran bir kayıt, PPP içinde durandan farklı bir arızayı tanımlar ve ikisi farklı sorumlulara çıkar. Tarayıcının ana makinenin web sayfasını yüklemesi yalnızca 443'te bir şeyin yanıt verdiğini kanıtlar; bu, bu alandaki en yaygın yanlış pozitiftir. O sayfa yüklenirken istemci hâlâ başarısız oluyorsa, sorun TLS'in üstünde ve web sunucusu şüpheli değil.

Gerçek bir özel kaynak ve bir ad sorgusuyla bitirin, çünkü kurulan ve hiçbir şey taşımayan bir oturum çoğu durum penceresinde çalışanla aynı görünür. İhtiyacınız olan kaynağa yapılan tek bir başarılı istek, simgenin yanıtlayamadığı bir soruyu çözer.

Destek yoksa planı değiştirin

İstemci SSTP konuşamıyorsa onaylı bir alternatif edinin ya da sunucu sahibinden iki ucun da desteklediği bir protokol isteyin. İçe aktarma başarılı olana kadar bilinmeyen seçenekleri silmek, hiçbir yere bağlanmayan bir profil üretir; bu da aynı çıkmaza giden daha yavaş bir yoldur. Evrensel uyumluluk reklamı yapan bilinmeyen kaynaklı bir yükleyici, makineye onaylanmamış bir güven yolu ekler ve çoğu zaman platform istemcisini kuruluşun güncelleyemediği bir şeyle değiştirir. İki hamleden hiçbiri bir onarım değildir ve ikisini geri almak da asıl sorundan daha zordur.

Uyumluluk sorusunu başarım ve uç nokta seçiminden ayrı ele alın, çünkü istemci onun protokolünü konuşamıyorsa yakındaki bir sunucu işe yaramaz. Gecikme ayarı hiç bitmeyen bir aşamayı onarmaz.