OpenVPN Access Server प्रत्यक्षात कोणत्या पोर्टवर ऐकतो?
Access Server होस्टवरील सॉकेट यादीतून जा: डीफॉल्ट श्रोते ओळखा, loopback आणि प्रकाशित पोर्ट वेगळे करा, आणि पोर्ट बंद करण्यापूर्वी फॉरवर्डिंग तपासा।
तुम्ही ss -lntup Access Server होस्टवर चालवता आणि अपेक्षेपेक्षा दुप्पट लांब यादी मिळते। अर्ध्या नोंदी डेमन-आकाराचे पोर्ट आहेत ज्यांचा सेटअपमध्ये कोणी उल्लेख केला नव्हता। प्रतिक्रिया म्हणजे 443 किंवा 1194 नसलेले सर्व बंद करणे, आणि अशा प्रकारे लोक स्वतःचे क्लायंट पोर्टल तोडतात।
Access Server एकच श्रोता नाही। तो VPN सेवा, वेब सेवा आणि क्लस्टर सहभागी आहे, आणि तुम्ही किती TCP डेमन कॉन्फिगर केले यावर अवलंबून तो अतिरिक्त डेमन-विशिष्ट पोर्ट आणि फायरवॉल रीडायरेक्शन तयार करू शकतो।
यादी क्रमाने पाहा: सॉकेट वाचा, परिचित असलेले नकाशा करा, उर्वरित मालक आणि बाइंडनुसार वर्गीकृत करा, आणि नंतर प्रत्यक्षात त्यांना काय प्रकाशित करते ते तपासा।
एका फक्त-वाचन आदेशाने सुरुवात करा
sudo ss -lntup प्रत्येक ऐकणाऱ्या सॉकेटसाठी ट्रान्सपोर्ट, स्थानिक पत्ता, पोर्ट आणि मालक प्रक्रिया देते। फ्लॅग महत्त्वाचे आहेत: -l ऐकणे, -n संख्यात्मक, -t TCP, -u UDP, -p प्रक्रिया। root शिवाय तुम्हाला सॉकेट मिळतात पण प्रक्रियेची नावे नाहीत, आणि वर्गीकरणासाठी नेमका तोच स्तंभ लागतो।
कोणतेही मत तयार करण्यापूर्वी प्रत्येक ओळीसाठी चार क्षेत्रे नोंदवा: प्रोटोकॉल, बाइंड पत्ता, पोर्ट आणि आदेश। Access Server आवृत्ती आणि कॉन्फिगर केलेली डेमन संख्या त्या यादीच्या शेजारी ठेवा, कारण दोन्ही अपेक्षा बदलतात।
सारख्या दिसणाऱ्या दोन ओळी सारख्या नसतात। एकाच क्रमांकावर TCP आणि UDP वेगळ्या एक्सपोजरसह वेगळे सॉकेट आहेत, आणि 0.0.0.0 आणि :: वेगळ्या पत्ता कुटुंबांसाठी वेगळे बाइंड आहेत। फक्त 127.0.0.1 ला बांधलेली सेवा दुसऱ्या होस्टवरून थेट पोहोचत नाही, तरी स्थानिक रीडायरेक्ट अजूनही ती प्रकाशित करू शकतो।
तुम्ही ओळखायला हवे असे श्रोते
हे डीफॉल्ट बहुतेक तैनाती व्यापतात आणि तुलनेसाठी आधार देतात। हे डीफॉल्ट आहेत, संपूर्ण परवानगी यादी नाही।
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
यापुढील प्रत्येक गोष्टीला स्पष्टीकरण हवे, गृहीतक नाही। उत्पादन स्वतःसाठी स्थापित करत असलेल्या घटकांचे फक्त-स्थानिक श्रोते तुम्हाला अनेकदा दिसतील। त्यांना लक्षात ठेवलेल्या पोर्ट क्रमांकाऐवजी PID आणि सेवा कॉन्फिगरेशनने पुष्टी करा, आणि अपरिचित पोर्टला फक्त अपरिचित असल्यामुळे शत्रू मानू नका।
परिचित जोडीबाहेरील सॉकेटही आपोआप उरलेले नसते। अनेक TCP डेमन कॉन्फिगर केले असता, Access Server प्रत्येक डेमनसाठी श्रोते तयार करतो आणि त्यांच्याकडे रहदारी रीडायरेक्ट करतो, त्यामुळे त्यांची संख्या आणि पोर्ट मूल्ये त्या कॉन्फिगरेशनचे अनुसरण करतात।
काहीही बंद करण्यापूर्वी वर्गीकृत करा
प्रत्येक अनिश्चित ओळीसाठी या क्रमाने तीन प्रश्नांची उत्तरे द्या।
- मालक आणि उद्देश। PID ला युनिट किंवा प्रक्रियेशी जुळवा आणि त्या सेवेचे कॉन्फिगरेशन वाचा। जर तुम्ही मालकाचे नाव सांगू शकत नाही, तर सॉकेटबद्दल काहीही ठरवण्यास तुम्ही तयार नाही।
- बाइंड व्याप्ती। Loopback नामव्यवस्थेसाठी स्थानिक आहे। वाइल्डकार्ड बाइंड फक्त तेव्हाच पोहोचता येते जेव्हा राउटिंग, होस्ट फिल्टरिंग आणि कोणतेही क्लाउड-स्तरीय नियम परवानगी देतात, त्यामुळे बाइंड पत्ता आवश्यक पण पुरेसा नाही। IPv4 आणि IPv6 वेगळे निर्णय म्हणून तपासा।
- प्रकाशित मार्ग। सेवा फॉरवर्डिंग, डेमन-विशिष्ट रीडायरेक्ट, बाह्य प्रॉक्सी आणि प्रभावी फायरवॉल धोरण शोधा। हेच पाऊल लोक वगळतात, आणि निष्पाप दिसणारे बॅकएंड पोर्ट पोहोचण्यायोग्य प्रशासकीय मार्गात बदलणारे हेच आहे।
तोच प्रश्न होस्टबाहेरून वेगळा वाचला जातो। होस्ट फायरवॉल नियम नसलेले पोर्ट क्लाउड सुरक्षा गट बंद करू शकतो, आणि परवानगी देणारे होस्ट नियम असलेले पोर्ट पोहोचता येणार नाही कारण तिथे काहीही राउट होत नाही। यादीचा निष्कर्ष लिहिण्यापूर्वी दोन्ही टोके पाहा।
जिथे प्रकाशित मार्ग सॉकेट यादीपेक्षा वेगळा आहे
Access Server चे स्वतःचे दस्तऐवजीकरण सर्वाधिक गोंधळ निर्माण करणारी परिस्थिती समाविष्ट करते: अनेक TCP डेमन चालू असता, पुढील पोर्ट डेमन-विशिष्ट पोर्टकडे फॉरवर्ड करतो, आणि दृश्य मांडणी सॉकेट यादीशी जुळणे थांबवते। वेब इंटरफेस फिल्टरिंग ट्युटोरियल ते नियम आणि फक्त स्पष्ट पोर्टसाठी लिहिलेला फिल्टर रीडायरेक्ट केलेला मार्ग पूर्णपणे कसा चुकवू शकतो हे स्पष्ट करते।
क्लस्टर नियंत्रण हे आवृत्ती महत्त्वाची असलेले दुसरे स्थान आहे। 3.0 आणि नंतरच्या आवृत्त्यांमध्ये ते 943 सामायिक करते; जुन्या क्लस्टर कॉन्फिगरेशन 945 वापरत असत। आवृत्ती न तपासता त्यातील एक उघडणे किंवा ब्लॉक करणे नीटनेटके दिसणारे पण चुकीचे यादी तयार करते।
म्हणून बाहेरून दिसणारा पृष्ठभाग तीन गोष्टींचा संघ आहे: ऐकणारे सॉकेट, त्यांना पुन्हा प्रकाशित करणारे फॉरवर्डिंग नियम, आणि होस्टसमोरील नेटवर्क नियंत्रणे। फक्त पहिले नोंदवणारी कोणतीही यादी अपूर्ण आहे, आणि फक्त पहिल्याचा विचार करणारा कोणताही बदल एकतर मार्ग उघडा ठेवेल किंवा सेवा कापेल।
कोणत्याही बदलानंतर पडताळणी करा
समर्थित कॉन्फिगरेशन मालकाद्वारे श्रोता सेटिंग्ज बदला आणि तसे करताना रिकव्हरी कन्सोल उघडे ठेवा। दूरच्या होस्टवरील वेब इंटरफेसचा प्रशासकीय प्रवेश गमावणे तुम्ही नुकतेच अक्षम केलेल्या VPN द्वारे परत मिळवता येत नाही।
नंतर तैनातीस सामान्यतः आवश्यक असलेल्या चार गोष्टी पडताळा: VPN क्लायंट जोडतो, क्लायंट पोर्टल लोड होते, प्रशासकीय प्रवेश काम करतो, आणि एकापेक्षा जास्त नोड चालवल्यास क्लस्टर संवाद अजूनही कार्यरत राहतो। फक्त-VPN चाचणी पोर्टल तुटलेले असतानाही सहज उत्तीर्ण होते।
प्रत्येक सेवेसाठी परवानगी दिलेला मार्ग लिहून पूर्ण करा: कोणते सॉकेट, कोणते बाइंड, कोणता फॉरवर्डिंग नियम, कोणते नेटवर्क नियंत्रण। तोच दस्तऐवज उपयुक्त सुरक्षा आउटपुट आहे। किमान सॉकेट संख्या नाही, आणि कोणीही ओळख पूर्ण न केलेल्या श्रोत्यांना बंद करणारे सामूहिक रीसेटही नाही।