सत्राच्या मध्यात पीअरचा पत्ता बदलला: OpenVPN मध्ये float काय करते
float प्रमाणित पीअरला सत्राच्या मध्यात आपला बाह्य पत्ता बदलू देते. ते एंडपॉइंट शोधत नाही, मृत दुवा पुन्हा उघडत नाही आणि ओळख तपासण्या वगळत नाही.
लॅपटॉप कार्यालयाच्या Wi-Fi वरून फोनच्या हॉटस्पॉटवर जातो, टनेल काही सेकंद अधिक टिकते आणि नंतर इंटरफेस अजूनही जोडलेले असल्याचा दावा करत असतानाच रहदारी थांबते. सर्व्हरवर, स्थिती यादी अजूनही जुना सार्वजनिक पत्ता दाखवते. ही अशी परिस्थिती आहे ज्यासाठी float अस्तित्वात आहे, आणि हीच अशी परिस्थिती आहे जिथे लोक त्याच्याकडून तो जे करतो त्यापेक्षा खूप जास्त अपेक्षा ठेवतात. मर्यादा नीट समजून घेतल्यास गोंधळात टाकणारा खोळंबा एका ओळीच्या कॉन्फिगरेशन बदलात किंवा पूर्णपणे वेगळ्या तपासणीत बदलतो.
float काय सैल करते आणि काय कधीही सैल करत नाही
सामान्यतः सत्र ज्या बाह्य पत्ता आणि पोर्टसह सुरू झाले त्यांच्याशीच बोलत राहते, आणि इतर कुठूनही येणारे पॅकेट दुर्लक्षित केले जातात. float पर्याय पीअरने स्वतःला आधीच सिद्ध केल्यानंतर ते कडक बंधन काढून टाकतो, त्यामुळे बदललेले स्रोत मॅपिंग टाकून देण्याऐवजी तेच सत्र पुढे चालू ठेवू शकते. क्रिप्टोग्राफिक तपासण्यांमध्ये काहीही बदलत नाही: की, प्रमाणपत्रे आणि कोणतेही HMAC संरक्षण कॉन्फिगर केल्याप्रमाणेच राहते.
हा प्रत्येक पॅकेटचा निर्णय आहे, कोण जोडू शकतो याबद्दलचे धोरण नाही. नव्या पत्त्यावरून पॅकेट पाठवणारे अनोळखी यंत्र काहीही सिद्ध केलेले नाही, आणि त्याचे पॅकेट इतर कोणत्याही अप्रमाणित रहदारीप्रमाणेच टाकून दिले जाते. फक्त सत्राच्या स्वतःच्या प्रमाणीकरणातून जाणारी रहदारीच नोंदवलेला पीअर पत्ता हलवू शकते, आणि म्हणूनच क्लायंट भटकत असलेल्या वातावरणात float चालू ठेवणे सुरक्षित आहे.
ते आतील टनेलबद्दलही काही सांगत नाही. हलवलेला बाह्य पत्ता टनेल पत्ता पुन्हा नेमत नाही, पूल बदलत नाही आणि पीअरला नव्या कशातही प्रवेश देत नाही. टनेलच्या आत, हलण्यापूर्वी आणि नंतर तीच ओळख आणि तेच ढकललेले मार्ग लागू होतात. भटकंती डेटा चॅनेलची पुन्हा बोलणीही करत नाही, त्यामुळे ठरलेले सायफर आणि की पुढे चालू राहतात.
सत्र हलवणाऱ्या पॅकेटने प्रमाणित व्हावे लागते
कॉन्फिगर केलेल्या दूरच्या टोकासमोर नेहमीच्या पद्धतीने सत्र सुरू करा, आणि मॅपिंग बदलल्यावर काय होते ते float सांभाळते. प्रवाहाच्या मध्यात क्रमांक बदलणारा मोबाइल ऑपरेटर, पोर्ट मॅपिंग पुन्हा लिहिणारा NAT गेटवे, किंवा अपलिंक बदलणारा लॅपटॉप—सर्व एकच आकार तयार करतात: नव्या टपलमधून प्रमाणित पॅकेट, जी अजूनही जुन्यावर विश्वास ठेवणाऱ्या सत्रात पोहोचतात.
float काम करत आहे का असे विचारले असता उपयुक्त पुरावा म्हणजे पूर्ण झालेला हातमिळवणी आणि त्यानंतर स्वीकारलेला स्रोत बदल, केवळ पत्त्याबद्दलची लॉग ओळ नाही. जुना आणि नवा बाह्य पत्ता जिवंत राहिलेल्या सत्राशी जोडा, आणि नंतर रहदारी खरोखर टनेलमधून पुढे गेली याची खात्री करा.
सत्र हलण्याऐवजी मेले तर, नव्या पत्त्यावरून आलेले पॅकेट कदाचित प्रमाणीकरणात अपयशी ठरले असेल किंवा अजिबात आले नसेल. क्लायंटच्या बाजूने दोन्ही प्रकरणे सारखीच दिसतात. सर्व्हरवर, सार्वजनिक इंटरफेसवरील कॅप्चर कोणते प्रकरण आहे हे कोणतेही कॉन्फिगरेशन हाताळण्यापूर्वी सांगते.
शोध ही पूर्णपणे वेगळी यंत्रणा आहे
float टाइमरवर नावे सोडवत नाही आणि गतिमान DNS नोंदीचा मागोवा घेत नाही. सर्व्हरचे होस्टनेम नव्या पत्त्यावर सोडवायला लागले तर निष्क्रिय क्लायंटला ते लक्षात घेण्याचे कारण नाही आणि नव्या एंडपॉइंटकडून प्रमाणित करण्यासाठी पॅकेटही नाही. ती समस्या पुनर्जोडणीचे तर्क, क्लायंटचे स्वतःचे पुन्हा प्रयत्नाचे वर्तन आणि DNS यांच्याशी संबंधित आहे, float शी नाही.
पर्याय पुन्हा एकदा जोडल्याने नव्या पत्त्यापर्यंतच्या मार्गाचा अभाव भरून निघत नाही. पीअर शांत असतानाही ते मदत करत नाही, कारण शांत पीअर कधीही काही हलवू शकेल असे प्रमाणित पॅकेट पाठवत नाही.
खालच्या फायरवॉललाही मत आहे. केवळ जुन्या बाह्य एंडपॉइंटला परवानगी देणारा नियम बदललेला पत्ता OpenVPN ला दिसण्यापूर्वीच अडवतो, आणि क्लायंट-बाजूचे कोणतेही कॉन्फिगरेशन ते दुरुस्त करत नाही. परवानगी दिलेल्या पत्त्यांचे जीवनचक्र स्वतंत्र काम म्हणून तपासा; नियम कोणत्याही स्रोतापर्यंत वाढवणे लहान समस्या मोठ्या समस्येबरोबर बदलणे आहे.
जेव्हा NetworkManager प्रोफाइलचा मालक असतो
कमांड-लाइन प्रोफाइल आणि आयात केलेले कनेक्शन वेगवेगळी कॉन्फिगरेशन आहेत, आणि एक संपादित केल्याने दुसऱ्याला धक्का लागत नाही. पर्याय समर्थित नाही असे गृहीत धरण्यापूर्वी, जतन केलेले प्रोफाइल प्रत्यक्षात कोणत्या प्रकारचे प्लगइन वापरते आणि त्याची मूल्ये कुठे राहतात हे निश्चित करा. प्रोफाइलचा UUID हा असा ओळखकर्ता आहे जो काही तपासताना किंवा बदलताना महत्त्वाचा असतो.
मूळ आयात फाइलऐवजी जतन केलेले कनेक्शन तपासा. .ovpn फाइलमध्ये टिकून राहिलेली ओळ काहीही सिद्ध करत नाही जर सक्रिय व्यवस्थापकाने ती कधीही लागू केली नसेल, आणि दिलेल्या पर्यायासाठी चेकबॉक्स नसलेला संपादकही प्रोटोकॉलच्या क्षमतांबद्दल काहीही सिद्ध करत नाही.
वर्तन जोडण्यासाठी पॅकेज केलेले प्लगइन पॅच करू नका, विशेषतः असंबंधित घटकाच्या ऐतिहासिक आवृत्तीसाठी लिहिलेल्या diff ने नाही. स्थापित एकत्रीकरण खरोखर ते सेटिंग व्यक्त करू शकत नसेल, तर योग्य पाऊल समर्थित प्रोफाइल किंवा तैनातीच्या मालकाने मंजूर केलेला दुसरा क्लायंट मार्ग आहे.
गृहीत धरण्याऐवजी संक्रमण सिद्ध करा
बिघाड जसा होतो तसाच चाचणी घ्या. जोडा, टनेलमधून रहदारी तपासा, बाह्य पत्ता बदलण्यास भाग पाडा, आणि नंतर तीन गोष्टी तपासा: सत्र अजूनही आहे, नोंदवलेला पीअर पत्ता हलला आहे, आणि प्रत्यक्ष विनंती अजूनही तिच्या गंतव्यापर्यंत पोहोचते. तीनपेक्षा कमी काहीही अर्धवट उत्तर आहे.
चाचणी करताना पुनर्प्राप्तीचा प्रवेश उपलब्ध ठेवा, कारण भटकंतीच्या प्रयोगांना ज्या यंत्रावरून तुम्ही काम करता ते अडकवून ठेवण्याची सवय असते. सिरियल कन्सोल किंवा बँडबाह्य मार्ग अपयशी चाचणीला साइट भेटीऐवजी पाच मिनिटांच्या पुनर्प्राप्तीत बदलतो.
शेवटी, तुम्ही प्रत्यक्ष केलेल्या प्रकरणाचेच वर्णन करा. सत्रादरम्यान यशस्वी पत्ता बदल हा DNS स्थलांतरे, दुसरे क्लायंट अंमलबजावणी किंवा पुन्हा बांधलेले प्रोफाइल तसेच वागतील याचा पुरावा नाही. link-options दस्तऐवज पर्यायाची व्याप्ती नेमकी सांगतात; तुमच्या चाचणी लॉगमध्ये त्या व्याप्तीचा कोणता भाग तुम्ही खरोखर व्यापला हे लिहिले पाहिजे.