یوازې IPv6 اړیکه، IPv4 خدمت: پر SOCKS پروکسي دې پل ووهي

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

دوه ساکټونه، دوه پته کورنۍ

SOCKS5 غوښتنه منزل په درېیو بڼو کې نوموي: لفظي v4 پته، لفظي v6 پته، یا هغه نوم چې پروکسي یې حل کړي۔ غوښتنه بیانوي چې پروکسي چېرته ونښلي، نه دا چې د کليانټ او پروکسي ترمنځ اړیکه څنګه ښکاري۔

دا د پتې ډولونه د یو پیغام دننه درې خپلواکې غوراوي وګڼئ۔ IPv6 له لارې د لاسرسي وړ پروکسي کولای شي د IPv4 منزل ساکټ پرانیزي هر کله چې فعاله IPv4 وتل ولري او د هغې تګلاره غوښتنه اجازه کړي۔ SOCKS5 مشخصات دوی پرته له دې چې د کليانټ ترانسپورت ته اشاره وکړي تعریفوي۔

کنټرول شوې SSH بېلګه

د SSH هوسټ واخلئ چې تاسو ته د کارولو اجازه لرئ، کوم چې پر IPv6 ځواب وایي او پخپله کولای شي هغه HTTPS خدمت ته ورسېږي چې یوازې پر v4 شتون لري۔ د OpenSSH متحرک فارورډنګ ستاسو پر ماشین یو ځایي SOCKS اورېدونکی ږدي، پداسې حال کې چې د ننوتلو ناسته پر v6 روانه وي۔

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

پورته هوسټ او حساب بېلګې دي، او loopback تړل اورېدونکی پر همدغه کمپیوټر ساتي۔ دا د وحشي کارت تړلو سره مه بدلوئ تر څو یو دفتر بې تصدیق پروکسي شریک کړي۔ ExitOnForwardFailure=yes د دې لپاره دی چې ناکام فارورډنګ ناسته پای ته ورسوي، نه دا چې په شالید کې غلې کمانډ روان پاتې شي۔

کله چې ناسته روانه وي، غوښتنه داسې ښکاري:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

د loopback اړیکه د IPv4 انټرنیټ لار نه ده۔ هغه څه چې ستاسو له ماشین څخه وځي د v6 له لارې د ننوتلو ناسته ده، او لرې اړخ هغه دی چې د منزل ساکټ پرانیزي۔ socks5h بڼه د نومونو حل هم هغه اړخ ته سپاري، کوم چې هغه وخت مهم دی چې کليانټ خپله IPv4 حل کوونکې لار نه لري۔

منزل په رښتیا څه ویني

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

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

دا DNS64 یا NAT64 نه دی

DNS64 د مصنوعي ریکارډونو سره ځواب وایي چې د v4 منزلونو ځای نیسي، او NAT64 پاکټونه د ټاکل شوې لارې په اوږدو کې بیا لیکي۔ هیڅ یو یې هم هغه څه نه بیانوي چې دلته پېښېږي، چېرته چې یوه ترانسپورټي خبره پای ته رسېږي او بله پیلېږي او هېڅ مصنوعي پته نتیجه نه تشرېح کوي۔ نو ځکه بریالۍ غوښتنه ستاسو د وړاندې کوونکي د ژباړې خدمتونو په اړه هېڅ نه وایي، او پروکسي کولای شي په خپل وتل کې عادي NAT وچلوي۔

دواړه میکانیزمونه کولای شي په یوه شبکه کې وي، نو هغه یې بیان کړئ چې واقعاً مو تصدیق کړی، نه هغه چې تر ټولو نږدې اورېدل کېږي۔

ژمنه کولو دمخه حد وپیژنئ

د OpenSSH متحرک فارورډنګ TCP اړیکې وړي، نه خپل سره IP ترافیک، نو UDP، ICMP او هر هغه پروتوکول چې پروکسي له پامه غورځوي بل ملاتړ شوی ډیزاین ته اړتیا لري۔ SSH د هوسټ کیلي تصدیق، د سرور د فارورډنګ محدودیتونه او د HTTPS سند اعتبار وساتئ، ځکه چې پروکسي یو اضافي باوري برخه وال دی، نه د هویت څېړنو د کمزوري کولو لامل۔ که هدف د VPN بهرنی ترانسپورت د پروکسي له لارې وړل وي، نو د دې پرځای چې فکر وکړئ هر SOCKS اورېدونکی یې لېږدولی شي، تصدیق کړئ چې دواړه پایونه هغه ترانسپورت ملاتړ کوي۔

له دې څخه هیڅ یو کليانټ دوه ګونی سټیک نه کوي، او د هغې اړتیا هم نه ده۔ دا یو اپلیکیشن د یو لېږدوونکي له لارې یو خدمت ته رسوي، کوم چې کوچنی ادعا ده او تصدیق یې ډېر اسانه دی۔