सत्रको बीचमा पीयरको ठेगाना बदलियो: OpenVPN मा float ले के गर्छ

ल्यापटप कार्यालयको Wi-Fi बाट फोनको हटस्पटमा जान्छ, टनेल केही सेकेन्ड अझै टिक्छ, र त्यसपछि इन्टरफेस अझै जोडिएको छ भनी दाबी गर्दै गर्दा ट्राफिक रोकिन्छ। सर्भरमा, स्थिति सूचीले अझै पुरानो सार्वजनिक ठेगाना देखाइरहेको हुन्छ। यो त्यही अवस्था हो जसका लागि float अवस्थित छ, र यो त्यही अवस्था पनि हो जहाँ मानिसहरूले यसले गर्नेभन्दा धेरै बढी अपेक्षा गर्छन्। सीमा राम्ररी बुझ्नाले अलमल्याउने रोकावटलाई एक लाइनको कन्फिगरेसन परिवर्तन वा पूर्ण रूपमा अर्को अनुसन्धानमा बदल्छ।

float ले के खुकुलो गर्छ, र के कहिल्यै खुकुलो गर्दैन

सामान्यतया सत्र जुन बाहिरी ठेगाना र पोर्टबाट सुरु भयो त्यसैसँग कुरा गरिरहन्छ, र अन्यत्रबाट आउने प्याकेटहरू बेवास्ता गरिन्छ। float विकल्पले पीयरले पहिले नै आफूलाई प्रमाणित गरिसकेपछि त्यो कडा बाँध्ने काम हटाउँछ, त्यसैले बदलिएको स्रोत म्यापिङ फाल्नुको सट्टा त्यही सत्र जारी राख्न सक्छ। क्रिप्टोग्राफिक जाँचमा केही पनि बदलिँदैन: कुञ्जीहरू, प्रमाणपत्रहरू र कुनै पनि HMAC सुरक्षा कन्फिगर गरिएझैँ रहन्छ।

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

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

सत्र सार्ने प्याकेट प्रमाणित हुनुपर्छ

कन्फिगर गरिएको टाढाको छेउतर्फ सामान्य तरिकाले सत्र सुरु गर्नुहोस्, र म्यापिङ बदलिँदा के हुन्छ त्यो float ले सम्हाल्छ। प्रवाहको बीचमा नम्बर बदल्ने मोबाइल अपरेटर, आफ्नो पोर्ट म्यापिङ फेरि लेख्ने NAT गेटवे, वा अपलिङ्क बदल्ने ल्यापटप सबैले एउटै आकार बनाउँछन्: नयाँ टपलबाट प्रमाणित प्याकेटहरू, जो अझै पुरानोमा विश्वास गर्ने सत्रमा पुग्छन्।

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

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

खोज पूर्ण रूपमा छुट्टै संयन्त्र हो

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

विकल्प फेरि एकपटक थप्दा नयाँ ठेगानासम्म मार्ग नहुनुलाई पूर्ति गर्न सक्दैन। पीयर चुप हुँदा पनि यसले सहयोग गर्दैन, किनकि चुप पीयरले कहिल्यै केही सार्न सक्ने प्रमाणित प्याकेट पठाउँदैन।

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

जब NetworkManager प्रोफाइलको मालिक हुन्छ

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

मूल आयात फाइलको सट्टा सुरक्षित जडान जाँच्नुहोस्। .ovpn फाइलमा बाँकी रहेको लाइनले केही प्रमाणित गर्दैन यदि सक्रिय प्रबन्धकले त्यसलाई कहिल्यै लागू गरेन भने, र दिइएको विकल्पका लागि चेकबक्स नभएको सम्पादकले पनि प्रोटोकलको क्षमताबारे केही प्रमाणित गर्दैन।

व्यवहार थप्न प्याकेज गरिएको प्लगइन प्याच नगर्नुहोस्, विशेष गरी असम्बन्धित घटकको ऐतिहासिक संस्करणका लागि लेखिएको diff प्रयोग गरेर होइन। यदि स्थापित एकीकरणले साँच्चै त्यो सेटिङ व्यक्त गर्न सक्दैन भने, सही कदम समर्थित प्रोफाइल वा तैनाथीको मालिकले स्वीकृत गरेको अर्को क्लाइन्ट मार्ग हो।

अनुमान नगरी संक्रमण प्रमाणित गर्नुहोस्

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

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

अन्तमा, तपाईंले अभ्यास गरेको अवस्थाको मात्र वर्णन गर्नुहोस्। सत्रको क्रममा सफल ठेगाना परिवर्तन भनेको DNS स्थानान्तरण, अर्को क्लाइन्ट कार्यान्वयन वा पुनः बनाइएको प्रोफाइल उस्तै व्यवहार गर्ने प्रमाण होइन। link-options कागजात ले विकल्पको दायरा ठ्याक्कै बताउँछ; तपाईंको परीक्षण लगले त्यो दायराको कुन भाग तपाईंले वास्तवमा समेट्नुभयो भनी लेख्नुपर्छ।