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

له هغه ځایه پیل کړئ چې کلاینټ ولاړ شي

کلاینټ یو ټاکلی ترتیب تېروي: د 443 پورټ TCP اړیکه، TLS لاس نیول، د سند تایید، د SSTP HTTP تبادله، PPP خبرې او تصدیق، بیا IP ترتیب۔ هر پړاو کې ناکامي بېله نښه پرېږدي، او د هغوی ګډول تاسو ناسم ترتیبي پاڼې ته رسوي۔

TCP ناکامي د یوې مودې پای یا بیا تنظیم دی چې د TLS له هر بایټ مخکې وي۔ TLS ناکامي خبرداری یا د لاس نیولو د مودې پای دی۔ د سند ناکامي د زنځیر یا نوم په اړه خبرداری ورکوي۔ HTTP ناکامي د بریالي لاس نیولو وروسته راځي، ډېری وخت د حالت کوډ یا سملاسي بندیدو په بڼه۔ PPP ناکامي وروسته له هغه راځي چې تونل تخنیکي توګه جوړ شو، نو ځکه د تصدیق ستونزه ښکاري۔

د لومړي تېروتنې کرښې پرځای د کلاینټ ثبت کې وروستی بریالی پړاو ولولئ۔ د تېروتنې کرښه معمولاً پایله ښیي، پداسې حال کې چې د پړاو پوله د هغه برخې نوم اخلي چې رد کړی یې دی۔

SSTP له شبکې څه غواړي چې یې وړي

SSTP د TCP 443 په TLS باندې چلیږي او بیا د SSTP_DUPLEX_POST په نامه HTTP غوښتنه چې په SSTP مشخصاتو کې تعریف شوې، /sra_{GUID}/ بڼې لارې ته لیږي۔ غوښتنه په عمل کې بې حده منځپانګه اوږدوالی اعلانوي او د غونډلې په ټول ژوند کې جریان دواړو خواوو ته پرانیستې ساتي۔ PPP چوکاټونه د همدې جریان دننه سفر کوي۔

له همدې امله عادي لټون کونکی پراکسي هم ناکام کیدای شي۔ محدود بدن لرونکې GET یا POST کیدای شي بفر، وپلټل او مخته ولېږل شي؛ هغه دوه اړخیز جریان چې بدن یې هیڅکله نه تمامیږي نشي کیدای۔ هغه پراکسي چې د بدن د بشپړیدو انتظار کوي، همیشه انتظار کوي، او کلاینټ په پای کې د مودې پای ته رسي۔

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

ولې پلټنه پیژندنه بدلوي

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

بریالۍ تایید نه مانا دا ده چې پراکسي غونډله وړلی شي۔ تر اوسه یې باید بې بفر بې حده دوه اړخیز POST ومنړي او دواړه اړیکې ساعتونه ژوندي وساتي۔ ډېری پلټنې محصولات د غوښتنې-ځواب ترافیک لپاره جوړ شوي او دا حالت بد یا هیڅ نه سمبالوي۔

له همدې امله نیمګړې جرړه زیاتول یا تایید بندول ناسم اصلاح ده۔ دا بدلوي چې کلاینټ کوم سند مني؛ د هغه جریان سمبالولو سره چې غونډله یې واقعاً مات کړه هیڅ نه کوي۔

د امستلو مخکې صادرونکی وپیژنئ

له پای ټکي وپوښتئ چې کوم سند وړاندې کوي او چا لاسلیک کړی یې دی۔ لاندې لارښوونې د VPN غونډلې له پیل پرته زنځیر او صادرونکی ښیي:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

که صادرونکی عامه CA وي، دا هوسټ لپاره اړیکه احتمالاً نه نیول کیږي او ناکامي بل ځای دی۔ که صادرونکی د سازمان خپله CA وي، پلټنه فعاله ده او ګیټوې ته د پراکسي له لارې رسیدل کیږي۔ د یوازې نوم له مخې د پایلې مخکې ګوته نښه له شبکې ټیم د تمې سره پرتله کړئ۔

همدا هوسټ ته د براوزر ازموینه یوازې دا ثابتوي چې پراکسي GET مني۔ د SSTP میتود، د غوښتنې URI یا د بدن ژوند په اړه هیڅ نه وایي، نو فعاله انټرانیټ پاڼه د تونل لارې د ملاتړ ثبوت مه ګڼئ۔

ملاتړې لاره وټاکئ

د شبکې مالک ته یوه مشخصه پوښتنه وکړئ: ایا پراکسي دې ګیټوې ته د 443 پورټ په بې بفر دوه اړخیز POST اجازه ورکوي؟ هو بیا د پراکسي استثنا یا د VPN هوسټ لپاره مستنده تېریدل دي۔ نه مانا دا ده چې پلټل شوې لاره SSTP نه شي وړلی، او ملاتړې حل بل لار یا پروتوکول دی، نه د کلاینټ سمون۔

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

پایله ثبت کړئ: صادرونکی، ناکام پړاو، د پراکسي قاعده او ټاکل شوې لاره۔ بل کس چې همدا 98 سلنه تمځای وویني، کولی شي یوه واقعیت وګوري پرته له دې چې ټول سفر بیا تکرار کړي۔

اړوندې مقالې