अपने असली खातों के बिना 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 एग्ज़िट कोड के साथ।
अगर कोई पंक्ति खाली है, तो परीक्षण पूरा नहीं हुआ। रोमिंग का मतलब है नेटवर्क-परिवर्तन पंक्ति दोहराना। बिना निगरानी वाला रीबूट का मतलब है यह जाँचना कि नियम लौटते हैं, जो स्विच के बारे में नहीं, बहाली के क्रम के बारे में सवाल है। क्लाइंट अपडेट के बाद क्रम दोबारा चलाएँ, क्योंकि टॉगल कम ही बदलते हैं जबकि उनके पीछे का व्यवहार बदलता है। डिकॉय पास रखें: घुमाने के लिए कुछ नहीं, और अगली जाँच पाँच मिनट लेती है।