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

एक सुरंग, फिर दूसरा निर्णय

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

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

लिखें कि प्रत्येक द्वार क्या सत्यापित करता है

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

GateIdentity it checksDestinations it permitsHow it could be skippedWhen it is removed
Outer gatewayEmployee account plus a managed device postureGeneral internal services and the inner gateway's listenerAny alternate path to the same destinations, including a public listenerOrdinary work stops and the inner stage becomes unreachable
Inner gatewayA maintenance entitlement or role claim on that identityThe named management addresses in the change recordDirect routes from the outer domain to those addressesMaintenance access ends while general access stays as it was

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

अस्वीकृति के मामले परखें, सुखद मार्ग नहीं

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

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

curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"

जोड़ी गई निर्भरताएँ गिनें

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

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

दूसरा द्वार आपके लिए क्या नहीं खरीद सकता

पूछें कि क्या दोनों द्वार एक क्रेडेंशियल, एक प्रमाणपत्र प्राधिकरण या एक प्रबंधन तल साझा करते हैं. जहाँ साझा करते हैं, वहाँ वे अपने सबसे महत्वपूर्ण विफलता ढंग भी साझा करते हैं, और दूसरा चरण उस स्वतंत्रता से अधिक महंगा है जो वह प्रतीत होता है कि जोड़ता है। अलग क्रिप्टोग्राफ़िक सत्र अलग प्रशासनिक नियंत्रण नहीं बनाते।

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

संबंधित लेख