SSTP استولى على المنفذ 443: لماذا لا يبدأ Apache

يتوقف Apache عن الرد على 443 في تلك الظهيرة التي يفعّل فيها أحدهم اتصالات VPN الواردة، ويلقي سجل أخطائه اللوم على bind بدلاً من الحجز الذي يقف خلفه. يفعّل Windows Routing and Remote Access SSTP في تلك اللحظة، ويطالب مستمع SSTP بمنفذ TCP 443 عبر مكدس HTTP قبل أن تتم مصادقة أي عميل. تبقى المطالبة قائمة حتى عندما تكون الشهادة مفقودة أو الاسم خاطئًا أو يتم رفض كل handshake، لذا يظل VPN لا يستطيع أحد الدخول إليه محتجزًا للمنفذ. اقرأ جدول الاستماع أولاً؛ إن PID الذي يملك 443 هو ما يحدد أي الإصلاحات أدناه مفتوح لك أصلاً.

الحجز يعيش أطول من شهادة معطوبة

يلف SSTP بروتوكول PPP داخل جلسة TLS، ولهذا يحتاج 443 ولهذا يمر عبر وكلاء يتخلون عن الأنفاق الأخرى. المستمع ليس مقبسًا تفتحه خدمة VPN لنفسها: يسجله SstpSvc لدى برنامج تشغيل HTTP في النواة، فيبقى المنفذ محجوزًا ما دامت الخدمة تعمل. لا يسأل ذلك التسجيل الشهادة قط، ما يعني أن اسمًا منتهيًا أو subject غير مطابق أو انعدام الشهادة كليًا يترك 443 محتجزًا. ثم تنقسم الأعطال في اتجاهين: handshakes المرفوضة تنتهي في سجل 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، وينبغي أن يكون الخدمة التي أعددتها للتو. الثاني يسرد شهادات الجهاز مع subjects الخاصة بها، لذا فإن اسمًا لا يطابق العنوان في ملف تعريف العميل يلفت النظر فورًا. استعلام الأحداث يعيد سجلات SSTP الحديثة، وhandshake لا يبلغ أبدًا مصادقة PPP يترك سجلًا مختلفًا عن الذي يُصادق ثم يُرفض. المرحلة الأخيرة لا تُرى إلا على العميل، حيث يبلغ الإدخال عن اتصال أو يسمي خطأ PPP.

عندما يجب أن يقوم مضيف واحد بالمهمتين، اختر مالك 443 عن قصد واكتب الاختيار، لأن الشخص التالي الذي يفعّل ميزة سيعيد اكتشاف هذا التعارض وإلا. يبقى فصل الأدوار الجواب الأنظف: خادم ويب عام ونقطة نهاية وصول بعيد تحملان دورات منفصلة من الترقيع والشهادات وإعادة التشغيل، وتلتقي تلك الدورات وفق جدولها الخاص. في كل الأحوال، اترك فحص الاستماع ومسار السجل والمنفذ المختار في مذكرة التسليم.