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 सेवाले आफ्नै लागि खोल्ने socket होइन: 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

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

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