OpenVPN لا 443 پورټ باندې لا هم بند دی؟ وګورئ چې شبکه څه ګوري

ټنل د کور له لین څخه نښلول کېږي او په هوټل یا دفتر شبکې کې درېږي، او سرور 443 پورټ ته لېږدول هیڅ ونه بدلول۔ دا پایله دومره عامه ده چې یوه بڼه لري: پورټ اسانه برخه وه، او پاتې پرېکړه هر هغه څه ته اړه لري چې د پیرودونکي او سرور ترمنځ ناست دي۔ دوه پوښتنې ډېرې پېښې حل کوي، او هېڅ یوه یې د سایفر په اړه نه ده۔ ایا شبکه دې پتې ته د TLS لاس نیول مني، او ایا پیرودونکی تر هغه چې ټنل پورته وي خپل پوښ ته مسیر ساتي؟

لاس نیول له شمېرې ډېر څه بربنډوي

په TCP 443 کې اصلي VPN اورېدونکی له لومړي بنډل څخه په خپل پروتوکول خبرې کوي۔ ClientHello د نسخې ساحه، تصادفي ارزښت او د غزونو لړلیک لري، او هغه وسیله چې څو سوه بایټه لولي پرته له کوم ډیکرېپشن توپیر پېژندلی شي۔ د پورټ شمېرې بشپړول ارزانه دي، او فلټر په رښتیا د پروتوکول بڼه ګوري۔ قاعدې معمولاً د پروتوکول له مخې هم لیکل کېږي، نو هغه تګلاره چې TLS ګوري د UDP په اړه هېڅ نه وایي۔

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

د بهیر پوښول دوه د ناکامۍ نقطې جوړوي

د stunnel په څېر TLS پوښ تمه شوې بڼه بېرته راولي: پیرودونکی له سیمه ییز اورېدونکي سره نښلول کېږي، پوښ له سرور سره په 443 کې ریښتینې TLS ناسته پرانیزي، او په سرور کې دویم پوښ ډیکرېپټ شوي بایټه VPN ډیمون ته رسوي۔ بهرنۍ ناسته اوس د هر بل HTTPS نښلون په څېر ښکاري۔ په سرور کې VPN ډیمون باید یوازې په loopback واوري، ځکه له پوښ بهر هېڅ شي ته اړتیا نشته چې هغه ته ورسيږي۔

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

پوښ ته لار پخپله دام دی

کله چې ټنل پورته شي، تلواله لار هغه ته اشاره کوي، او بهرنۍ TLS ناسته ته داسې لار پکار ده چې هغه ټنل ته نه ننوځي چې دا یې وړي۔ عادي VPN پیرودونکی هغه پته ساتي چې هغه ته زنګ وهی؛ پوښ شوی پیرودونکی خپل loopback ته زنګ وهی، نو د پوښ منزل پته دې ساتنې ته نه ښکاري۔

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

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

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

تر بدلون مخکې وخت ولولئ

هغه ناسته چې هربار وروسته له هماغې وقفې مري، د تګلارې لاسلیک دی نه د کریپټوګرافي ناکامي، او اوږدمهاله بهیر محدودیتونه هماغه بڼه جوړوي۔ هغه اړیکه چې سمدلاسه وروسته له لاس نیول بیا تنظیم شي، هغه پراکسي ته اشاره کوي چې د سندونو لړلیک یې خوښ نه شو۔

د دواړو شبکو څخه د یوې عادي HTTPS وېبپاڼې د سند صادرونکی پرتله کړئ۔ که په محدودې شبکه کې صادرونکی توپیر ولري، یو څه په منځ کې TLS پای ته رسوي، او هېڅ پوښ به هغه خنډ پرته له بدلون پاس نه کړي۔ هماغه پرتله تاسو ته وایي چې بند ستاسو د سرور نوم په نښه کوي که په هغه پته هره TLS ناسته۔

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

په یوه وخت کې یو بدلونکی وآزمویئ

لومړی UDP وګورئ، ځکه ځینې شبکې هغه په بشپړه توګه غورځوي او د UDP ناکامي د 443 په اړه هېڅ نه وایي۔ بیا پرته له پوښ TCP 443 وآزمویئ، بیا په 443 پوښ۔ په هر قدم کې د پیرودونکي لاګ ولولئ او څومره ژر چې چلند بدل شي ودريږئ۔

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