स्प्लिट टनेल काम गर्छ कि जाँच्नुहोस्: एउटा 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 नतिजाले तीमध्ये कुनै पनि प्रमाणित गर्दैन।