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