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

क्लाइंट से शुरू करें और दोनों सिरों के नाम दें

वहाँ से शुरू करें जहाँ उपयोगकर्ता शुरू करता है, कनेक्शन प्रोफ़ाइल में। इसमें एक दूरस्थ पता, एक प्रमाणीकरण विधि और, जब डिज़ाइन समर्थन करे, मार्गों की सूची होती है। क्लाइंट से गेटवे A तक उस बाहरी टनल को नाम दें और उसे उदाहरण पते दें: क्लाइंट का टनल पता 10.77.0.2, A का 10.77.0.1, और A का सार्वजनिक अंतिम बिंदु 198.51.100.10, TEST-NET-2 दस्तावेज़ीकरण श्रेणी से लिया गया ताकि उदाहरण में कुछ भी वास्तविक होस्ट से टकरा न सके।

उस प्रोफ़ाइल में गेटवे B का कोई उल्लेख नहीं है, और यह कोई दोष नहीं है। दूसरा हॉप A का है, और क्लाइंट का एकमात्र दायित्व ट्रैफ़िक को A तक पहुँचाना और जो लौटता है उसे स्वीकार करना है। A टनल समाप्त करता है, आगे भेजता है या नई खोलता है — यह वह प्रश्न है जिसका उत्तर इस पूरी यात्रा का शेष भाग देता है, और यही तय करता है कि A क्या पढ़ सकता है।

सीरियल: A डिक्रिप्ट करता है, फिर एन्क्रिप्ट करता है

सीरियल डिज़ाइन में A ट्रैफ़िक को दो बार समाप्त करता है। यह क्लाइंट से सुरक्षा हटाता है, एप्लिकेशन का IP पैकेट प्राप्त करता है, और फिर उस पैकेट को दूसरी टनल से भेजता है जिसे A, B की ओर बनाता है। इन दो क्रियाओं के बीच पैकेट A के अग्रेषण पथ में निजी गंतव्य पर पता किए गए सामान्य IP पैकेट के रूप में बैठता है।

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

इससे यह नहीं निकलता कि A एप्लिकेशन का सादा पाठ पढ़ता है। जब क्लाइंट और सेवा TLS चलाते हैं और एक-दूसरे के प्रमाणपत्र सत्यापित करते हैं, A पठनीय अनुरोध के बजाय TLS रिकॉर्ड स्ट्रीम देखता है। यह पुष्टि करने के लिए कि वह सुरक्षा कहाँ समाप्त होती है, सेवा की प्रमाणपत्र श्रृंखला देखनी होती है, टनल का आरेख नहीं।

नेस्टेड: A केवल बाहरी परत हटाता है

नेस्टेड डिज़ाइन में क्लाइंट पहले B के लिए भीतरी टनल बनाता है और फिर उस टनल को बाहरी टनल के भीतर A तक ले जाता है। A बाहरी हेडर हटाता है, भीतरी टनल पाता है और उसकी कुंजियाँ रखे बिना उसे आगे भेजता है, इसलिए भीतरी सुरक्षा अब भी B पर समाप्त होती है।

तब क्लाइंट का अपलिंक दो परतें ढोता है, जबकि A और B के बीच का पथ एक। A भीतरी टनल के बाहरी पते देखता है, जो यह जानने के लिए पर्याप्त है कि ट्रैफ़िक है और लगभग कहाँ जा रहा है, और पेलोड पढ़ने के लिए पर्याप्त नहीं है। सीरियल मामले से पूरा अंतर यही है, और कोई हॉप काउंटर इसे नहीं दिखाता। A अब भी जो कर सकता है वह है जो पढ़ नहीं सकता उसे आगे भेजने से इनकार करना, और यह उस गेटवे के ऑपरेटर के लिए सदा उपलब्ध रहता है।

नेस्टिंग उस गुण की कीमत लेती है। हर परत हेडर ओवरहेड जोड़ती है, इसलिए MTU और MSS की योजना सुव्यवस्था के बजाय अनिवार्य हो जाती है, और एक परत के साथ चलने वाला पथ दो के साथ बड़े पैकेट चुपचाप गिरा सकता है। हर परत को अपना पुनः-कनेक्शन और कीपअलाइव व्यवहार भी चाहिए, और एक परत में विफलता दूसरी से आंशिक रुकावट जैसी दिखती है।

केवल टनल नहीं, प्रेक्षक खींचें

टनल चित्र का आसान हिस्सा हैं। प्रेक्षक ही डिज़ाइन का विषय हैं, इसलिए हर दृष्टिकोण के लिए एक पंक्ति लिखें और भरें कि हर कोई वास्तव में क्या पढ़ सकता है।

Vantage pointSerial chainNested chain
Client's access networkOuter tunnel onlyOuter tunnel only
Operator of AInner IP packet between A and BOuter addresses of the inner tunnel, not its payload
Path between A and BSecond tunnelSecond tunnel
Operator of BInner packet re-originated by APayload after the inner layer is removed
Service edgeTraffic from the exit addressTraffic from the exit address

दो पंक्तियाँ लगातार मिला दी जाती हैं: A का ऑपरेटर और क्लाइंट की टनल का प्रदाता। वे एक ही इकाई हो सकते हैं, और अलग गेटवे नाम उन्हें स्वतंत्र नहीं बनाते। स्वतंत्र स्वामित्व के लिए अलग प्रशासनिक नियंत्रण, अलग क्रेडेंशियल और अलग लॉग चाहिए।

मेटाडेटा दोनों डिज़ाइनों में बचा रहता है। समय, पैकेट आकार और कनेक्शन संख्या हर हॉप पर देखी जा सकती रहती है, इसलिए दो हॉप संकेत हटाने के बजाय सहसंबंध की लागत बढ़ाते हैं। अदृश्यता का वादा करने वाला डिज़ाइन किसी के उस पर भरोसा करने से पहले उस सूची के सामने जाँचा जाना चाहिए।

चुनने से पहले विफलता के रास्ते चलें

क्लाइंट से जानबूझकर चीज़ें तोड़ें, उसी क्रम में जिसमें उपयोगकर्ता उनसे मिलेगा। इंटरफ़ेस और उसके MTU से शुरू करें, क्योंकि नेस्टिंग प्रमाणीकरण में विफल होने से बहुत पहले पैकेट आकार पर विफल होती है।

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

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

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

पुनः-कनेक्शन मैट्रिक्स के साथ समाप्त करें: क्लाइंट की टनल गिरती है, B की टनल गिरती है, A और B के बीच का पथ बदलता है। नोट करें कि क्या लौटता है और क्या नहीं, और क्या कोई भीतरी कनेक्शन कभी अपने इच्छित वाहक के बाहर के मार्ग पर गिरता है। हर परीक्षण द्वारा प्रयुक्त पते दर्ज करें, क्योंकि किसी अन्य एक्सेस नेटवर्क पर उसे दोहराना किसी अन्य प्रश्न का उत्तर देता है। हर पुनः-कनेक्शन के बाद MTU जाँच भी दोहराएँ, क्योंकि बदला हुआ पथ एक भी कॉन्फ़िगरेशन पंक्ति हिले बिना उपयोगी आकार घटा सकता है।

सीरियल चुनें जब A को भीतरी पैकेट पर नीति लागू करनी हो, या जब क्लाइंट दो स्तरित टनल न चला सके। नेस्टिंग चुनें जब भीतरी पेलोड A पर अपठनीय रहना हो। चयन को उसके प्रेक्षकों और MTU संख्याओं के साथ लिखें, और अगले व्यक्ति को एक प्रश्न का उत्तर देने के लिए पूरा चित्र फिर से नहीं खींचना पड़ेगा।

संबंधित लेख