Destinasi asal dalam penghantaran TCP ke SOCKS yang telus

Tembok api boleh mengubah ke mana sambungan TCP mendarat. Namun dengan perubahan itu sahaja ia tidak boleh mengajar aplikasi asal bertutur SOCKS.

Pelayan SOCKS biasa menjangka rundingan yang menerangkan destinasi yang diminta. Aplikasi yang tidak mengetahui proksi sebaliknya menghantar bait protokolnya sendiri serta-merta. Ubah hala bait itu terus ke pendengar SOCKS dan kedua-dua pihak tidak akan bersetuju tentang mesej pertama.

Komponen yang hilang ialah penterjemah

Komponen telus TCP-ke-proksi terletak antara antara muka itu. Ia menemui destinasi yang diminta asal oleh aplikasi, mewujudkan sesi SOCKS atau HTTP CONNECT yang sesuai, kemudian menyampaikan data aplikasi melalui aliran yang terhasil.

Pada laluan Linux iptablesnya, sumber redsocks mengambil destinasi terpelihara menggunakan SO_ORIGINAL_DST. Sistem pengendalian dan kaedah ubah hala lain menggunakan mekanisme berbeza. Ini sifat pengubah hala dan persediaan rangkaian, bukan ciri klien SOCKS biasa.

Maklumat destinasi asal juga menerangkan mengapa memindahkan peraturan ubah hala daripada hos proksi ke get laluan yang tidak berkaitan tidak selalunya setara. Proses penerima memerlukan metadata yang dituntut oleh mod pemintasannya. Alamat yang ditulis semula di tempat lain mungkin tidak lagi menyediakan maklumat itu dalam bentuk yang dijangka.

Kekalkan skop penterjemah secara jelas. Sambungan TCP terubah hala yang berfungsi tidak membuktikan sokongan untuk UDP sewenang-wenangnya, ICMP atau setiap laluan penyelesai. Protokol proksi huluan dan pelaksanaan penterjemah masih menentukan operasi yang disokong.

Apabila persediaan gagal sejurus selepas sambungan, periksa sempadan protokol sebelum meluaskan peraturan akses. Pendengar SOCKS yang boleh dicapai sepenuhnya pun boleh menolak bait yang tidak pernah menjadi permintaan SOCKS.