څنګه وګورو چې یو VPN کلاینټ واقعاً SSTP ملاتړ کوي
د وارداتو تڼۍ او پورټ 443 هېڅ ثابتولای نه شي. ذکر شوې پلي کول، د پروفایل بڼه، سند او PPP تصدیق وګورئ، بیا هره مرحله.
یو محصول ته VPN کلاینټ ویل هېڅ نه وایي چې هغه SSTP خبرې کوي که نه، او په پته کې د 443 پورټ شتون لا لږ ثابتوي. SSTP لومړی پر TCP 443 باندې TLS چلوي، بیا د SSTP کنټرول تبادله، بیا د لینک لپاره PPP، او پر سر د سند تصدیق او د PPP تصدیق طریقه. کلاینټ پروتوکول ته یوازې هغه وخت ملاتړ کوي چې ذکر شوې پلي کول په نصب شوې نسخه کې ستاسو د سرور غوښتنو سره سم هره طبقه بشپړه کړي. لاندې کتنې په ترتیب سره وکړئ او په لومړۍ ناکامه کتنه ودرېږئ، ځکه هماغه د حل وړ ده.
پلي کول، نسخه او پلیټ فارم سره ورته کړئ
د پلیټ فارم، اپلیکیشن او نصب شوي جوړښت څخه پیل وکړئ، ځکه یو د جوړونکي نوم کولای شي پر دوو بشپړو بېلو پلي کولو باندې وي. دننه شوي VPN ډولونه او دریم اړخ کلاینټونه یو شی نه دي، او پلګن کولای شي د اډاپټر نښه وښیي چې لاندې پروتوکول نه بیانوي. د اوسني خپرونې اسناد هغه جوړښت نه بیانوي چې ستاسو مخې ته په ماشین کې روان دی. نسخې ته ځانګړې پاڼه ولولئ، بیا یې د هغو سره پرتله کړئ چې کلاینټ د ځان په اړه وایي.
په Windows کې د تونل ډول له GUI نه نه، بلکې له پلیټ فارم څخه راځي، نو پلیټ فارم وپوښتئ. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress Sstp ښیي کله چې اصلي کلاینټ پروتوکول هڅه کوي، او د اړیکو ډولونو مرجع هغه د دننه شوو تونل ډولونو په منځ کې لیستوي. په Linux کې اصلي SSTP کلاینټ هېڅ نشته، نو پوښتنه دا کېږي چې آیا sstp-client بستې څخه د sstpc په څېر بېله پلي کول نصب او تازه دي.
له نښې مخکې د پروفایل بڼه ولولئ
پروفایلونه د بدلون وړ نه دي، او هغه فایل چې تاسو ته درکړل شوی معمولاً له هرې ځانګړنې لیست څخه ژر پوښتنه حل کوي. د OpenVPN لارښوونې، د WireGuard کیلي او د SSTP اړیکې تنظیمات درې نااړوند پروتوکولونه بیانوي، او هېڅ د وارداتو کړکۍ یو بل ته نه بدلوي. د TCP 443 پورټ شریکول هېڅ نه ژباړي، ځکه SSTP، پر TLS باندې OpenVPN او عادي HTTPS خدمت کولای شي هماغه پورټ ونیسي او د هغه پورته هېڅ ګډ نه لري.
که فایل .ovpn یا د WireGuard ترتیب وي، ځواب لا وړاندې روښانه دی: له هغه کلاینټ څخه نه غوښتل کېږي چې SSTP خبرې وکړي. هغه ته یوازې SSTP کوونکي کلاینټ ته واردول د پروفایل په مرحله کې ناکامېږي، له هرې پروتوکول خبرو اترو څخه ډېر مخکې.
TLS د ځای پرځای کولو په اړه څه نه ثابتوي
بشپړ شوی TLS لاس ورکول ثابتوي چې سرور سند لري، او هېڅ نه ثابتوي چې آیا ستاسو کلاینټ د صادروونکې زنځیر باور لري یا په هغې کې نوم سمون لري. تصدیق باید د ټاکل شوي سرور پر وړاندې بریالی شي، په دې کې هره خصوصي CA چې سازمان چلوي، او هغه کلاینټ چې د سند تېروتنو تېرولو وړاندیز کوي، تصدیق یې لرې کړی نه چې پروتوکول ملاتړ یې ترلاسه کړی. د زنځیر تصدیق او د نوم سمون دوه جلا ازموینې دي، او یوه بریالۍ ډېره کولای شي په بله کې ناکامه شي. دواړه د منلو معیارونو کې راځي، نه د ستونزو حل ضمیمه کې.
بیا د PPP تصدیق طریقه تایید کړئ، ځکه د EAP-TLS سره ځای پرځای کول هغه کلاینټ غواړي چې په PPP دننه سند وړاندې کولای شي، پداسې حال کې چې پر پټنوم ولاړه طریقه د هغې تبادلې ملاتړ غواړي. د سرور پته او پټنوم د سازمان ریښتینې اړتیا نه بیانوي، په ځانګړي ډول چېرې چې د هغې مخې ته دویم فکتور یا د وسیلې کتنه وي. له دې مخکې چې فکر وکړئ کلاینټ یې بشپړولای شي، وپوښتئ چې سرور کومه طریقه لازمي کوي.
غونډه په څلورو مرحلو تعقیب کړئ
وګورئ چې اړیکه څنګه څلور پولې تېروي: TCP او TLS سرور ته، د SSTP کنټرول تبادله، د PPP خبرې اترې، بیا هغه سرچینه چې تاسو واقعاً ورته اړتیا لرئ. هغه لاګ چې له TLS وروسته ودريږي بېله خرابي بیانوي له هغه چې په PPP کې دننه ودريږي، او دواړه بېلو مسؤلینو ته رسوي. د براوزر له خوا د کوربه وېب پاڼې لوډ کېدل یوازې دا ثابتوي چې یو څه پر 443 ځواب ورکړ، کوم چې په دې برخه کې ترټولو عامه غلطه مثبته ده. که هغه پاڼه لوډ شي او کلاینټ لا هم ناکامېږي، ستونزه له TLS پورته ده او وېب سرور مشکوک نه دی.
د ریښتینې خصوصي سرچینې او د نوم پلټنې سره پای ته ورسئ، ځکه هغه غونډه چې جوړېږي او هېڅ نه وړي په ډېرو حالت کړکیو کې د کار کوونکې په څېر ښکاري. ستاسو د اړتیا وړ سرچینې ته یوه بریالۍ غوښتنه هغه پوښتنه حل کوي چې آیکون یې نشي کولای.
کله چې ملاتړ نه وي، پلان بدل کړئ
که کلاینټ نشي کولای SSTP خبرې وکړي، منل شوی بدیل ترلاسه کړئ یا د سرور له مالک څخه هغه پروتوکول وغواړئ چې دواړه خواوې یې ملاتړ کوي. د ناڅرګندو انتخابونو ړنګول تر هغه چې واردات بریالي شي، هغه پروفایل جوړوي چې هېرې سره نه نښلوي، چې هماغه مړ پای ته وروستی لار ده. له ناڅرګندې سرچینې راغلی نصب کوونکی چې نړیواله مطابقت اعلانوي، ماشین ته نا-منل شوې باور لار زیاتوي او ډېری وخت د پلیټ فارم کلاینټ له هغه شي سره بدلوي چې سازمان یې تازه کولای نه شي. دواړه ګامونه حل نه دي، او دواړه له اصلي ستونزې څخه سخت ګرځېدونکي دي.
د مطابقت پوښتنه له فعالیت او د پای نقطې له ټاکلو جلا وګورئ، ځکه نژدې سرور بېکاره دی کله چې کلاینټ د هغه پروتوکول خبرې نشي کولای. د ځنډ تنظیم هغه مرحله نه جوړوي چې هېڅکله نه بشپړېږي.