SSTP پورت 443 را گرفت: چرا Apache شروع نمی‌شود

Apache بعدازظهری که کسی اتصال‌های ورودی VPN را فعال می‌کند، پاسخ‌دهی روی 443 را متوقف می‌کند و گزارش خطای آن به‌جای رزرو پشت ماجرا، bind را مقصر می‌داند. Windows Routing and Remote Access در همان لحظه SSTP را فعال می‌کند و شنونده SSTP پیش از احراز هویت هر مشتری، TCP 443 را از طریق پشته HTTP ادعا می‌کند. این ادعا حتی وقتی گواهی وجود ندارد، نام اشتباه است یا هر handshake رد می‌شود نیز برقرار می‌ماند، بنابراین VPN‌ی که هیچ‌کس نمی‌تواند وارد آن شود، باز هم پورت را اشغال می‌کند. ابتدا جدول شنود را بخوانید؛ PIDی که مالک 443 است تعیین می‌کند کدام‌یک از اصلاح‌های زیر اصلاً برای شما باز است.

رزرو از یک گواهی خراب جان سالم به در می‌برد

SSTP بسته PPP را درون یک نشست TLS می‌پیچد، به همین دلیل به 443 نیاز دارد و به همین دلیل از پراکسی‌هایی عبور می‌کند که تونل‌های دیگر را دور می‌ریزند. شنونده سوکتی نیست که سرویس VPN برای خودش باز کند: SstpSvc آن را نزد درایور HTTP هسته ثبت می‌کند، پس تا زمانی که سرویس اجرا می‌شود پورت رزرو می‌ماند. آن ثبت هرگز گواهی را بررسی نمی‌کند، یعنی نام منقضی، subject ناسازگار یا نبود کامل گواهی، 443 را اشغال باقی می‌گذارد. خطاها سپس به دو جهت تقسیم می‌شوند: handshakeهای ردشده در گزارش System زیر RasSstp فرود می‌آیند، در حالی که وب‌سرور فقط می‌تواند گزارش کند که نتوانسته bind کند.

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

خط اول PID مالک را برمی‌گرداند؛ خط دوم سرویس پشت آن را نام می‌برد و پاسخ معمولاً سرویس HTTP یا پشته RRAS است. وقتی tasklist با یک فرایند میزبان مشترک پاسخ می‌دهد، ستون سرویس را بخوانید نه اینکه از نام فرایند حدس بزنید.

هشدارهای RasSstp فقط بعد از آن ارزش خواندن دارند، چون handshakeای را توصیف می‌کنند که شکست خورده و درباره رزروی که باعث برخورد شده چیزی نمی‌گویند. نقطه پایانی VPN‌ی که هر مشتری را رد می‌کند هنوز مالک پورت است. گزارش را پرسش دوم بدانید، نه اول.

IIS درایور را شریک می‌شود، Apache سوکت باز می‌کند

IIS بایندینگ‌های خود را به همان درایور هسته‌ای می‌سپارد که SSTP استفاده می‌کند و آن درایور اتصال‌های ورودی را بر اساس نام میزبان و پیشوند URL تفکیک می‌کند، پس می‌توان از هر دو سرویس خواست که 443 را بخواهند بدون آنکه هیچ‌یک شکست بخورد. Apache و nginx برعکس عمل می‌کنند: روی سوکت خودشان bind صدا می‌زنند و سیستم‌عامل انکار می‌کند چون نشانی از قبل در اختیار است. در هیچ‌یک از این دو پیکربندی چیزی اشتباه نیست؛ تفاوت در این است که کدام API مالک پورت است. به همین دلیل هم فعال کردن VPN یک سایت را روی یک میزبان از کار می‌اندازد و سایت مشابهی را روی میزبان دیگر دست‌نخورده می‌گذارد.

این عدم‌تقارن شکل تعمیر را تعیین می‌کند. اگر IIS از قبل دروازه ورودی باشد، برخورد به پرسشی درباره پیشوندها، بایندینگ‌ها و گواهی‌ها تبدیل می‌شود. اگر Apache دروازه ورودی باشد، یا خودش از 443 کنار می‌رود یا شنونده SSTP این کار را می‌کند، و بخش بعدی هر دو جابه‌جایی را پوشش می‌دهد.

انتخاب کنید کدام سرویس 443 را نگه دارد

پورت شنونده در یک مقدار واحد رجیستری زندگی می‌کند، یک DWORD دهدهی زیر کلید پارامترهای Sstpsvc. مقدار را تغییر دهید، 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 را به‌عنوان بک‌اندی می‌بیند که پراکسی به آن ارجاع می‌دهد. این حالت پیش‌فرض SSTP را حفظ می‌کند و یک مالک برای پورت باقی می‌گذارد، به قیمت سرآیندهای ارجاع‌شده، نشانی مشتری که برنامه دیگر آن را مستقیم نمی‌بیند و بک‌اندی که باید پروتکلی را صحبت کند که پراکسی در واقع می‌فرستد.

مالک، گواهی و 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 را آگاهانه انتخاب کنید و انتخاب را بنویسید، چون در غیر این صورت نفر بعدی که ویژگی‌ای را فعال می‌کند این برخورد را دوباره کشف خواهد کرد. جدا کردن نقش‌ها پاسخ پاک‌تر می‌ماند: یک وب‌سرور عمومی و یک نقطه پایانی دسترسی از راه دور چرخه‌های جداگانه وصله، گواهی و راه‌اندازی مجدد دارند و آن چرخه‌ها طبق برنامه خودشان به هم می‌رسند. در هر حالت، بررسی شنود، مسیر رجیستری و پورت انتخاب‌شده را در یادداشت تحویل بگذارید.