SSTP ने पोर्ट 443 ले लिया: Apache क्यों शुरू नहीं होता

जिस दोपहर कोई आने वाले VPN कनेक्शन चालू करता है, Apache उस दोपहर 443 पर जवाब देना बंद कर देता है, और उसका त्रुटि लॉग पीछे के आरक्षण के बजाय bind को दोष देता है। Windows Routing and Remote Access उसी पल SSTP चालू करता है, और SSTP लिसनर किसी भी क्लाइंट के प्रमाणित होने से पहले HTTP स्टैक के ज़रिए TCP 443 पर दावा करता है। यह दावा तब भी बना रहता है जब प्रमाणपत्र गायब हो, नाम गलत हो या हर handshake अस्वीकार हो, इसलिए जिस VPN में कोई लॉगिन नहीं कर सकता वह भी पोर्ट पर ही डटा रहता है। पहले सुनने की तालिका पढ़ें; 443 रखने वाला PID तय करता है कि नीचे दिए उपायों में से कौन-सा आपके लिए खुला है।

आरक्षण टूटे प्रमाणपत्र से भी ज़्यादा टिकता है

SSTP, PPP को TLS सत्र के अंदर लपेटता है, इसीलिए उसे 443 चाहिए और इसीलिए वह ऐसे प्रॉक्सी से गुज़रता है जो दूसरी सुरंगें गिरा देते हैं। लिसनर वह सॉकेट नहीं है जो 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 सॉकेट खोलता है

IIS अपने bindings उसी कर्नेल ड्राइवर को सौंपता है जिसका SSTP उपयोग करता है, और वह ड्राइवर आने वाले कनेक्शन को होस्ट नाम और URL उपसर्ग के हिसाब से अलग करता है, इसलिए दोनों सेवाओं से 443 चाहने को कहा जा सकता है और कोई भी विफल नहीं होती। Apache और nginx उलटा करते हैं: वे अपने सॉकेट पर 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

पहली पंक्ति 443 रखने वाले PID का नाम बताती है, और वह वही सेवा होनी चाहिए जिसे आपने अभी कॉन्फ़िगर किया है। दूसरी मशीन प्रमाणपत्रों को उनके subjects के साथ सूचीबद्ध करती है, इसलिए क्लाइंट प्रोफ़ाइल के पते से न मेल खाता नाम तुरंत उभर आता है। घटना क्वेरी हाल के SSTP रिकॉर्ड लौटाती है, और जो handshake कभी PPP प्रमाणीकरण तक नहीं पहुँचता वह उससे अलग रिकॉर्ड छोड़ता है जो प्रमाणित होकर फिर अस्वीकार होता है। अंतिम चरण केवल क्लाइंट पर दिखता है, जहाँ प्रविष्टि या तो कनेक्टेड बताती है या PPP त्रुटि का नाम लेती है।

जब एक ही होस्ट को दोनों काम करने पड़ें, तो 443 का मालिक जानबूझकर चुनें और चुनाव लिख लें, क्योंकि वरना कोई सुविधा चालू करने वाला अगला व्यक्ति इस टकराव को फिर से खोजेगा। भूमिकाओं को अलग रखना ही साफ़ जवाब है: सार्वजनिक वेब सर्वर और दूरस्थ पहुँच एंडपॉइंट के पैच, प्रमाणपत्र और पुनःआरंभ चक्र अलग होते हैं, और वे चक्र अपने ही कार्यक्रम पर मिलते हैं। किसी भी हाल में, सुनने की जाँच, रजिस्ट्री पथ और चुना गया पोर्ट हैंडओवर नोट में छोड़ें।