غوښتنلیک SOCKS ته اړتیا لري. ستاسو منل شوې پورتنۍ خدمت HTTP CONNECT مني. د HTTP پای ټکی د غوښتنلیک په SOCKS څنډه کې ایښودل د پروتوکولونو ترمنځ ژباړه نه کوي.

ګیټوې کولای شي له غوښتنلیک څخه SOCKS ومني، غوښتل شوی هدف ولولي او د هغه هدف لپاره د HTTP والد څخه CONNECT تونل وغواړي. بیا د غوښتنلیک بهیر د تونل له لارې تېروي.

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

هره برخه څرګنده کړه

د دې ترتیباتو ملاتړ کوونکې ګیټوې لپاره د هغې د والد ډول مهم دی. د 3proxy اسناد connect والد له هغه والد څخه بېلوي چې د عادي HTTP لېږدونکي پراکسي په توګه کارول کیږي.

د موجود 3proxy کارونکي او تصدیق سره، یوازې-ځایي لارښوونې ټوټه کولای شي دا بڼه ولري:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

دا ټوټه فرض کوي چې حساب لا دمخه تعریف شوی. دا د HTTP والد خپله غوښتل شوې کومه اعتبارنامه نه ورزیاتوي او موجوده لاسرسي تګلاره نه بدلوي. د عامه هدفونو لپاره په هغه لار چې بې تصدیقه عامه HTTP والد ته اجازه ورکوي، د HTTP پراکسي لیست د کوربه او پورټ نوماندان وړاندې کوي. د دې څانګې لپاره د والد اعتبارنامه غایبه پرېږده او د ریښتیني هدف لپاره اجازه تایید کړه؛ د ګیټوې خپل حساب ځایي پاتې کیږي. د parent قاعده د 3proxy د مستند شوي ترتیب ماډل له مخې له مخکینۍ allow قاعدې سره تړلې ده.

غوښتنلیک ځایي SOCKS پای ټکی کاروي. ګیټوې د والد په لور HTTP CONNECT کاروي. غوښتل شوی هدف کوربه او پورټ اجازه لري که نه، دا لا هم والد فیصله کوي.

دلته ګټوره حوزه د عادي TCP بهیر تونل دی. د SOCKS5 UDP یوځایوالی یوازې د دې لپاره چې مخکینی اورېدونکی SOCKS5 مني ملاتړ شوی نه کیږي. د HTTP CONNECT والد اړین UDP ریلې په اتوماتيک ډول نه برابروي.

HTTPS کولای شي په دې لار کې له سره تر سره پاتې شي؛ د پراکسي برخو ترمنځ ژباړه د هدف وېبسایټ د impersonation غوښتنه نه کوي. ګیټوې، والد او وېبسایټ ته تصدیق بیا هم بېلې اعتبارنامې او تبادلې پاتې کیږي.

اړوندې مقالې