یو کاروونکی وصل کیدای شي او بل نه، د هماغې دروازې له لارې، په هماغه ورځ۔ دواړه د سرور سره تړلي پروفایلونه لري، دواړه په یوه Access Server جوړښت کې دي، او یوازینی توپیر دا دی چې د هغوی پروفایل کله جوړ شوی۔ دا هغه بڼه ده چې پیژندل یې ارزښت لري، ځکه "د سرور سره تړلی" د نښلونې ترتیب نه، بلکې تګلاره نوموي۔ Access Server د هغه اثر دوه نسلونه خپاره کړي دي، او د TLS معکوس پروکسي د هغوی یوې لارې مخې ته یوازې ولاړ دی۔ تاسو په کومه څانګه کې یاست، درې شرطونه یې ټاکي۔

دوه نسلونه، دوه نښلونې ترتیبونه

په زوړ ډیزاین کې، چې تر 2.8 پوري روان دی، وارد شوی فایل یو نیمګړی پروفایل دی۔ OpenVPN Connect هغه د HTTPS له لارې د Access Server ویب API په وړاندې د تصدیق لپاره کاروي، یو لنډمهاله کاروونکي ته تړلی پروفایل او د غونډې ټوکن ترلاسه کوي، او بیا وروسته VPN جوړوي۔ دوه انتقالونه په ترتیب سره کار کوي، او لومړی یو عادي ویب غوښتنه ده۔

هغه بڼه چې له 2.9 سره معرفي شوه، هغه د هرې نښلونې پیل نه ترسره کوي۔ دا یو اصلي پروفایل دی چې همغږي OpenVPN مراجعین یې کارولی شي، نه یوازې OpenVPN Connect۔ د هغه ډاونلوډ یا د URL له لارې واردول لاهم کیدای شي HTTPS ولري — دا د خپرولو ګام دی، نه د هرې نښلونې لپاره د لنډمهاله پروفایل راوړل۔

Older server-locked (≤2.8)Newer server-locked (2.9+)
Before the tunnelWeb API call with credentialsNothing; the profile is already local
Client requirementOpenVPN ConnectAny compatible client
What a TLS web proxy can breakThe bootstrap, before any VPN attemptDownload only, not the connection
Expected HTTP log on connectA request from the clientOften nothing at all

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

درې شرطونه چې ستاسو څانګه ټاکي

لومړی شرط د اثر نسل دی۔ فایل وغواړئ، وګورئ چې څنګه جوړ شو، او هغه مراجع نسخه ولیکئ چې هغه یې وارد کړ۔ که له فایل څخه نسل ونه توانیدل شي، د ازموینې حساب لپاره صادر شوی نوی پروفایل به تاسو ته ووایي چې سرور ننګه څه تولیدوي، او دا له هغې معلوماتو توپیر لري چې ناکام کاروونکی یې لري۔

دویم شرط دا دی چې ستاسو مخکینې برخه واقعاً څه پای ته رسوي۔ اومې طبقې HTTP معکوس پروکسي چې TLS ښکته کوي د څلورمې طبقې TCP لېږدونکي په څېر شی نه دی، او UDP لېږدونکی هم نه دی۔ په 443 پورټ کې د Access Server عادي ترتیب د OpenVPN TCP ډیمون هڅوي چې د لټونکي ترافیک وپیژني او ویب خدمتونو ته یې وسپاري، نو د مخې ته د بېربط HTTPS پای ته رسوونکي ایښودل د هغه ډیمون پروتوکول سمبالول نه ساتي۔ د 443 شمېرې شریکول دوه ډیزاینونه مساوي نه کوي۔

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

کله چې اثر زوړ وي: پیل لومړی ناکاميږي

د مراجع پای حالت نه، بلکې ریښتینی تېروتنه یې ولولئ۔ د پام وړ ساحې HTTPS تېروتنه، هغه سرور هویت چې مراجع یې تمه درلوده، هغه منزل چې غوښتنه ورته لاړه، او دا چې ایا د سند تصدیق بشپړ شو۔ بیا هغه د سرور خوا ویب خدمت او پروکسي لاګونو سره پرتله کړئ۔

د لټونکي رسیدل د ننوتلو پاڼې ته دا ثابتوي نه چې د دې مراجع API تصدیق بریالی شو۔ دا بېلابېلې غوښتنې دي، د بېلابېلو سند تمې او ډېری وختونه بېلابېلو کوربه نومونو سره۔ که دروازه سمه وړاندې شي او مراجع لاهم ناکام شي، اختلاف د پیل په لاره کې دی، نه د کاروونکي په پټنوم کې۔

پرته له دې چې TLS تصدیق بند کړئ یا تصدیق تګلاره نرمه کړئ، پرتله بریالۍ مه کوئ۔ دا د تشخیص وړ ترتیب ناسمونې په داسې لاره بدلوي چې کار کوي خو تصدیق شوې نه ده، او هماغه بدلون دی چې لنډمهالې ازموینه تلپاتې سوري ته اړوي۔ د Access Server د نښلونې پروفایلونو اسناد دواړه نسلونه او د لنډمهاله پروفایل بهیر بیانوي، او هغه حواله ده چې باید د پروکسي په غلطۍ شک کولو دمخه وګورئ۔

کله چې اثر نوی وي: پرځای یې کنټرول چینل ولولئ

د 2.9 سټایل پروفایل سره مراجع مستقیم اصلي VPN پای نقطې ته ځي۔ په پروفایل کې پای نقطې، کارول شوی انتقال، او د کنټرول چینل تېروتنه وپلټئ۔ که مراجع هیڅکله HTTP غوښتنه نه صادروي، دا له ډیزاین سره سمون لري او نښه نه ده۔

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

د یو جریان لپاره TLS تېریدل یوه تنګه ترتیبه ده۔ دا UDP لېږد نه برابروي، او په 443 کې د ډیمون خپل د خدمتونو لېږد چلند بیا نه تولیدوي۔ که ستاسو مخکینې برخه له دې یو کار کوي، ووایاست کوم، ځکه درملنه توپیر لري۔

هغه درملنې چې تنګې پاتې کیږي

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

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

بیا د خپرولو ترتیب سم کړئ ترڅو هر اړین لار شتون ولري: د ډاونلوډونو او دروازې کارولو لپاره ویب لار، او په هغه انتقال کې اصلي VPN لار چې پروفایلونه یې تمه لري۔ د پروکسي کار په یوه طبقه کې وساتئ۔ کار کوونکې کاروونکي ته تړلې تونل ثابتوي چې هغه لار کار کوي؛ دا نه ثابتوي چې هر پروکسي ترتیب هر نسل ملاتړ کوي، او د زوړ پیل ناکامي نوې بڼه نه غندي۔

  • د پروکسي لمس کولو دمخه د اثر نسل وپیژنئ۔
  • ټاکئ چې ناکامي د تونل څخه مخکې ده که په هغه کې۔
  • تایید کړئ چې مخکینې برخه څه پای ته رسوي: HTTP، TCP جریان، یا UDP۔
  • نوی صادر شوی پروفایل د بدل شوې تګلارې پرته د اصلي پای نقطې په وړاندې وآزمویئ۔

اړوندې مقالې