एउटै लाइनले फरक पर्ने दुई प्रोफाइल एउटै होस्टमा दोस्रो क्लाइन्ट सुरु हुने क्षणमै फरक व्यवहार गर्छन्। एउटा nobind बोक्छ र कर्नेलले दिने जुनसुकै स्थानीय पोर्ट लिन्छ; अर्कोले 1194 आरक्षित गर्छ, र दोस्रो इन्स्टेन्स पहिले नै प्रयोगमा रहेको ठेगानासँग मर्छ। त्यो लाइनले स्रोत पोर्ट कसले छान्छ भन्ने निर्धारण गर्छ, जसले पुनः प्रोफाइल मेसिनमा अरू केहीसँग बस्न सक्छ कि सक्दैन भन्ने निर्धारण गर्छ। तीन प्रश्नले यो टुंग्याउँछन्, र पहिलोले अरू दुईसम्म पुग्नुअघि धेरैजसो प्रोफाइलको जवाफ दिन्छ।

nobind ले वास्तवमा के छोड्छ

पूर्वनिर्धारित रूपमा क्लाइन्टले कल गर्नुअघि स्थानीय सकेट बाँध्छ, र प्रोफाइलले अरू नभने स्थानीय पोर्ट 1194 हुन्छ। nobind त्यो आरक्षण हटाउँछ, त्यसैले जडानको समयमा स्ट्याकले प्रयोग नगरिएको पोर्ट बाँड्छ। यो पूर्वनिर्धारित होइन, अपवाद हो, र लाइन नभएको क्लाइन्टले 1194 राख्छ, त्यसैले पिन नगरिएको दोस्रो इन्स्टेन्स ठोक्किन्छ। वितरण गरिएका धेरैजसो क्लाइन्ट प्रोफाइलले त्यही कारणले यो निर्देशन बोक्छन्, र नमुना फाइलले केही गर्नु भनेको संयन्त्रले पूर्वनिर्धारित रूपमै त्यही गर्नु होइन।

नबदलिने कुरा टाढाको पक्ष हो। सर्भर अझै प्रोफाइलले भनेको ठाउँमा सुन्छ, र कन्फिगरेसनको गन्तव्य पोर्ट अझै गन्तव्य पोर्ट हो। गतिशील स्रोत पोर्टले तपाईंको आफ्नै सकेटको फिर्ती ठेगाना बदल्छ, सर्भरको सकेटमा केही गर्दैन।

यसले केही लुकाउँदैन। तपाईंको सार्वजनिक ठेगाना मार्गले यसलाई अनुवाद गर्ने कुरा हो, प्याकेट अझै स्थानीय नेटवर्क पार गर्छ, र त्यो नेटवर्क चलाउने जो कोहीले अझै प्रवाह देख्छ। nobind गोपनीयताको विशेषता होइन, फायरवाल छल्ने बाटो पनि होइन।

यो निर्धारण गर्ने तीन सर्त

एउटा प्रश्नले अरू दुई निर्धारण गर्छ, त्यसैले केही सम्पादन गर्नुअघि त्यसको जवाफ दिनुहोस्। यदि साथीले बाहिर कल गर्छ भने, बाँकी प्रश्नले पहिले नै लिइएको निर्णयलाई मात्र सूक्ष्म बनाउँछन्। यदि यसले भित्री जडान स्वीकार गर्छ भने, स्थानीय पोर्टको कुनै पनि समायोजनले यसलाई पुग्नयोग्य बनाउँदैन।

के यो साथीले जडान सुरु गर्छ? यदि बाहिर कल गर्छ भने, गतिशील स्रोत पोर्ट हानिकारक हुँदैन र सामान्यतया राम्रो हुन्छ, किनकि जवाफ त्यही प्रवाहबाट फर्कन्छ। यदि भित्री जडानको प्रतीक्षा गर्छ भने, अगाडि केहीले पोर्ट प्रकाशित नगरेसम्म गतिशील पोर्टले यसलाई पुग्नै नसकिने बनाउँछ। त्यो एउटै जवाफले हरेक क्लाइन्ट प्रोफाइललाई हरेक सर्भर प्रोफाइलबाट अलग गर्छ।

के मार्गले स्रोत पोर्टमा फिल्टर गर्छ? एउटा ज्ञात पोर्टका लागि लेखिएको कडा नियमले स्पष्ट स्थानीय पोर्ट अनिवार्य गर्छ, र प्रोफाइलले कुन नियम पूरा गर्छ भन्ने रेकर्ड गर्नुपर्छ। धेरैजसो नेटवर्कले गन्तव्यमा मात्र फिल्टर गर्छन्, त्यसैले यो सर्त पहिलोभन्दा दुर्लभ छ। जहाँ लागू हुन्छ, त्यहाँ यसले गतिशील पोर्टको प्राथमिकतालाई पछि पार्छ।

के धेरै इन्स्टेन्सले होस्ट साझा गर्छन्? एउटा स्थिर पोर्टले तीमध्ये दुईलाई सेवा दिन सक्दैन, र पुनः सुरु गरिएको इन्स्टेन्सले 1194 अझै बन्द हुने अवस्थामा भेट्टाउन सक्छ। गतिशील पोर्टहरूले अरू केही नबदली त्यो द्वन्द्व हटाउँछन्। यसको जवाफ आत्मविश्वासका साथ दिन सक्नुहुन्न भने, हो भनेर मान्नुहोस् र कर्नेललाई छान्न दिनुहोस्।

जहाँ पिन गरिएको पोर्ट सही जवाफ हो

केही नेटवर्कले गन्तव्यसँगै स्रोत पोर्टमा पनि फिल्टर गर्छन्, त्यसैले अपरेटरले एउटा ज्ञात पोर्टबाट मात्र ट्राफिक पास गर्ने नियम लेखेको हुन सक्छ। त्यसबेला स्थानीय पोर्ट पिन गर्नु सही हो, र प्रोफाइलले पूरा गर्ने नियमको नाम दिने टिप्पणी बोक्नुपर्छ। सर्भर पोर्टसँग सममितिका लागि पिन गर्नु कारण होइन, किनकि ती दुई संख्याको एकअर्कासँग कुनै सम्बन्ध छैन। पिन टेम्प्लेटमा थियो भनेर मात्र छ भने, त्यो मेटाउनुहोस्।

अन्यथा पिन गरिएको पोर्टले समस्या किन्छ: एउटै मेसिनका दुई क्लाइन्टले दुवै 1194 राख्न सक्दैनन्, र दोस्रो प्रोफाइल होइन, पोर्टतिर संकेत गर्ने त्रुटिले असफल हुन्छ। छिटो पुनः सुरु हुने कन्टेनर उही पर्खालमा ठोक्किन्छ। समाधान वितरण गरिएका प्रोफाइलमा पहिले नै भएको निर्देशन हो।

सर्भर र क्लाइन्ट सममित छैनन्

OpenVPN 2.6 म्यानुअल ले nobind को छेउमा lport राख्छ, जो एक लाइनको तर्क हो: एउटा विकल्प भन्छ कर्नेलले छान्छ, अर्को भन्छ तपाईंले छान्नुहुन्छ। गतिशील स्थानीय पोर्ट बाहिर कल गर्ने साथीका लागि मात्र काम गर्छ, किनकि जवाफ दिने पक्षले पोर्ट अग्रिम जान्न सक्दैन। त्यसैले क्लाइन्ट प्रोफाइल सर्भरमा प्रतिलिपि गर्दा कसैले पुग्न नसक्ने श्रोता बन्छ।

धेरै नेटवर्क इन्टरफेस भएको होस्टमा ठेगाना पोर्टभन्दा छुट्टै निर्णय हो। निश्चित स्थानीय ठेगाना बाँध्नु र निश्चित पोर्ट बाँध्नु दुई फरक सेटिङ हुन्, र दुई अपलिंक भएको सर्भरले सामान्यतया दुवै पिन गर्छ। दुवै पिन गर्ने क्लाइन्टले कुनै फाइदा बिना त्यही कठोरता लिएको छ।

सारांश भूमिकाबारे हो, सुरक्षाबारे होइन: बाहिर कल गर्ने आफ्नै स्रोतबारे लचिलो हुन सक्छ, र जवाफ दिने हुन सक्दैन। कुनै पनि विकल्पले अर्को पक्षले तपाईंको पहिचानबारे सिक्ने कुरा बदल्दैन। त्यसैले यो निर्देशन क्लाइन्ट नमुनामा देखिन्छ र सर्भर नमुनामा लगभग कहिल्यै देखिँदैन।

कर्नेलले छानेको पोर्ट जाँच्नुहोस्

जडानपछि कन्फिगरेसन होइन, सकेट पढ्नुहोस्, किनकि कन्फिगरेसनले मनसाय भन्छ र सकेटले के भयो भन्छ। रेकर्ड गर्न योग्य तथ्यहरू स्थानीय पोर्ट, टाढाको अन्त्य बिन्दु, र अझै केही सुनिरहेको छ कि छैन हुन्। Linux होस्टमा तीनवटै एक आदेशको दूरीमा छन्।

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

nobind सँग क्लाइन्ट उच्च स्थानीय पोर्ट र कन्फिगर गरिएको टाढाको पोर्ट देखाउँछ, जो अपेक्षित आकार हो। सर्भरले आफ्नो कन्फिगर गरिएको पोर्टमा सुनिरहेको सकेट देखाउँछ, र त्यो सकेट नभए प्रोफाइल या त श्रोता होइन या बाँध्न सकेन। प्रवाह भए पनि प्याकेट फर्किएन भने, प्रोफाइल सम्पादन गर्नुअघि छानिएको स्रोत पोर्टलाई मार्गको कुनै पनि पोर्ट फिल्टरसँग तुलना गर्नुहोस्। एउटा कुरा बदल्नुहोस्, पुनः जोड्नुहोस् र सकेट फेरि पढ्नुहोस्।

सम्बन्धित लेखहरू