د SSTP سند ناسمونځ: هغه نوم چې ستاسو سرور باید وړاندې کړي

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

د پروفایل نوم ټاکي چې څه وګړل شي

SSTP د TLS په TCP 443 باندې چلوي، نو کلاینټ لکه بل هر TLS کلاینټ چلند کوي: هوسټ نوم له پروفایل څخه اخلي، هغه نوم غواړي او سند ورسره پرتله کوي۔ که په پروفایل کې IP پته ولیکئ، پرتله د IP پتو پرتله کیږي، چې ډېری سرور سندونه يې نه پوره کوي۔

نو د براوزر ازموینه کېدای شي بریالۍ شي خو VPN ناکام شي، ځکه براوزر له پروفایل څخه بل نوم کارولی۔ همدا وېش هغه وخت هم ښکاري چې split-horizon DNS د VPN هوسټ نوم کورنۍ پتې ته حل کوي خو براوزر عامه پتې ته رسېدلی وي۔ لومړی پروفایل له مستند هوسټ نوم سره سم کړئ، بیا سندونه پرتله کړئ۔ له هغې دمخه هر بل څه چې بدل کړئ اټکل دی۔

سرور سند باید څه ولري

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

سند ته د سرور د تصدیق هدف هم اړین دی: په مایکروسافټ د SSTP مشخصاتو کې یاد شوی غځېدلی کیلي کارونې ارزښت، یعنې د شی پېژندونکي 1.3.6.1.5.5.7.3.1 سره serverAuth۔ کیلي کارونه او سم زنځیر ټولګه بشپړوي۔ هغه سند چې پر سرور شته، د سم نوم لپاره صادر شوی خو یوازې د کلاینټ تصدیق لپاره، بیا هم ناکام شي۔

د ننوتلو معلوماتو دمخه زنځیر او ساعت وګورئ

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

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

لومړی فرمان نوم، د اعتبار موده او هغه بدیل نومونه چاپوي چې کلاینټ به ورسره پرتله کوي۔ دویم د وړاندې شوي زنځیر سره د تصدیق تېروتنې راپور کوي، او هماغه ځای کې ورک منځنی سند ښکاري۔ په Windows کې د وخت خدمت پوښتنه وايي چې ساعت سمېږي که یوازې لېږدېدلی دی۔

کورنی CA یو بل شرط زیاتوي: کلاینټ باید هغه CA ته باور ولري۔ سازماني ریښه د هغې د تصویب شوې وېش لارې له لارې نصب کړئ، نه له هغه پاڼې چې بدیل سند وړاندې کوي، ځکه هغه پریکړه ټول باور ماډل په کوچني بڼه دی۔

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

نوم یا سند سم کړئ او بیا یې ازموینه وکړئ

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

له بدلون وروسته د ملاتړ شوي کلاینټ سره بیا وصل شئ او تایید کړئ چې د ننوتلو غوښتنه ښکاري، بیا چې تونل پورته کیږي۔ په ټیکټ کې کارول شوی هوسټ نوم، صادرونکی او د پای نیټه ولیکئ۔ هماغه ریکارډ بل نوي کول د بل خنډ پر ځای پلان شوی کار کوي، او بل کس ته ښيي چې له درېیو شرطونو کوم یو واقعاً مات و۔