VPN किल स्विच: कौन-सा ट्रैफ़िक और कब रोकता है
फिर से कनेक्ट होना टनल लौटाता है; किल स्विच तय करता है कि उसके न होने पर क्या होता है। कनेक्शन टूटना, हाथ से डिस्कनेक्ट, ऐप से बाहर निकलना और नेटवर्क बदलना अलग-अलग जाँचें।
दो विशेषताओं का वर्णन एक ही शब्द से होता है और वे अलग काम करती हैं। स्वतः पुनः कनेक्शन टनल को लौटाने की कोशिश करता है, और वह एक सेकंड में सफल हो सकता है जबकि उसी अंतराल में अनुरोध विफल होते हैं। किल स्विच उस अंतराल में ट्रैफ़िक का क्या होगा यह तय करता है। इन दोनों को एक ही सेटिंग मानकर क्लाइंट पढ़ना वह तरीका है जिससे लोग नीति की जगह आइकन पर भरोसा करने लगते हैं।
रोकना और फिर से कनेक्ट होना अलग निर्णय हैं
एक क्लाइंट केवल तब रोकता है जब कनेक्शन टूटना अप्रत्याशित हो, फिर पुनः कनेक्ट होता है और रोक हटा देता है। दूसरा सिस्टम स्तर की रोक बनाए रखता है जब तक कोई सेटिंग हाथ से न बदले, और तीसरा जानबूझकर डिस्कनेक्ट को सामान्य पहुँच लौटाने की अनुमति मानता है। ये तीन अलग व्यवहार हैं, और विक्रेता का दस्तावेज़ बताता है कि आपका बिल्ड कौन-सा लागू करता है।
प्रोफ़ाइल आयात करने से उस प्रश्न का कोई निर्णय नहीं होता। वही सर्वर प्रोफ़ाइल विपरीत रोक-व्यवहार वाले दो क्लाइंट में लोड होती है, क्योंकि प्रोफ़ाइल सेटिंग ले जाती है, वादा नहीं। इसीलिए डेस्कटॉप का चेकबॉक्स और समान नाम वाला मोबाइल स्विच अलग नियम लागू कर सकते हैं। अपने प्लेटफ़ॉर्म पर नियंत्रण के पास लिखा विवरण पढ़ें, फिर जाँचें कि वह क्या करता है।
वही प्रोफ़ाइल दो क्लाइंट में अलग व्यवहार करती है
OpenVPN Connect ऐप की सेटिंग्स ऐसी टनल मोड का वर्णन करती हैं जो सामान्य ट्रैफ़िक केवल तब रोकती है जब क्लाइंट ठहरा हुआ या फिर कनेक्ट होता हुआ स्थिति बताता है, जो हर प्लेटफ़ॉर्म पर हर घटना के बारे में सामान्य वादे से संकरा है। उत्पाद का नाम नहीं, सूचीबद्ध स्थितियाँ पढ़ें। एक क्लाइंट बिल्ड के लिए लिखा विवरण दूसरे विक्रेता के क्लाइंट पर लागू नहीं होता।
Android एक ही शब्द दो नियंत्रणों के लिए दिखाता है, क्योंकि हमेशा चालू VPN और VPN के बिना कनेक्शन रोकना अलग-अलग प्रलेखित हैं। समान नाम वाले चेकबॉक्स वाला डेस्कटॉप क्लाइंट उन दोनों में से किसी से भी अधिक संकरा या व्यापक कुछ लागू कर सकता है। दो मेन्यू में साझा लेबल को तब तक संयोग मानें जब तक दोनों विवरण न पढ़ लिए जाएँ। प्रबंधित डिवाइस तीसरी परत जोड़ते हैं, क्योंकि डिवाइस प्रोफ़ाइल ऐसी सेटिंग थोप सकती है जिसे उपयोगकर्ता न देख सके न रद्द कर सके।
दिखने में समान प्लेटफ़ॉर्म सेटिंग्स समतुल्य नहीं हैं
जो नियंत्रण आप देखते हैं उसकी तुलना उस नीति से करें जो वास्तव में लागू होती है। प्रबंधित डिवाइस पर दिखने वाला स्विच धूसर हो सकता है, या चालू हो सकता है जबकि ऊँचे स्तर की प्रोफ़ाइल उल्टा थोप रही हो। स्थानीय नहीं, प्रभावी नीति माँगें, और उत्तर लिखित में लें।
कुछ भी जाँचने से पहले लिख लें कि हर परत क्या दावा करती है, क्योंकि दोनों अक्सर मेल नहीं खातीं और जाँच शुरू होने के बाद यह अंतर खो जाना आसान है। जो डिवाइस जाँच के दौरान सही रोकता है वह ऐसी वजह से रोक रहा हो सकता है जिसे किसी ने प्रलेखित नहीं किया।
एक बार में एक घटना चलाएँ और कोड लिखें
एक बार में एक घटना जाँचें, हानिरहित अनुरोध के साथ, और हर प्रयास को नया अनुरोध बनाएँ, ऐसा पृष्ठ नहीं जो पहले से कैश में हो। नीचे दिए आदेश टनल उतारते हैं, एक पृष्ठ माँगते हैं और दिखाते हैं कि इंटरफ़ेस लौटा या नहीं।
ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0तालिका हर क्रिया को उस अवलोकन से जोड़ती है जो मायने रखता है और उस प्रमाण से जो रखने योग्य है। समय-सीमा में विफल अनुरोध बताता है कि रोक लगी; सफल अनुरोध बताता है कि ट्रैफ़िक ने दूसरा रास्ता पाया, जो बंद रोक नहीं बल्कि छोड़ा गया मार्ग हो सकता है। किसी महत्वपूर्ण सॉफ़्टवेयर अद्यतन या रूटिंग नीति परिवर्तन के बाद पूरा सेट दोहराएँ, क्योंकि दोनों में से कोई भी दिखने वाली सेटिंग हिले बिना शाखा बदल सकता है। अंत में आपको पूर्वानुमेय विफलता व्यवहार चाहिए, आश्वस्त करने वाला आइकन नहीं।
| What I do | What I watch | Evidence to keep |
|---|---|---|
| Bring the tunnel down by hand | Whether a fresh request fails at once | The HTTP code and the client state at that second |
| Choose Disconnect in the client | Whether ordinary access returns on purpose | The same request succeeding with no tunnel up |
| Quit the app, then reboot | Whether the block outlives the client | A request made from a clean boot |
| Move from Wi-Fi to cellular | Whether DNS and IPv6 follow the policy | The resolver answer, the route table and the code again |
अपवाद, अतिथि पोर्टल और जो रोक नहीं कर सकती
स्थानीय नेटवर्क तक पहुँच सामान्य अपवाद है, और यह वादे का दायरा बदल देती है। क्लाइंट बाकी सब रोकते हुए उसी सबनेट के प्रिंटर तक पहुँच सकता है, जो घर पर उचित और अतिथि नेटवर्क पर संदिग्ध है। किसी घटना के आपके लिए इसे खोजने से पहले तय करें कि यह अपवाद चाहिए या नहीं।
कठोर रोक अतिथि नेटवर्क के पोर्टल में प्रवेश को भी कठिन बनाती है, क्योंकि पोर्टल ठीक वही सीधा ट्रैफ़िक है जिसे रोकने के लिए रोक मौजूद है। नेटवर्क को अधिकृत करने का समर्थित तरीका सीखें, फिर पृष्ठ लोड होने तक नियंत्रण बंद करने के बजाय नीति सोच-समझकर बहाल करें। रिज़ॉल्वर का उत्तर और रूट तालिका एक ही नोट में रखें, जैसा नीचे है। किल स्विच जो नहीं कर सकता वह है सेवा को अनाम बनाना, क्योंकि टनल के बाहर ट्रैफ़िक रोकना इस बारे में कुछ नहीं कहता कि उसके भीतर क्या होता है।
resolvectl query example.com
ss -tunp | grep -v tun0