जांचें कि स्प्लिट टनल काम करता है: एक IP परिणाम कोई परीक्षण नहीं है

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

मिथक: पता खोज कवरेज साबित करती है

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

पता पेज मार्ग, रिज़ॉल्वर या विफलता नीति भी नहीं दिखा सकता। इसे एक अवलोकन मानें, फैसला नहीं।

शामिल और बहिष्कृत प्रवाह का परीक्षण करें

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

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

इसलिए गलत एप्लिकेशन में परीक्षण डिज़ाइन के इरादे के विपरीत दिखा सकता है। कोई निष्कर्ष निकालने से पहले दोनों पक्षों के चार फ़ील्ड लिखें।

DNS और विफलता का मामला जोड़ें

सिस्टम रिज़ॉल्वर और ऐप द्वारा उपयोग किए जाने वाले रिज़ॉल्वर से पूछें, फिर उन उत्तरों की तुलना उस निकास पते से करें जो साइट बताती है। दोनों परतें जानबूझकर अलग हो सकती हैं, और एक ब्राउज़र खोज ऑपरेटिंग सिस्टम की नीति की जांच नहीं करती। एक शेल तुलना को दोहराने योग्य बनाता है: टनल को जानबूझकर तोड़ें, फिर ऐसा अनुरोध करें जिसे ब्राउज़र ने कैश नहीं किया; कैश से दिया गया पेज इस बारे में कुछ नहीं बताता कि बैकअप किस दिशा में गया। जो वास्तव में हुआ वह दर्ज करें, न कि जो डिज़ाइन ने अनुमान लगाया।

curl -s https://ifconfig.me
nslookup intranet.example

बंद रूप में विफल होने वाली स्प्लिट टनल और खुले रूप में विफल होने वाली टनल एक जैसी दिखती हैं जब तक आप टनल को जानबूझकर न तोड़ें। जो व्यवहार आपने देखा वह दर्ज करें, न कि जिसकी अपेक्षा थी।

स्थिति बदलने के बाद दोहराएं

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

यदि कोई परिणाम भिन्न हो, तो एक साथ कई सेटिंग बदलने से पहले नियम का स्वामी और प्रसंस्करण चरण खोजें। पांच चीजें बदलना और एक परिणाम देखना निदान नहीं है, यह नई कॉन्फ़िगरेशन है।

परिणाम को क्या साबित करना चाहिए

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

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