Tujuan asli dalam penerusan TCP ke SOCKS yang transparan

Firewall dapat mengubah ke mana koneksi TCP mendarat. Namun hanya dengan perubahan itu, ia tidak dapat mengajari aplikasi asal untuk berbicara SOCKS.

Server SOCKS biasa mengharapkan negosiasi yang menjelaskan tujuan yang diminta. Aplikasi yang tidak mengetahui proksi justru langsung mengirim byte protokolnya sendiri. Alihkan byte tersebut langsung ke pendengar SOCKS dan kedua pihak akan berselisih tentang pesan pertama.

Komponen yang hilang adalah penerjemah

Komponen transparan TCP ke proksi berada di antara antarmuka tersebut. Ia menemukan tujuan yang semula diminta aplikasi, membangun sesi SOCKS atau HTTP CONNECT yang sesuai, lalu meneruskan data aplikasi melalui aliran yang dihasilkan.

Pada jalur Linux iptables-nya, kode sumber redsocks mengambil tujuan yang dipertahankan menggunakan SO_ORIGINAL_DST. Sistem operasi dan metode pengalihan lain memakai mekanisme berbeda. Ini adalah sifat pengalih dan pengaturan jaringan, bukan fitur klien SOCKS biasa.

Informasi tujuan asli juga menjelaskan mengapa memindahkan aturan pengalihan dari hos proksi ke gateway yang tidak terkait tidak selalu setara. Proses penerima memerlukan metadata yang dituntut oleh mode penyadapannya. Alamat yang ditulis ulang di tempat lain mungkin tidak lagi menyediakan informasi itu dalam bentuk yang diharapkan.

Jaga cakupan penerjemah tetap eksplisit. Koneksi TCP teralihkan yang berfungsi tidak membuktikan dukungan untuk UDP sembarang, ICMP, atau setiap jalur penyelesai. Protokol proksi hulu dan implementasi penerjemah tetap menentukan operasi yang didukung.

Ketika penyiapan gagal tepat setelah koneksi, periksa batas protokol sebelum memperluas aturan akses. Pendengar SOCKS yang sangat mudah dijangkau dapat menolak byte yang tidak pernah merupakan permintaan SOCKS.