Soket .NET memerlukan jabat tangan SOCKS

Menghalakan Socket.Connect() ke pelayan SOCKS membuka sambungan TCP ke pelayan itu. Bait seterusnya masih perlu bertutur SOCKS. Menghantar protokol aplikasi anda serta-merta meninggalkan pelayan menunggu perbualan yang berbeza.

Dengan SOCKS5, penubuhan sambungan merangkumi rundingan kaedah, sebarang pertukaran pengesahan yang dipilih, dan permintaan yang menamakan destinasi. Hanya balasan yang berjaya membuka laluan untuk bait aplikasi. Peringkat ini ditakrifkan dalam RFC 1928.

Kekalkan rundingan dalam lapisan sambungan

Aplikasi dengan protokol TCP sendiri boleh menggunakan penyambung yang sedar proksi yang mengembalikan strim yang telah ditubuhkan. Selebihnya aplikasi kemudian membaca dan menulis melalui strim itu. Penyambung mesti mengambil kira bacaan separa, alamat panjang boleh ubah, kegagalan pengesahan dan tarikh akhir untuk rundingan.

Pelaksanaan tulisan tangan yang membaca satu penimbal bersaiz tetap dan menganggap kejayaan adalah rapuh. TCP tidak mengekalkan sempadan mesej SOCKS. Baca balasan lengkap yang diterangkan oleh jenis alamatnya sebelum memulakan protokol aplikasi. Pembaca balasan CONNECT .NET 7+ menggambarkan langkah itu.

Jika pustaka yang diselenggara sudah menyediakan lapisan sambungan ini, semak versi SOCKS yang disokong, kaedah pengesahan dan rangka kerja sasaran. Pautan forum berusia sedekad ialah titik permulaan untuk penyiasatan, bukan bukti keserasian semasa.

Konfigurasi klien HTTP mempunyai skop berasingan

Tetapan proksi klien HTTP mengkonfigurasi klien HTTP itu. Ia tidak mengubah setiap soket mentah dalam proses. API Socket menerima titik akhir rangkaian dan menyerahkan rundingan peringkat lebih tinggi kepada pemanggil.

Untuk protokol aplikasi yang disulitkan, lakukan jabat tangan TLSnya selepas terowong proksi ditubuhkan. Sahkan identiti destinasi yang dimaksudkan pada peringkat itu. Pengesahan proksi dan pengesahan destinasi kekal berasingan walaupun ia menggunakan strim asas yang sama.