वास्तविक खाता नभई VPN किल स्विच कसरी परीक्षण गर्ने
छलाउने पृष्ठ र ब्याकअप प्रोफाइलसँग किल स्विचको परीक्षण गर्नुहोस्: हरेक अवरोध प्रकार समेट्नुहोस्, curl का निकास कोड पढ्नुहोस् र वास्तविक रोकावटलाई DNS खराबीबाट छुट्याउनुहोस्।
किल स्विच टिक्छ कि टिक्दैन भनेर थाहा पाउन वास्तविक खाता चाहिँदैन; परीक्षणले जोखिममा पार्ने ठ्याक्कै त्यही खाता हो। यो जाँचले यस्तो छोटो झ्याल बनाउँछ जसमा ट्राफिक सुरुङबाहिर जान सक्छ वा नजान पनि सक्छ, त्यसैले गुमाउन तयार भएको कुरै भार बनाउनुपर्छ। अहिले म यो छलाउने पृष्ठ र ब्याकअप ब्राउजर प्रोफाइलसँग गर्छु, र पहिले प्रयोग गरेको ब्राउजर र वेबमेल विधिभन्दा यसले स्पष्ट उत्तर दिन्छ। तल क्लाइन्टले देखाउने त्यही क्रम पछ्याउँछु: सेटिङ, गन्तव्य, संक्रमण र त्यसपछि प्रमाण।
परीक्षणले एउटै साँघुरो प्रश्नको उत्तर दिन्छ: यो संक्रमणका बेला यो अनुप्रयोग सुरुङबाहिरको सञ्जालसम्म पुग्न सक्छ? बाँकी नीति उचित छ कि छैन भन्नेबारे यसले केही भन्दैन। दायरा त्यति सानो राख्नुहोस्, नतिजा लेख्न लायक हुन्छ।
क्लाइन्टमा स्विच र त्यसको दायरा खोज्नुहोस्
कुनै पनि सञ्जाल अवस्था बदल्नुअघि क्लाइन्ट खोलेर रोकावट सेटिङ खोज्नुहोस्। उत्पादकहरूले यसलाई फरक नामले भन्छन्: किल स्विच, लकडाउन मोड, सञ्जाल लक, सुरुङबाहिरको ट्राफिक रोक्ने। लेबलले भित्रका विकल्पभन्दा कम बताउँछ। मुख्य कुरा, रोकावट सधैं लागू हुन्छ कि अनुप्रयोगले सुरुङ भर्खरै असफल भयो भनेर ठान्दा मात्र, र त्यसले सबै अनुप्रयोग वा छानिएको सूची समेट्छ।
त्यसपछि तपाईंको क्लाइन्टले साँच्चै गर्न सक्ने संक्रमणहरू सूचीबद्ध गर्नुहोस्। प्रयोगकर्ताले सुरु गरेको विच्छेद, अनुप्रयोगबाट बाहिरिने र सर्भरसँगको सम्पर्क गुमाउने कुरा धेरै क्लाइन्टमा तीन फरक कोड मार्ग हुन्, र तिनले एउटै रोकावट नीति बाँड्दैनन्। कतिले अनुप्रयोग बन्द हुँदा रोकावट छोड्छन्। अरूले केही हटाउनेसम्म फिल्टर नियम छोड्छन्। अनुमान नगरी तपाईंले चलाउने बिल्डका लागि उत्पादकको सेटिङ सन्दर्भ पढ्नुहोस्, अनि तीनमध्ये कुनको परीक्षण गर्दै हुनुहुन्छ लेख्नुहोस्।
प्रोफाइल पनि लेख्नुहोस्: प्रोटोकल, ठेगाना परिवार र विभाजित सुरुङ सक्रिय छ कि छैन। प्रोफाइलले जानाजान केही अनुप्रयोग बाहिर राख्छ भने सम्पूर्ण यन्त्रको दाबी अर्थहीन हुन्छ, र आफैं मिलाएको बहिष्कार चुहावट होइन। OpenVPN Connect को सेटिङ सन्दर्भ कुन स्विचले कुन व्यवहार बदल्छ भनेर नाम दिने खालको पृष्ठ हो, यद्यपि लेबल क्लाइन्टअनुसार फरक पर्छ।
सुरुङबिना पनि काम गर्ने छलाउने गन्तव्य छान्नुहोस्
छलाउने पृष्ठलाई दुई गुण चाहिन्छ, र यीमध्ये एउटा छोड्दा पढ्न नसकिने नतिजा आउँछ। सुरुङ तल र रोकावट बन्द हुँदा त्यहाँ सिधै पुग्न सकिनुपर्छ, नत्र जवाफ दिन छोड्यो भन्ने कुराले होस्ट नै गयो भन्ने मात्र अर्थ लाग्न सक्छ। र त्यसलाई लगइन, कुकी वा भुक्तानी चाहिनु हुँदैन, ताकि चुहावटको मूल्य एउटा लग लाइन होस्, सत्र होइन।
तपाईंले नियन्त्रण गर्ने होस्टमा राखिएको स्थिर पृष्ठ सबैभन्दा सफा विकल्प हो। साधारण HTTP सर्भर चलाउने ब्याकअप भर्चुअल मेसिन पनि लगभग त्यत्तिकै राम्रो हुन्छ, र त्यसको उपलब्धता तपाईंको नियन्त्रणबाहिर छ भन्ने मान्नुभयो भने सार्वजनिक जडान जाँच पृष्ठ पनि चल्छ। ठेगाना, पोर्ट, ठेगाना परिवार र अनुरोधलाई नाम खोजी चाहिन्छ कि भन्ने लेख्नुहोस्, किनकि यीमध्ये हरेक पछि छुट्याउनुपर्ने चल बन्छ।
स्विच छुनुअघि आधाररेखा स्थापना गर्नुहोस्। सुरुङ माथि हुँदा छलाउने पृष्ठले सुरुङबाट जवाफ दिनुपर्छ, यसले नीति मार्ग चल्छ भन्ने प्रमाणित गर्छ। सुरुङ तल र रोकावट बन्द हुँदा त्यसले सिधै जवाफ दिनुपर्छ, यसले गन्तव्य जीवित छ भन्ने प्रमाणित गर्छ। त्यसपछि मात्र रोकिएको अवस्थाको असफलताले तपाईंलाई केही बताउँछ।
संक्रमणहरू निश्चित क्रममा चलाउनुहोस्
संक्रमणहरू एकएक गर्नुहोस् र हरेकलाई केही सेकेन्ड स्थिर हुन दिनुहोस्, किनकि क्लाइन्टहरू प्रायः त्यही अन्तरालमा नियम भत्काएर फेरि बनाउँछन्। हरेक पटक त्यही छोटो जाँच चलाउँदा अवलोकनहरू तुलनीय हुन्छन्:
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
अनुप्रयोगबाट बाहिरिने पंक्ति, सामान्य प्रयोगमा क्लाइन्ट कहिल्यै नबन्दा पनि, छुट्टै चलाउन योग्य छ। बाहिरिँदा रोकावट छुट्छ भने क्र्यास वा जबरजस्ती अद्यावधिकले तपाईंलाई त्यही जोखिम दिन्छ, र यो तपाईंको धैर्यको कुरा होइन, तैनाथीको तथ्य हो। Windows मा समान जाँचहरू Resolve-DnsName decoy.example र curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/ हुन्।
रोकावटलाई बिग्रिएको रिजोल्भरबाट छुट्याउनुहोस्
नलोड हुने पृष्ठका धेरै कारण हुन्छन्, र तीमध्ये एउटा मात्र स्विच चलिरहेको हुनु हो। नाम समाधान भएन भने डेटा मार्ग रोकिएको होइन, DNS रोकिएको वा बिग्रिएको हो भन्ने थाहा भयो। शाब्दिक ठेगाना पनि जाँच्नुहोस्, ताकि उत्तर नाम समाधानमा अलिकति पनि निर्भर नहोस्।
curl का निकास कोडले ती अवस्था छुट्याउँछन्। 6 भनेको नाम समाधान असफलता, 7 भनेको जडान अस्वीकार भयो, 28 भनेको समय सकियो। रोकिएको मार्ग सामान्यतया शाब्दिक ठेगानाप्रति समय सकिने वा अस्वीकारका रूपमा देखिन्छ, जबकि DNS मात्र रोक्दा 6 बाँकी रहन्छ र बाँकी सबै लुक्छ। क्यास गरिएको पृष्ठ वा क्याप्टिभ पोर्टलले आँखा छल्छ, त्यसैले प्रमाण स्क्रिन होइन, निकास कोड हो।
शाब्दिक ठेगानासँग IPv6 मा जाँच दोहोर्याउनुहोस्। IPv4 समेटेर IPv6 बेवास्ता गर्ने रोकावट तपाईंको टिप्पणीमा छुट्टै लाइन पाउन लायक सामान्य छ, र सुरुङबाहिर IPv6 बन्द गर्ने क्लाइन्ट दुवै परिवारमा सफा रूपमा असफल हुनुपर्छ।
नतिजाले समेट्ने दायरा लेख्नुहोस्
सुरुङ फर्किएपछि पुनर्प्राप्ति पुष्टि गर्नुहोस्: छलाउने पृष्ठ सुरुङबाट जवाफ दिन्छ, रिजोल्भरले उत्तर फर्काउँछ, र नीति तपाईंले छोडेको ठाउँमै छ। त्यसपछि प्रयोगहरू फर्काउनुहोस्। अस्थायी फायरवाल नियम, डिबग मार्ग वा परीक्षण प्रोफाइल त्यत्तिकै राख्दा अर्को पटकको काममा भ्रम पर्छ र अनुप्रयोगभन्दा लामो समय टिक्न सक्छ।
एक फेरिले एक क्लाइन्ट बिल्ड, एक प्रोफाइल, एक संक्रमण र एक ठेगाना परिवार मात्र समेट्छ। ती चार नतिजासँगै लेख्नुहोस्:
- क्लाइन्ट बिल्ड र प्लेटफर्म, र सेटिङ प्रोफाइलअनुसार हो कि सार्वजनिक।
- प्रोफाइल, प्रोटोकल र विभाजित सुरुङका कुनै पनि बहिष्कार।
- परीक्षण गरिएको संक्रमण र त्यो तपाईंले कसरी सुरु गर्नुभयो।
- ठेगाना परिवार र DNS, रोकिएको र नरोकिएको अवस्थाका curl निकास कोडसहित।
कुनै पनि लाइन खाली भए परीक्षण सकिएको छैन। रोमिङ भन्नाले सञ्जाल परिवर्तनको लाइन दोहोर्याउनु। अप्रत्यक्ष पुनःसुरु भन्नाले नियम फर्किन्छन् कि भनेर जाँच्नु भन्ने बुझिन्छ, र यो स्विचको प्रश्न होइन, पुनर्स्थापनाको क्रमको प्रश्न हो। क्लाइन्ट अद्यावधिकपछि क्रम फेरि चलाउनुहोस्, किनकि स्विचहरू विरलै बदलिन्छन्, तिनका पछाडिको व्यवहार बदलिन्छ। छलाउने पृष्ठ नजिकै राख्नुहोस्: घुमाउनुपर्ने केही छैन र अर्को जाँचमा पाँच मिनेट लाग्छ।