اصلي منزلونه په روڼ TCP-څخه-SOCKS لېږد کې
تشريح کوي چې ولې روڼ TCP-څخه-SOCKS لېږد داسې ژباړونکي ته اړتیا لري چې د پروکسي سره له خبرو اترو مخکې اصلي منزل بېرته ترلاسه کوي.
یو اور وژونکی کولای شي بدل کړي چې د TCP اړیکه چېرې کښېني. خو یوازې په دې بدلون نشي کولای اصلي اپلیکیشن SOCKS ویناوالۍ ته زده کړي.
عادي SOCKS سرور هغه خبرې اترې تمه کوي چې غوښتل شوی منزل بیانوي. هغه اپلیکیشن چې د پروکسي په اړه نه پوهېږي پرځای یې سمدلاسه خپل پروتوکول بایټونه لېږي. که هغه بایټونه مستقیم SOCKS اورېدونکي ته واړوئ، دواړه خواوې به د لومړي پیغام په اړه سره یو نه شي.
ورک شوی برخه یو ژباړونکی دی
د روڼ TCP-څخه-پروکسي برخه د هغو انټرفېسونو ترمنځ ده. هغه منزل مومي چې اپلیکیشن په لومړي سر کې غوښتی و، مناسب SOCKS یا HTTP CONNECT ناسته جوړوي، او بیا د جوړ شوي بهیر له لارې د اپلیکیشن ډاټا لېږدوي.
په خپله Linux iptables لاره کې، د redsocks سرچینه ساتل شوی منزل د SO_ORIGINAL_DST په مرسته ترلاسه کوي. نور عملیاتي سیستمونه او د بیا لارښوونې نورې طریقې بېل میکانېزمونه کاروي. دا د لارښوونکي او د شبکې تنظیم ځانګړنه ده، نه د عادي SOCKS کړنې.
د اصلي منزل معلومات دا هم تشريح کوي چې ولې د بیا لارښوونې قاعده له پروکسي کوربه څخه بې اړیکې دروازې ته لېږدول تل برابر نه وي. د ترلاسه کوونکي پروسې ته هغه میټاډاټا غواړي چې د هغې د نیولو طریقه یې غواړي. کېدای شي په بل ځای بیا لیکل شوی پته هغه معلومات نور په تمه شوې بڼه ورنه کړي.
د ژباړونکي پوره ساحه روښانه وساتئ. یوه فعاله بیا لارښوونې شوې TCP اړیکه د خپل سري UDP، ICMP یا هر حل کوونکي لارې لپاره ملاتړ نه ثابتوي. د لوړ پروکسي پروتوکول او د ژباړونکي پلي کول لاهم ملاتړ شوې عملیات ټاکي.
کله چې تنظیم سمدلاسه وروسته له اړیکې ناکام شي، د لاسرسي قواعدو د پراخولو دمخه د پروتوکول پوله وګورئ. یو بشپړ د لاسرسي وړ SOCKS اورېدونکی کولای شي هغه بایټونه رد کړي چې هیڅکله SOCKS غوښتنه نه وه.