UDP د Tor د SOCKS پورت له لارې: څه نه تېرېږي

یو اپ ته د SOCKS پورت په نښه کول براوزر لپاره کار کوي او لوبې لپاره ناکامېږي، او لامل کنفیګریشن نه دی۔ SOCKS5 څو کمانډونه تعریفوي، او پلي کول آزاد دي چې یوازې ځینې یې ملاتړ وکړي؛ د Tor انټرفیس د جریان اړیکې او د نومونو حل مني، نه خپل سري ډیټاګرام لېږد۔ هغه کلاینټ چې UDP لېږي او تمه کوي چې پراکسي یې ولېږدوي، داسې کمانډ غواړي چې سرور یې نه پلي کوي۔ لاندې لارښود دا په څو دقیقو کې پلټي او بیا هغه ټرانسپورټ ټاکي چې واقعاً کار کولی شي۔

وګورئ چې اپ واقعاً څه لېږي

د پروتوکول نوم نه، د ټرانسپورټ په پېژندنې پیل وکړئ۔ غږیز کلاینټ کولی شي د HTTPS له لارې ننوځي او بیا میډیا د UDP له لارې ولېږدوي؛ لوبه کولی شي د TCP له لارې تصدیق وکړي او د UDP له لارې وکړي؛ د فایل لېږد کولی شي د کنټرول لپاره TCP او د موندنې لپاره UDP وکاروي۔ لومړنۍ دوه چلندونه تر هغو یو شان ښکاري چې ننوتل بریالي شي او زنګ لا هم ناکام شي، له همدې امله «وصل شو» د دې ثبوت نه دی چې ټول اپ کار کوي۔ ځینې کلاینټونه پخپله له UDP څخه TCP ته بېرته ځي، چې نیمګړی کارکوونکی سیشن د بند شوي ټرانسپورټ پر ځای د بې ثباته شبکې په څېر ښکاره کوي۔

د هغې برخې لپاره چې ناکامېږي د موخې پورت او ټرانسپورټ ولیکئ۔ همدا یوه کرښه پرېکړه کوي چې پراکسي په بشپړه توګه مرسته کولی شي که نه۔

د Tor SOCKS انټرفیس به څه ومني

Tor د جریان اړیکو لپاره د SOCKS5 CONNECT کمانډ او د نومونو د حل لپاره د پراخېدو کمانډونه پلي کوي، له همدې امله براوزر پرته له بدلون له هغې تېرېږي۔ UDP ASSOCIATE، هغه کمانډ چې کلاینټ ته اجازه ورکوي ډیټاګرامونه پراکسي ته د لېږد لپاره وسپاري، د هغه څه برخه نه ده چې Tor یې وړاندې کوي۔ د پراخېدنو اسناد د پروژې په SOCKS د پراخېدنو مشخصات کې دي، او لنډ دي۔ د ډیټاګرام کمانډ نه شتون قصدی دی: خپل سري UDP لېږد به شبکې ته داسې لېږدونکې رول ورکړي چې هغه هرګز د هغې لپاره نه و ډیزاین شوی۔

دا د WireGuard لپاره هم ځواب دی، کوم چې د ډیزاین له مخې UDP دی او د TCP بېل بدیل لاره نه لري۔ هېڅ ملاتړ شوې لاره نشته چې WireGuard د SOCKS پورت ته ګوته ونیسي، او هر هغه څه چې خلاف یې ادعا کوي د دوو وسیلو له یوې ځانګړتیا نه، بلکې د خپل باور او ساتنې کیسې سره یو پوښ دی۔

OpenVPN جزوي استثنا ده، ځکه چې د TCP له لارې د تونل لپاره تنظیمېدلی شي او د SOCKS پراکسي اختیار پوهېږي۔ دا بیا هم د TCP لپاره تنظیم شوی سرور او د کارکرد او د ګوتې نښې په پایلو کې پوهاوی لازمي دي، نو دا د ډیزاین انتخاب دی، نه د مطابقت سمون۔

پلټنه په ترتیب سره پر مخ یوسئ

لومړی تایید کړئ چې پراکسي د جریانونو لپاره کار کوي، تر څو وروسته ناکامي په نه رسېدونکي پورت ونه نښلول شي۔ بیا د اپ خپله ترافیک تایید کړئ او وګورئ چې په رښتیا کوم ساکټونه خلاصوي۔

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

بریالي لومړی کمانډ او په دویمه کرښه کې جوړ شوی جریان ښیي چې د پراکسي لاره لکه څنګه چې ډیزاین شوې کار کوي۔ درېیم کمانډ د اپ پورې اړوند محلي ډیټاګرام ساکټونه لټوي؛ که کلاینټ یو خلاص کړي او مستقیم لرې پتې ته ولېږي، نو هغه هرګز له پراکسي سره نه دی مشوره کړې او هېڅ د پراکسي تنظیم به یې نه بدلوي۔ که په لومړي ګام کې ناکام شي، ودروئ او د اپ پلټنې دمخه د پراکسي لاره سمه کړئ، ځکه چې په یو وخت کې دوه خرابۍ داسې راپور جوړوي چې هیڅوک پرې اقدام نه شي کولی۔

بېرته وګرځئ او سمه وسیله وټاکئ

هر هغه د پراکسي چاپېریال متغیر یا د هر اپ لپاره د پراکسي تنظیم لرې کړئ چې UDP کلاینټ یې SOCKS پورت ته ګوته نیولی و؛ د هغوی پاتې کول وروسته ازموینې مبهموي۔ د یوې کاپي څخه پخوانی کنفیګریشن بیا جوړ کړئ، اپ بیا پیل کړئ او تایید کړئ چې اصلي چلند بېرته راځي تر څو پرتله پاکه وي۔ هغه بېرته ګرځېدنه چې نه تاییدېږي یوازې دا هیله ده چې حالت بدل شوی۔

د هغه ټرانسپورټ لپاره چې باید UDP پاتې شي، VPN معمولاً ډېر مناسب دی: دا د اپ پیکټونه لېږدوي پرته له دې چې اپ ته ووایي د پراکسي پروتوکول وکاروي، د بشپړ توپیر لرونکې ناشناسۍ ځانګړتیاوو په بیه۔ هر وسیله د هغه څه لپاره چې اسناد یې کوي وکاروئ، او د هغوی تر منځ هر پل د جلا سیسټم په توګه وګڼئ چې خپله بیاکتنه غواړي۔ په پای راپور کې ولیکئ چې کومه طبقه کوم ټرانسپورټ لېږدوي، تر څو بل کس د بل اپ سره هماغه پوله بیا کشف نه کړي۔