SSTP هغه ځای کې ناکامېږي چې د براوزر HTTPS بریالی کېږي: ولې
SSTP د 443 پورټ په TLS دننه چلېږي، خو دا د وېب غوښتنه نه ده. TCP، د TLS پېژندنه، د SSTP تبادله او د PPP تصدیق د جلا پړاوونو په توګه وآزمویئ.
براوزر د VPN کوربه نوم له HTTPS له لارې پرته له کوم شکایت خلاصوي، او د SSTP کلاینټ لا هم له نښلېدو انکار کوي۔ په دې جوړه کې هېڅ متناقض نشته۔ SSTP له TLS څخه د باندني لېږد په توګه کار اخلي او بیا په همدې اړیکه کې خپله غوښتنه او د PPP پېلود چلوي، نو د پاڼې بریالۍ بارېدنه یوازې یوه تنګه خبره ثابتوي: کوربه د 443 پورټ په GET ځواب وایي۔ کلاینټ بله پوښتنه کوي، او سرور کېدای شي هغې ته بد ځواب ووایي۔
پاڼه بارېږي او ټونل نه
خلک د براوزر آزموینې ته مخه کوي ځکه چې ژر ده، بیا پایله د دې ثبوت په توګه نیسي چې سرور د لاسرسي وړ او تنظیم شوی دی۔ دا د هغې لارې GET په اړه ثبوت دی چې د پته پټۍ پرانیسته، له دې زیات نه۔ د VPN خبرې اترې له همدې TLS لاس نیولې وروسته پیلېږي، خو لېږي داسې طریقه او لار چې وېب پاڼه هېڅکله نه کاروي۔ نو د براوزر لپاره 200 ځواب د دې په اړه هېڅ نه وایي چې د SSTP پای ټکی شته که نه۔
دواړه کتنې جلا کړئ او لټون لنډېږي۔ لېږد او د سندونو زنځیر کار کوي، او د هغوی پورته د پروتوکول تبادله کې څه نه کار کوي۔ دا له مات شوي پورټ یا پای ته رسېدلي سند څخه بېل تحقیق دی، او بېل شواهد غواړي۔
SSTP کلاینټ په حقیقت کې څه لېږي
کلاینټ د /sra_{GUID}/ لارې ته د SSTP_DUPLEX_POST طریقې سره HTTP غوښتنه لېږي، بیا د اړیکې بدن د PPP چوکاټونو وړونکې دوه اړخیزه بهې په توګه پرانیستی ساتي۔ سمونېدونکی سرور HTTP/1.1 200 ځواب وایي او د وېب سرور په څېر چلند بندوي۔ هر بل څه یو لاسلیک دی: 405 یا 404 معنا دا ده چې پای ټکی نشته، 301 یا 302 معنا دا ده چې څه غوښتنه بېرته لارښوونه کوي، او سملاسي FIN معنا دا ده چې پروکسي یا سرور بهه وتړله۔
نو هدف باید د TLS سند سره تړلی وېب سرور نه، بلکې SSTP سرور وي۔ طریقه، لاره او اوږد بدن د پروتوکول غوښتنې دي، نو برعکس پروکسي نشي کولی هغوی یوازې د تنظیم له مخې ورزیات کړي۔ هغه پروکسي چې عادي HTTPS په بشپړه توګه لېږدوي، لا هم کېدای شي داسې طریقه رد کړي چې نه پېژني۔
چېرې پروکسي یا وېب سرور بهه ماتوي
منځګړی د هر څه لېږدولو دمخه د HTTP غوښتنې کرښه ګوري، او د غیرعادي لارې سره ځانګړې طریقه کېدای شي د هغه په قواعدو کې ناکامه شي۔ ځینې وسایل عادي پاڼه وړاندې کوي خو ټونل رد یا پرې کوي، نو کلاینټ د پاک انکار پر ځای داسې اړیکه راپور کوي چې پیلېږي او بیا مري۔ نورې غوښتنه مني، بیا د بدن یا بې کارۍ وخت حد پلي کوي چې د PPP کیپالایوونه یې نشي زغملای۔ دواړه د کلاینټ له اړخه یو شان ښکاري، نو کوم پړاو چې ناکام شو هغه د تېروتنې له متن څخه مهم دی۔
د وېبسایټ او SSTP ترمنځ د 443 پورټ شریکول د لارښوونې انتخاب دی، نه دا ژمنه چې هر ټوپ دواړه خبرې اترې یو شان سمبالوي۔ که په لاره کې د بار توازن کوونکی، د اور وژنې دیوال یا د TLS پای کوونکی وي، نو د VPN تنظیم ته د لاس وروړلو دمخه یې د شکمنو لیست ته ورزیات کړئ۔
پړاوونه جلا وآزمویئ
ازموینې په ترتیب چل کړئ او په لومړي ناکامۍ ودرېږئ، ځکه هر پړاو بېله طبقه بېلوي۔ لاندې TLS پروب د سند پېژندنه له هر هغه څه بېلوي چې SSTP یې کوي۔ کوربه نوم د خپل پای ټکي سره بدل کړئ او هغه subject او زنځیر ولولئ چې چاپوي۔
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comبیا پاتې شواهد پړاوونو ته وټاکئ پرځای د دې چې د کلاینټ تېروتنې څخه اټکل وکړئ۔ لاندې جدول په ټکټ کې د نقل کولو چکلیست دی، د هغه لاسلیک سره چې یوه ناکامي له بلې بېلوي۔
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
په ټکټ کې د "نښلول نشي" لیکلو پرځای وروستی بریالی پړاو ثبت کړئ۔ د MS-SSTP مشخصات هغه غوښتنه او PPP تبادله مستندوي چې د TLS لاس نیولې وروسته راځي، او دا هغه حواله ده چې ولې د براوزر آزموینه نشي کولی د دواړو څخه یو هم ځای ونیسي۔
لومړی پېژندنه، بیا PPP
د TLS پېژندنه او د PPP تصدیق پرلهپسې دي، نه بدیل، او د دوی ګډول خلک ناسم سرور تنظیم ته لېږي۔ کلاینټ لومړی د سرور سند او د هغه نیت شوی هدف تصدیقوي، بیا PPP خپل حالت خبرې اترې کوي او کاروونکی د ننګونې-ځواب طریقې یا EAP سره تصدیقوي۔ د سند ستونزه له رد شوي پټنوم څخه بېله تېروتنه ورکوي، او هېڅ تېروتنه د هغه پړاو تفصیل نه کوي چې بل یې پوښي۔
کوربه نوم د پتې سره بدلول، یا د سند خبرداری څخه تېرېدل، هغه ازموینه لرې کوي چې ناکام پړاو به یې پېژندلی و، پرځای د دې چې یې سم کړي۔ خبرداری وساتئ او ولولئ یې۔ کله چې HTTP تبادله هېڅکله د SSTP چلند ته ونه رسېده نو د PPP پټنوم بیا تنظیم نه کړئ، ځکه اعتبارنامه هېڅکله ونه غوښتل شوه۔