कई पथों पर 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 के काउंटर दोनों जाँचें। यदि दोनों इस पर सहमत न हों कि डेटा कौन-सा पथ ले गया, तो अनुबंध अभी देखा नहीं जा सकता।

स्वीकृत मैट्रिक्स को तैनाती के साथ रखें। यह अगले इंजीनियर को बताती है कि कौन-सा व्यवहार वादा किया गया, पथों के कौन-से संयोजन जाँचे गए और कौन-सी विफलता विधि अभी समर्थित नहीं है, बिना लिंक-स्थिति लैंपों से नए अनुमान के।