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

तय करें कि परीक्षण को क्या सिद्ध करना है

कुछ भी चलाने से पहले अपेक्षा एक पंक्ति में लिखें: कौन-सा प्रवाह, किस इंटरफ़ेस से, किस गंतव्य तक, और दूसरे छोर पर क्या देखा जाना चाहिए। घोषित अपेक्षा के बिना परीक्षण ऐसी संख्या देता है जिसकी कोई व्याख्या नहीं कर सकता।

सबसे उपयोगी रूप एक स्वीकृत एंडपॉइंट का नाम लेता है जो देखे गए स्रोत-पते की रिपोर्ट करता है।

वही एंडपॉइंट एकमात्र हिस्सा है जिसे आपको व्यवस्थित करना है। बाकी सब क्लाइंट-पक्ष का अवलोकन है, और क्लाइंट-पक्ष के अवलोकन दिलचस्प तरीकों से गड़बड़ाते हैं।

अवलोकन सही संदर्भ में चलाएँ

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

सामान्य होस्ट पर इसका अर्थ वही उपयोगकर्ता और वही यूनिट है। कंटेनर परिवेश में इसका अर्थ होस्ट से परीक्षण करने के बजाय कंटेनर के नेटवर्क नेमस्पेस में प्रवेश करना है। systemd सेवा पर इसका अर्थ समान सेटिंग्स वाली अस्थायी यूनिट हो सकता है।

आगे दिया गया अनुरोध तभी अर्थपूर्ण है जब आप सही संदर्भ में हों।

पता-परिवारों की जाँच अलग-अलग करें

हर परिवार स्पष्ट रूप से माँगें, क्योंकि सफल IPv4 अनुरोध IPv6 पथ का बिल्कुल भी उपयोग नहीं करता। --ipv4 और --ipv6 चयनकर्ता चुनाव को बाध्य करते हैं, और दोनों परिणामों का अंतर स्वयं जानकारी है।

curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-source

असफल IPv6 अनुरोध प्रभावी अवरोध का प्रमाण नहीं है। इसका अर्थ हो सकता है कि एंडपॉइंट के पास IPv6 पता नहीं है, DNS ने कुछ उपयोगी नहीं लौटाया, या उपकरण के पास IPv6 मार्ग ही नहीं है। निष्कर्ष निकालने से पहले विफलता पढ़ें। सुरंग से गुज़रा सफल IPv6 अनुरोध ही एकमात्र परिणाम है जो सिद्ध करता है कि IPv6 पथ ढका गया है।

दोनों उत्तर साथ-साथ लिखें। उनमें से एक अकेला आधा तथ्य है।

वे चार चीज़ें जोड़ें जो निकास जाँच छोड़ देती है

निकास पता एक प्रश्न का उत्तर देता है। चार और तय करते हैं कि सुरंग डिज़ाइन के अनुसार व्यवहार करती है या नहीं।

CheckWhat it provesWhat it does not
Included and excluded destinationsThe split behaves as designed for those flowsCoverage of any other destination
Resolver pathWhere a fresh lookup actually travelledWhere a cached answer came from
Tunnel-down behaviourThe failure policy for a new requestWhat an already open connection does
Reconnect and restartThe requirement survives the lifecycle eventBehaviour under load or partial failure

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

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

साक्ष्य लिखें, फ़ैसला नहीं

हर परिणाम के लिए प्रक्रिया संदर्भ, गंतव्य, पता-परिवार, समय और देखा गया स्रोत रखें। यह समुच्चय आपके द्वारा चलाए गए प्रवाहों के बारे में सीमित साक्ष्य है, और यह इसलिए बचाव योग्य है क्योंकि यह बताता है कि इसने क्या ढका।

यह VPN ऑपरेटर के रिकॉर्ड का अंकेक्षण नहीं है, और उपकरण पर हर भावी अनुप्रयोग के लिए प्रमाणपत्र नहीं है।

परिणाम के बगल में सीमाएँ लिखें। जो परीक्षण बताता है कि उसने क्या नहीं ढका, वह समीक्षा में टिकता है, जबकि उपकरण को सत्यापित बताने वाला नहीं टिकता। जिन परिवार-चयनकर्ताओं का उपयोग किया उनके पास curl पुस्तिका रखें, और चार पंक्तियों वाली तालिका परिणामों के साथ रखें।

संबंधित लेख