Bir .NET soketi SOCKS el sıkışması gerektirir

SOCKS sunucusuna Socket.Connect() yöneltmek o sunucuya bir TCP bağlantısı açar. Sonraki baytlar yine de SOCKS konuşmak zorundadır. Uygulamanızın protokolünü hemen göndermek sunucuyu farklı bir konuşma beklerken bırakır.

SOCKS5 ile bağlantı kurulumu yöntem görüşmesini, seçilen herhangi bir kimlik doğrulama alışverişini ve hedefi belirten bir isteği içerir. Uygulamanın baytlarına yolu yalnızca başarılı bir yanıt açar. Bu aşamalar RFC 1928 belgesinde tanımlanmıştır.

Görüşmeyi bağlantı katmanında tutun

Kendi TCP protokolüne sahip bir uygulama, kurulmuş bir akış döndüren proxy farkındalığı olan bir bağlayıcı kullanabilir. Uygulamanın geri kalanı bu akış üzerinden okur ve yazar. Bir bağlayıcı kısmi okumaları, değişken uzunluktaki adresleri, kimlik doğrulama hatalarını ve görüşme için bir son tarihi hesaba katmalıdır.

Sabit boyutlu tek bir tamponu okuyup başarıyı varsayan elle yazılmış bir uygulama kırılgandır. TCP SOCKS mesajlarının sınırlarını korumaz. Uygulama protokolünü başlatmadan önce adres türüyle tanımlanan tam yanıtı okuyun. .NET 7+ için bir CONNECT yanıtı okuyucusu bu adımı örnekler.

Bakımı yapılan bir kitaplık bu bağlantı katmanını zaten sağlıyorsa, desteklediği SOCKS sürümlerini, kimlik doğrulama yöntemlerini ve hedef çerçevesini kontrol edin. On yıllık bir forum bağlantısı, güncel uyumluluğun kanıtı değil, inceleme için bir başlangıç noktasıdır.

HTTP istemcisi yapılandırmasının ayrı bir kapsamı vardır

Bir HTTP istemcisinin proxy ayarı o HTTP istemcisini yapılandırır. Süreçteki her ham soketi değiştirmez. Socket API bir ağ uç noktası kabul eder ve üst düzey görüşmeyi çağırana bırakır.

Şifrelenmiş bir uygulama protokolü için, proxy tüneli kurulduktan sonra TLS el sıkışmasını gerçekleştirin. Amaçlanan hedef kimliğini o aşamada doğrulayın. Proxy kimlik doğrulaması ve hedef kimlik doğrulaması aynı temel akışı kullansalar bile ayrı kalır.