د OpenVPN لپاره SOCKS5 پراکسي: TCP تونل که اپلیکیشنونه پراکسي کول؟
پراکسي یو بهیر لیږدوي، نه ډیټاګرام. د socks-proxy شاته TCP تونل د redsocks لېږد سره پرتله کړئ او وګورئ چې هر ډیزاین لومړی چېرته ناکامېږي.
هغه شبکه چې یوازې د پراکسي له لارې وتل اجازه ورکوي، هغه ځای دی چې یو فعال پروفایل ناڅاپه مري۔ د پراکسي پته په هغه ناکامي کې تر ټولو کمه زړه راښکونکې بدله ده۔ هر څه د هغه ترافیک بڼه فیصله کوي چې پراکسي به یې لیږدوي، ځکه چې دا پراکسي د بایټ بهیر لیږدوي او UDP تونل داسې نه دی۔ دا دوه معماری پاتې کوي، او دوی په بېلو ځایونو کې ماتېږي۔
یو محدودیت ډیزاین فیصله کوي
SOCKS5 واقعاً د UDP اتحادیې حالت ټاکي۔ سره له دې OpenVPN کلاینټ د پراکسي ملاتړ د بهیرونو شاوخوا جوړ شوی دی: socks-proxy د TCP پروفایلونو لپاره مستند شوی، او د HTTP CONNECT پراکسي د ډیټاګرامونو لپاره هیڅ لاره نه لري۔ د اسنادو یوه کرښه معماري فیصله کوي، مخکې لدې چې د ترتیباتو فایل ته لاس ووهئ۔
نو پوښتنه دا نه ده چې کوم پراکسي غوره کړئ۔ پوښتنه دا ده چې تونل بهیر کیږي، که ډیټاګرام پاتې کیږي او بل څه ته اجازه ورکوي چې پراکسي کول جذب کړي۔
اختیار A: تونل په بهیر بدل کړئ
دا د TCP اورېدونکي سره سرور او د پراکسي نومونکې کلاینټ پروفایل ته اړتیا لري۔ دواړه برخې اړینې دي، او هغه برخه چې خلک یې هېروي د سرور خوا ده:
proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080وروستۍ کرښه په http-proxy proxy.internal 8080 بدله کړئ کله چې پراکسي HTTP وایي، او که وغواړي د اعتبارنامې فایل ورزیات کړئ۔ پراکسي باید چمتو وي چې ستاسو د VPN پورټ ته CONNECT وکړي، او سرور باید په TCP ځواب ووایي؛ یوازې UDP اورېدونکی هغه هڅه له پامه غورځوي۔ 443 غوره کول یو عملي ګام دی، ځکه چې ډېرې محدودې شبکې هغه او لږ بل څه اجازه ورکوي۔
لګښت دا دی چې TCP پر TCP کیږي۔ یوه ورکه شوې بهرنۍ برخه هره داخلي بهیر چې هغه اړیکه شریکوي بندوي، نو هغه بیا رغونه چې معمولاً خپلواکه وي شریکه کیږي۔ ترتیب هم ډېر وخت نیسي، او یو بې ثباته بهرنی لار بې ثباته تونل کیږي نه ورو۔
اختیار B: تونل یوازې پرېږدئ
کله چې تونل باید په UDP پاتې شي، تونل هغه ځای نه دی چې تاسو پکې څه ترتیب کړئ۔ پرځای یې له اپلیکیشنونو وتونکی TCP یو ځایي SOCKS اورېدونکي ته لېږل کیږي، او اپلیکیشنونه هېڅکله نه پوهیږي چې پراکسي شته۔ په Linux کې دا معمولاً redsocks او په nat جدول کې د NAT REDIRECT قاعده وي۔
بیا هم یوازې TCP۔ یوازې-HTTP پراکسي لکه privoxy نشي کولای خپل سري پروتوکولونه لیږدوي، او دا ډیزاین هم اپلیکیشنونو ته د ډیټاګرام ملاتړ نه ورزیاتوي۔
هر اپلیکیشن ته مستقیم د پراکسي په اړه ویل معمولاً غوره دي هلته چې سافټویر ملاتړ کوي۔ د هغې پلټنه اسانه ده، او په هغه ځای کې ناکامېږي چې تاسو واقعاً لیدلی شئ۔
هر اختیار چېرته ناکامېږي
اختیار A ناکامېږي کله چې سرور د TCP اورېدونکی نه لري، کله چې پراکسي د CONNECT هدف ردوي، یا کله چې بهرنی بهیر د تونل له اړتیا لاندې محدود شي۔ لومړي دوه د پراکسي لاګ کې ننوتنه پرېږدي؛ دریم یې هغه اړیکه پرېږدي چې جوړېږي او بیا غلطه احساسېږي۔ د پروفایل د سمون مخکې هغه لاګ ولولئ، ځکه چې دا د اجازې ستونزه د ظرفیت ستونزې څخه بېلوي۔ بشپړ شوی CONNECT پلټنه د تونل دننه باسي۔
اختیار B هغه هر څه لپاره ناکامېږي چې ډیټاګرام ته اړتیا لري، هغه پروتوکولونو لپاره چې پراکسي نه پوهیږي، او په خاموشۍ هغو کوربه وو کې چې لېږد قاعده پکې شته خو لارښوونه ترافیک د هغې ترڅنګ لیږي۔
هیڅ اختیار د وسیلې اړتیا نه بدلوي۔ کڅوړو ته لا هم TUN یا TAP نوډ ته اړتیا ده مخکې لدې چې کرنل یې لارښوونه وکړي، نو بهیر ته لا هم /dev/net/tun باندې اجازه ته اړتیا ده۔ یو پوښ بدلوي چې هغه نوډ پرانیستل شو وروسته څه پېښیږي، نه دا چې تاسو ورته اړتیا لرئ که نه۔
ثابت کړئ چې کومه لار مو جوړه کړه
د ټري آیکون پرځای ساکټونه وګورئ۔ VPN بهیر باید د پراکسي پتې سره جوړه شوې اړیکه وساتي، او پراکسي باید هغه هدف لاګ کړی وي چې رسېدل ورته ویل شوي وو:
ss -tnp | grep openvpnبیا هغه منزل ته ورسیږئ چې یوازې تونل یې خدمت کولی شي، او هغه نوم ته چې یوازې د تونل حلکوونکی ځواب ویلای شي۔ د مړ تونل سره بشپړه پراکسي اړیکه معمولاً مانا دا ده چې لرې پای ستاسو په پروفایل کې نومول شوی انتقال هېڅکله وړاندې نه کړ۔
انتقال او منونکی پراکسي په یوه پایښتناکه ځای کې یادښت کړئ۔ کله چې هماغه پروفایل په بله شبکه کې ناکام شي، هغه یادښت په ثانیو کې پراکسي بېل یا تاییدوي۔