हेडलेस बक्समा खोल्न ब्राउजर छैन र हेर्न ताला छैन, त्यसैले जाँच उत्तर पढ्न सकिने अनुरोध हुनुपर्छ। दर्जनौं सेवा, दुई ठेगाना परिवार र प्रोक्सी चलाउने यन्त्रलाई एउटै मात्र एक्जिट-ठेगाना नतिजाले प्रमाणित गर्न खोजिएको देख्दासम्म यो साधारण लाग्छ। तलको विवरण कार्यभार वास्तवमै चल्ने त्यही सन्दर्भमा एक पटकमा एउटा सीमित प्रमाण बनाउँछ।

परीक्षणले के प्रमाणित गर्नुपर्ने हो निर्णय गर्नुहोस्

केही चलाउनुअघि अपेक्षा एक हरफमा लेख्नुहोस्: कुन प्रवाह, कुन इन्टरफेसबाट, कुन गन्तव्यतर्फ, र अर्को छेउमा के देखिनुपर्छ। घोषित अपेक्षा बिनाको परीक्षणले कसैले व्याख्या गर्न नसक्ने सङ्ख्या दिन्छ।

सबैभन्दा उपयोगी संस्करणले आफूले देखेको स्रोत ठेगाना रिपोर्ट गर्ने स्वीकृत अन्त्यबिन्दुको नाम दिन्छ।

त्यही अन्त्यबिन्दु तपाईंले व्यवस्था गर्नुपर्ने एकमात्र भाग हो। बाँकी सबै ग्राहक-पक्षीय अवलोकन हो, र ग्राहक-पक्षीय अवलोकनहरू रोचक तरिकाले असफल हुन्छन्।

अवलोकन सही सन्दर्भमा गर्नुहोस्

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

सामान्य होस्टमा यसको अर्थ उही प्रयोगकर्ता र उही युनिट हो। कन्टेनर वातावरणमा यसको अर्थ होस्टबाट परीक्षण गर्नुको सट्टा कन्टेनरको नेटवर्क नामस्पेसमा प्रवेश गर्नु हो। 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 पुस्तिका राख्नुहोस्, र चार हरफको तालिका नतिजासँगै राख्नुहोस्।

सम्बन्धित लेखहरू