SSTP پورټ 443 ونیو: Apache ولې نه پیل کیږي

Apache په 443 باندې ځواب ورکول بندوي هغه ماسپښین چې یو څوک راتلونکي VPN اړیکې فعالوي، او د هغې خطا لاګ د شاته ریزرویشن پرځای bind ته ګناه ورکوي۔ Windows Routing and Remote Access په هماغه شیبه SSTP فعالوي، او SSTP اورېدونکی د هر کليانټ له تصدیق مخکې د HTTP سټک له لارې TCP 443 ادعا کوي۔ دا ادعا هغه وخت هم پاتې کیږي چې سند نه وي، نوم غلط وي یا هر handshake رد شي، نو هغه VPN چې هیڅوک نه شي ننوتل کولی، بیا هم پورټ نیسي۔ لومړی د اورېدو جدول ولولئ؛ هغه PID چې 443 لري پرېکړه کوي چې لاندې کوم سمون ستاسو لپاره خلاص دی۔

ریزرویشن د مات شوي سند څخه اوږد ژوند کوي

SSTP PPP د TLS غونډې دننه تړي، له همدې امله 443 ته اړتیا لري او له همدې امله د هغو پروکسيانو له لارې تګ کوي چې نور تونلونه غورځوي۔ اورېدونکی هغه socket نه دی چې VPN خدمت د ځان لپاره پرانیزي: SstpSvc هغه د کرنل HTTP ډرایور سره ثبتوي، نو پورټ تر هغه ریزرو پاتې کیږي چې خدمت روان وي۔ هغه ثبت کله هم له سند څخه نه پوښتي، یعني پای ته رسېدلی نوم، ناسم subject یا په بشپړه توګه د سند نه شتون 443 نیول شوی پریږدي۔ بیا ناکامۍ دوه لورو ته وېشل کیږي: رد شوي handshake د RasSstp لاندې System لاګ ته ځي، خو ویب سرور یوازې دا خبر ورکولی شي چې bind نه شو کولی۔

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

لومړی کرښه مالک PID بېرته ورکوي؛ دوهمه یې شاته خدمت نوموي، او ځواب معمولاً HTTP خدمت یا RRAS سټک وي۔ کله چې tasklist د شریک هوسټ پروسې سره ځواب ووایي، د پروسې له نوم څخه اټکل مه کوه، د خدمت کالم ولوله۔

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

IIS ډرایور شریکوي، Apache socket پرانیزي

IIS خپل bindings هغه ورته کرنل ډرایور ته سپاري چې SSTP یې کاروي، او هغه ډرایور راتلونکي اړیکې د هوسټ نوم او URL مخکښ له مخې بېلوي، نو دواړو خدمتونو ته کولی شو ووایو چې 443 غواړي او هیڅ یو هم ناکام نه شي۔ Apache او nginx برعکس کوي: په خپل socket باندې bind بولي، او ځکه چې پته لا دمخه نیول شوې ده، آپریټنګ سیسټم انکار کوي۔ په دواړو ترتیباتو کې هیڅ غلط نه دی؛ توپیر په دې کې دی چې کوم API پورټ لري۔ له همدې امله د VPN فعالول یوه هوسټ کې یو سایټ نسکوروي او بل هوسټ کې ورته سایټ نه لمس کوي۔

دا نابرابري د سمون بڼه ټاکي۔ که IIS لا دمخه مخکینی دروازه وي، ټکر د مخکښو، bindings او سندونو پوښتنه کیږي۔ که Apache مخکینی دروازه وي، یا هغه له 443 وځي یا SSTP اورېدونکی، او بل برخه دواړه ګامونه پوښي۔

وټاکه چې کوم خدمت 443 وساتي

د اورېدونکي پورټ په یو واحد راجستر ارزښت کې ژوند کوي، د Sstpsvc پارامیټر کلي لاندې لسیز DWORD۔ ارزښت بدله کړه، Routing and Remote Access بیا پیل کړه، او د اورېدو له جدول څخه تایید کړه چې زوړ پورټ خالي دی۔

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

هغه پورټ وټاکه چې په هوسټ کې بل څه نه غواړي، او لسیزه کې یې ولیکه: reg add DWORD په سمه توګه لکه څنګه چې لیکل شوی ساتي، نو هغه ارزښت چې شپاړسي فکر شوی و، د بل پورټ په توګه کېني۔ که پوښتنه ووایي چې ارزښت نشته، دوهمه کرښه جوړوي یې۔ Restart-Service RemoteAccess هر هغه څوک غورځوي چې نښلول شوي وي، چې پلانول یې ارزښت لري۔ بیا د اورېدو کتنه بیا چلاوه، ځکه په 443 باندې زوړ داخلیدل یعني خدمت خپل زوړ ثبت ساتلی دی۔

د اورېدونکي لېږدول هغه بیه لري چې راجستر سمون نه ښیي۔ عادي SSTP کليانټ 443 ته زنګ وهلو، نو هر کليانټ پروفایل نوی پورټ ته اړتیا لري، او بهیر د لارې څیړونکي هر څه لپاره د ویب غوښتنې په څیر نه ښکاري۔ په هغه شبکه کې چې یوازې د HTTPS په څیر ترافیک زغمي، دا د SSTP غوره کولو ډیره لامل لرې کوي۔ کوچنۍ، مدیریت شوې کليانټ نفوس دا جذبوي؛ عامه یا BYOD کاروونکي بنسټ نه۔

بل ګام 443 د IIS سره ساتي او Apache د backend په توګه ګڼي چې پروکسي ورته لیږدوي۔ دا د SSTP ډیفالټ ساتي او پورټ لپاره یو مالک پریږدي، خو د لېږدول شوو سرلیکونو، هغه کليانټ پتې چې اپلیکیشن نور یې مستقیم نه ویني، او هغه backend بیه چې باید هغه پروتوکول ووایي چې پروکسي واقعاً لیږي۔

مالک، سند او handshake په ترتیب سره ثابته کړه

بشپړه TCP اړیکه یوازې دا ثابتوي چې اورېدونکی شته او نور هېڅ نه، له همدې امله د پورټ سکن روغ ښکاریدلی شي خو تونل بیا هم ناکام وي۔ څلور پړاوونه په بېلابېلو لارو ناکام شي، او هغه پړاو ته نښه شوی سمون چې تا نه دی مات کړی معمولاً ټکر ژوروي۔ دوی په ترتیب سره ترسره کړه او هلته ودېږه چې ځواب بېل شي۔

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

لومړی کرښه هغه PID نوموي چې 443 لري، او باید هماغه خدمت وي چې تا همدا اوس تنظیم کړ۔ دوهمه د ماشین سندونه د دوی له subject سره لیستوي، نو هغه نوم چې د کليانټ پروفایل پتې سره سمون نه خوري سمدلاسه سترګو ته رسیږي۔ د پیښو پوښتنه وروستي SSTP ریکارډونه بېرته راولي، او هغه handshake چې کله هم PPP تصدیق ته نه رسیږي، د هغه څخه بېل ریکارډ پریږدي چې تصدیق او بیا رد شي۔ وروستی پړاو یوازې په کليانټ باندې ښکاري، چې هلته داخلیدل یا نښلول شوی خبر ورکوي یا د PPP خطا نوموي۔

کله چې یو هوسټ باید دواړه کارونه وکړي، د 443 مالک په پوهه سره وټاکه او ټاکنه ولیکه، ځکه که نه، بله ورځ هر څوک چې یوه ځانګړتیا فعالوي به دا ټکر بیا ومومي۔ د رولونو بېلول تر ټولو پاک ځواب پاتې کیږي: عامه ویب سرور او د لرې لاسرسي پای ټکی بېل د پیچ، سند او بیا پیل کولو دورانونه لري، او هغه دورانونه د خپل مهالویش له مخې سره ګوري۔ په هر حال، د اورېدو کتنه، راجستر لاره او ټاکل شوی پورټ په سپارلو یادښت کې پریږده۔