हेडलेस बॉक्सवर उघडण्यासाठी ब्राउझर नाही आणि पाहण्यासाठी कुलूप नाही, म्हणून तपासणी अशी विनंती असावी ज्याचे उत्तर तुम्ही वाचू शकता. डझनभर सेवा, दोन पत्ता-कुटुंबे आणि प्रॉक्सी चालवणाऱ्या उपकरणाची फक्त एकच एक्झिट-पत्ता निकाल वापरून प्रमाणित करण्याचा प्रयत्न पाहण्यापर्यंत हे क्षुल्लक वाटते. खालील विवेचन कामाचा भार प्रत्यक्षात चालतो त्याच संदर्भात एका वेळी एक मर्यादित पुरावा उभारते.

चाचणीने काय सिद्ध करायचे ते ठरवा

काहीही चालवण्यापूर्वी अपेक्षा एका ओळीत लिहा: कोणता प्रवाह, कोणत्या इंटरफेसने, कोणत्या गंतव्याकडे, आणि पलीकडे काय दिसावे. घोषित अपेक्षेशिवाय चाचणी अशी संख्या देते जी कोणीही समजू शकत नाही.

सर्वात उपयुक्त आवृत्ती स्वतः पाहिलेला स्रोत-पत्ता कळवणाऱ्या मंजूर एंडपॉइंटचे नाव घेते.

तो एंडपॉइंट हाच एकमेव भाग आहे जो तुम्हाला तयार करायचा आहे. बाकी सर्व क्लायंट-बाजूचे निरीक्षण आहे, आणि क्लायंट-बाजूची निरीक्षणे मनोरंजक पद्धतीने चुकतात.

योग्य संदर्भात निरीक्षण करा

प्रशासकाचे शेल कामाच्या भाराचे पर्यावरण नाही. त्यात वेगळा प्रॉक्सी चल, दुसऱ्या नेमस्पेसमधील वेगळा राउटिंग तक्ता, किंवा दुसऱ्या वापरकर्त्याची पर्यावरण फाइल असू शकते. तुम्ही तपासत असलेल्या गोष्टीप्रमाणेच त्याच होस्ट, कंटेनर, नेमस्पेस किंवा सेवा संदर्भात चाचणी करा. अन्यथा तुम्ही तुमचेच शेल मोजत आहात.

सामान्य होस्टवर याचा अर्थ तोच वापरकर्ता आणि तीच युनिट. कंटेनर पर्यावरणात याचा अर्थ होस्टवरून तपासण्याऐवजी कंटेनरच्या नेटवर्क नेमस्पेसमध्ये प्रवेश करणे. 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 पुस्तिका ठेवा, आणि चार ओळींचा तक्ता निकालांसोबत ठेवा.

संबंधित लेख