सत्र के बीच में पीयर का पता बदला: OpenVPN में float क्या करता है

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

float क्या ढीला करता है, और क्या कभी नहीं ढीला करता

आम तौर पर सत्र उसी बाहरी पते और पोर्ट से बात करता रहता है जिनसे शुरू हुआ था, और कहीं और से आने वाले पैकेट नज़रअंदाज़ किए जाते हैं। float विकल्प उस सख़्त बंधन को हटा देता है जब पीयर पहले ही ख़ुद को साबित कर चुका होता है, इसलिए बदला हुआ स्रोत मैपिंग उसी सत्र को जारी रख सकता है बजाय फेंके जाने के। क्रिप्टोग्राफ़िक जाँचों में कुछ नहीं बदलता: कुंजियाँ, प्रमाणपत्र और कोई भी HMAC सुरक्षा ठीक वैसे ही रहती हैं जैसे कॉन्फ़िगर की गई थीं।

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

यह अंदरूनी टनल के बारे में भी कुछ नहीं कहता। खिसका हुआ बाहरी पता टनल पता फिर से नहीं सौंपता, पूल नहीं बदलता और पीयर को किसी नई चीज़ तक पहुँच नहीं देता। टनल के भीतर, खिसकने से पहले और बाद में वही पहचान और वही धकेले गए मार्ग लागू होते हैं। घूमना डेटा चैनल पर फिर से बातचीत भी नहीं करता, इसलिए तय किया गया सिफ़र और कुंजियाँ चलते रहते हैं।

सत्र को खिसकाने वाले पैकेट को प्रमाणित होना चाहिए

कॉन्फ़िगर किए गए दूरस्थ के सामने सामान्य तरीके से सत्र शुरू करें, और मैपिंग बदलने पर क्या होता है यह float संभालता है। बहाव के बीच में नंबर बदलने वाला मोबाइल ऑपरेटर, अपनी पोर्ट मैपिंग फिर से लिखने वाला NAT गेटवे, या अपलिंक बदलने वाला लैपटॉप सभी एक ही आकार बनाते हैं: नए टपल से प्रमाणित पैकेट, जो अब भी पुराने पर भरोसा करने वाले सत्र तक पहुँचते हैं।

जब पूछा जाए कि float काम कर रहा है या नहीं, तो उपयोगी सबूत पूरा हुआ हैंडशेक और उसके बाद स्वीकार किया गया स्रोत परिवर्तन है, केवल पते के बारे में एक लॉग पंक्ति नहीं। पुराने और नए बाहरी पते को जीवित रहे सत्र से जोड़ें, फिर पुष्टि करें कि ट्रैफ़िक वास्तव में टनल से जारी रहा।

अगर सत्र खिसकने के बजाय मर जाता है, तो नए पते से आया पैकेट शायद प्रमाणीकरण में विफल रहा या आया ही नहीं। क्लाइंट की ओर से दोनों स्थितियाँ एक जैसी दिखती हैं। सर्वर पर, सार्वजनिक इंटरफ़ेस पर किया गया कैप्चर आपको कोई भी कॉन्फ़िगरेशन छूने से पहले बता देता है कि आपके पास कौन-सी स्थिति है।

खोज पूरी तरह अलग तंत्र है

float टाइमर पर नाम हल नहीं करता और गतिशील DNS रिकॉर्ड पर नज़र नहीं रखता। अगर सर्वर का होस्टनाम किसी नए पते पर हल होने लगे, तो निष्क्रिय क्लाइंट के पास यह नोटिस करने का कोई कारण नहीं और नए एंडपॉइंट से प्रमाणित करने के लिए कोई पैकेट नहीं। वह समस्या पुनः कनेक्शन तर्क, क्लाइंट के अपने पुनः प्रयास व्यवहार और DNS की है, float की नहीं।

विकल्प को एक बार और जोड़ना नए पते तक मार्ग न होने की भरपाई नहीं कर सकता। जब पीयर चुप हो तब भी यह मदद नहीं करता, क्योंकि चुप पीयर कभी वह प्रमाणित पैकेट नहीं भेजता जो कुछ खिसका सके।

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

जब NetworkManager प्रोफ़ाइल का मालिक हो

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

मूल आयात फ़ाइल के बजाय सहेजे गए कनेक्शन का निरीक्षण करें। .ovpn फ़ाइल में बची कोई पंक्ति कुछ साबित नहीं करती अगर सक्रिय प्रबंधक ने उसे कभी लागू न किया हो, और किसी दिए गए विकल्प के लिए चेकबॉक्स रहित संपादक भी प्रोटोकॉल की क्षमताओं के बारे में कुछ साबित नहीं करता।

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

मान लेने के बजाय संक्रमण साबित करें

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

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

अंत में, केवल उसी स्थिति का वर्णन करें जिसे आपने आज़माया है। सत्र के दौरान सफल पता परिवर्तन इस बात का सबूत नहीं है कि DNS माइग्रेशन, कोई दूसरा क्लाइंट कार्यान्वयन या फिर से बनाई गई प्रोफ़ाइल वैसा ही व्यवहार करेंगे। link-options दस्तावेज़ विकल्प का दायरा सटीक रूप से बताता है; आपके परीक्षण लॉग में लिखा होना चाहिए कि आपने उस दायरे का कौन-सा हिस्सा वास्तव में कवर किया।