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 चा मालक जाणीवपूर्वक निवडा आणि निवड लिहून ठेवा, कारण अन्यथा पुढील व्यक्ती कोणतेही वैशिष्ट्य सुरू करताना ही टक्कर पुन्हा शोधेल। भूमिका वेगळ्या ठेवणे हेच स्वच्छ उत्तर आहे: सार्वजनिक वेब सर्व्हर आणि दूरस्थ प्रवेश टोक यांचे पॅच, प्रमाणपत्र आणि पुनःसुरुवातीचे चक्र वेगळे असतात, आणि ती चक्रे त्यांच्या स्वतःच्या वेळापत्रकाने भेटतात। कोणत्याही परिस्थितीत, ऐकण्याची तपासणी, रजिस्ट्री मार्ग आणि निवडलेला पोर्ट हस्तांतरण टीपेत ठेवा।