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 परीक्षण पोर्टल टूटा होने पर भी आराम से पास हो जाता है।
हर सेवा के लिए अनुमत पथ लिखकर समाप्त करें: कौन सा सॉकेट, कौन सा बाइंड, कौन सा फ़ॉरवर्डिंग नियम, कौन सा नेटवर्क नियंत्रण। वही दस्तावेज़ उपयोगी सुरक्षा आउटपुट है। न्यूनतम सॉकेट संख्या नहीं, और जो सामूहिक रीसेट ऐसे श्रोताओं को बंद करता है जिनकी पहचान किसी ने पूरी नहीं की, वह भी नहीं।