अनेक मार्गांवर VPN: वाहकाने द्यायच्या चार हमी

दुसरा WAN दुवा जोडा आणि बोगदे वर येतात, तरीही एक मार्ग डगमगल्यास फाइल प्रत अडकते. दुवे निरोगी आहेत आणि VPN प्रक्रिया चालू आहेत; जे कमी आहे ते म्हणजे वाहक आणि बोगदा यांच्यातील करार. अनेक सॉकेट स्वतःहून एका जोडणीसारखे वागत नाहीत, आणि त्यांच्यावरील अनुप्रयोग वितरण तुटेपर्यंत फरक ओळखू शकत नाही. कराराचा प्रत्येक भाग अशा अपयशाशी जुळतो जे तुम्ही तपासू शकता, आणि यामुळेच तो उपयुक्त ठरतो.

उत्पाद निवडण्यापूर्वी तो करार लिहा. त्याचे चार भाग आहेत: VPN ला मिळणारा प्रवाह, वाहक गहाळ डेटा कसा पुनर्प्राप्त करतो, कोणती टोक ओळख मार्ग बदलल्यावर टिकते, आणि मार्ग अपयशी झाल्यावर संपूर्ण तंत्र कसे वागते.

लक्षण: दुवे सुरू आहेत, सत्र तरीही तुटते

दोन्ही दुवे सुरू दाखवणारा देखरेख आलेख केवळ हे सिद्ध करतो की प्रत्येक मार्ग रहदारी वाहू शकतो. तो हे सिद्ध करत नाही की VPN एक क्रमबद्ध प्रवाह पाहतो, की एका मार्गावर गमावलेला पॅकेट दुसऱ्यावर पुनर्प्राप्त होतो, किंवा सहकारी अजूनही कोणत्या सत्राशी बोलतो हे जाणतो. कराराचा उर्वरित भाग आलेख दाखवू शकत नाही ते व्यापतो.

हस्तांतरण अडकल्यावर, वाहकाने टिकलेल्या मार्गावर वितरण चालू ठेवले का ते शोधा. दुसरा दुवा निष्क्रिय असताना सत्र मेले, तर वाहकाने तो कधीच वापरला नाही. सत्र टिकले पण डेटा क्रमाबाहेर किंवा दुहेरी आला, तर वाहक जोडणी-स्तरावरील कराराशिवाय पॅकेट हलवत आहे. दोन्ही बाजूंच्या वेळमुद्रा सहसा हे स्पष्ट करतात.

हाच फरक उपाय ठरवतो. मार्गनिर्देशन किंवा धोरणाची समस्या मार्गनिवड बदलण्याची मागणी करते; गहाळ क्रम आणि पुनर्प्राप्ती थर वेगळी वाहतूक मागतो, मोठा बफर नाही.

पहिली हमी: जोडणी-स्तरावर बाइट प्रवाह

VPN ला विश्वासार्ह क्रमबद्ध प्रवाह हवा असल्यास, वाहकाने वैयक्तिक मार्गावरील बाइट श्रेणी ओळखल्या पाहिजेत. प्रत्येक मूलभूत TCP जोडणी फक्त स्वतःचे खंड क्रमांकित करते, त्यामुळे प्राप्तकर्ता केवळ त्या क्रमांकांनी मार्गांमध्ये पुनर्रचना करू शकत नाही.

Multipath TCP हे प्रमाणित उदाहरण आहे. ते एक विश्वासार्ह बाइट प्रवाह सादर करताना अनेक TCP उपप्रवाह समन्वयित करते, डेटा-स्तरीय क्रम मॅपिंग आणि पोचेसह. अनुप्रयोग प्रवाह वाचतो, तो उपप्रवाह नाही ज्याने योगायोगाने आधी तुकडा दिला.

Linux वर MPTCP प्रति सॉकेट IPPROTO_MPTCP द्वारे opt-in आहे. जेव्हा वाटाघाटी बहुमार्ग वर्तन वापरू शकत नाही, तेव्हा दस्तऐवजीकृत पर्याय साधारण TCP आहे, म्हणजे अनुप्रयोग दुसऱ्या मार्गाचा कधीही वापर न करता एका मार्गावर चालू राहू शकतो. कर्नल सेटिंग लागू झाली असे गृहीत धरण्याऐवजी तैनात केलेल्या सॉकेटने प्रत्यक्षात कोणते वर्तन ठरवले ते तपासा.

दुसरी हमी: क्रम, दुहेरीकरण आणि पुनर्प्राप्ती

वेगवेगळ्या विलंब आणि हानी-दर असलेले मार्ग वाहकाला बफरिंग, पुनर्रचना आणि पुनःप्रेषणास भाग पाडतात. कराराने सांगावे की किती बफरिंगला परवानगी आहे, अनुप्रयोग कोणता प्रतिदाब पाहतो, आणि कोणता मार्ग पुनःप्रेषण वाहतो.

जोडलेला राहून वितरण थांबवणारा मार्ग स्वच्छ बंद होण्यापेक्षा कठीण आहे. वाहकाने तो ओळखला पाहिजे, प्रलंबित डेटा हलवला पाहिजे आणि कधीही न येणाऱ्या खंडाची अनंत प्रतीक्षा टाळली पाहिजे. दोन्ही दुवे सुरू आहेत याची साधी तपासणी या स्थितीचा समावेश करत नाही.

दुहेरीकरणाला स्वतःचा नियम हवा. एकच पेलोड दोन्ही मार्गांवर पाठवल्याने विलंब सुधारू शकतो, पण प्राप्तकर्त्याने प्रत VPN पर्यंत पोहोचण्यापूर्वी दाबून टाकली पाहिजे. IPsec anti-replay प्रति सुरक्षा-संलग्नता वैकल्पिक आहे आणि क्रमांक तपासते; पॅकेट पुनर्रचित किंवा पुनःचालित करणारा दुहेरीकरण थर ते सक्रिय करू शकतो किंवा बोगदा पडेपर्यंत समस्या लपवू शकतो.

तिसरी हमी: टोक ओळख आणि मार्गाचा सहभाग

सहकाऱ्याला नवीन मार्ग आल्यावर सत्र ओळखण्याचा स्थिर मार्ग हवा. प्रत्येक मार्ग स्वतंत्र बोगदा म्हणून प्रमाणित झाला, तर VPN एकाऐवजी दोन सत्रे पाहू शकतो. वाहकाने मार्ग एका सत्राखाली एकत्र केले, तर नवीन मार्ग कसा प्रमाणित होतो आणि जुन्याचे काय होते हे निश्चित केले पाहिजे.

कोणते पत्ते आणि ओळखकर्ते स्थिर राहतात ते नोंदवा: बोगद्याचे टोक, वाहकाचा सत्र ओळखकर्ता आणि मधला कोणताही प्रॉक्सी. प्रॉक्सी उपलब्धता आणि विश्वासाची अजून एक सीमा जोडतो, तो संरक्षित पेलोड कधीही पाहत नसला तरी.

धोरणही इथेच राहते. अनपेक्षित नेटवर्कवरून जोडणारा मार्ग तांत्रिकदृष्ट्या वैध असू शकतो आणि तरीही इच्छित विश्वास-मॉडेलचे उल्लंघन करू शकतो. नवीन मार्ग स्वयंचलितपणे स्वीकारले जातात, प्रमाणीकरण मागतात की नाकारले जातात हे ठरवा.

चौथी हमी: अपयशाखाली मर्यादित वर्तन

मार्गाचे संपूर्ण अपयश तपासा, केवळ संथ मार्ग नाही. टिकलेल्या मार्गाने सत्र अमर्यादित स्मृतीवाढीशिवाय वाहिले पाहिजे, आणि पुनर्प्राप्ती अनुप्रयोग सहन करू शकेल त्यापेक्षा लांब टाइमरवर अवलंबून नसावी. अपयशी मार्ग परत आल्यावर वाहकाने पुनर्संतुलन करायचे की प्रवाह जिथे आहे तिथे ठेवायचे हे ठरवले पाहिजे.

बफरिंग, पुनःप्रेषण आणि मार्गसंख्या यांना मर्यादा घाला, नंतर त्या हानी, पुनर्रचना, दुहेरीकरण आणि विलंब-असंतुलनाखाली पडताळून पाहा. एकूण बँडविड्थ हा इथला सर्वात कमी मनोरंजक आकडा आहे; वितरणाची सातत्य आणि स्मृती मर्यादा हाच करार आहे.

वाहकाची पुनर्प्राप्ती स्थिती VPN च्या क्रिप्टोग्राफिक स्थितीपासून वेगळी ठेवा. प्रस्थापित प्रमाणीकरण किंवा एन्क्रिप्शनची जागा घेणारा स्वतःचा विश्वासार्हता थर हा शॉर्टकट नाही, आणि थरांमध्ये क्रमांकांचा पुनर्वापर replay संरक्षण आणि निदान अविश्वासार्ह बनवतो.

वाहकाला चाचणी योजनेसह स्वीकारा

चारही हमी पास किंवा फेल तपासण्या म्हणून लिहा: एक क्रमबद्ध प्रवाह, निश्चित पुनर्प्राप्ती, स्थिर सत्र ओळख, मर्यादित अपयश वर्तन. प्रत्येक तपासणी एक मार्ग कमकुवत आणि नंतर एक मार्ग काढून चालवा.

मार्ग बदलताना एक यशस्वी फाइल हस्तांतरण सतत कार्य सिद्ध करत नाही. आवडता मार्ग बदलत हस्तांतरण पुन्हा करा, आणि वाहकाचा दृष्टिकोन व VPN चे स्वतःचे काउंटर दोन्ही तपासा. डेटा कोणत्या मार्गाने नेला यावर दोन्ही सहमत नसतील, तर करार अजून पाहण्यायोग्य नाही.

मंजूर मॅट्रिक्स तैनातीसोबत ठेवा. ते पुढील अभियंत्याला सांगते की कोणते वर्तन वचन दिले, मार्गांचे कोणते संयोजन तपासले आणि कोणती अपयश पद्धत अजून असमर्थित आहे, दुव्यांच्या स्थिती-दिव्यांवरून नवीन अंदाज न घेता.