Always-on VPN बनाम किल स्विच: आपने असल में क्या चालू किया?
Always-on VPN टनल दोबारा जोड़ता है; किल स्विच तय करता है कि उसके बिना क्या बाहर जा सकता है। लेबल पर भरोसा करने से पहले पाँच जाँचें।
Always-on और किल स्विच एक ही सेटिंग स्क्रीन में दो पंक्तियों की दूरी पर होते हैं, इसलिए लोग उन्हें एक ही सुविधा के दो नाम समझ लेते हैं। वे नहीं हैं। Always-on एक पुनः कनेक्ट नीति है: बूट पर टनल शुरू करना, क्रैश या नेटवर्क बदलने के बाद उसे वापस लाना, और विफल रहने पर लगातार फिर कोशिश करना। किल स्विच एक ट्रैफ़िक नीति है: वह उन पैकेटों को नाम देता है जो टनल बंद होने पर भी मशीन से बाहर जा सकते हैं। आप पहला चालू कर सकते हैं बिना दूसरे के, और ज़्यादातर प्लेटफ़ॉर्म पर डिफ़ॉल्ट नतीजा उस अंतराल में भी ट्रैफ़िक बाहर जाने देता है।
जाँच 1: क्या ब्लॉक अपने आप में एक स्विच है?
Android 10 और उसके बाद, सहेजा गया VPN प्रोफ़ाइल गियर आइकन के पीछे दो स्वतंत्र टॉगल खोलता है: Always-on VPN और Block connections without VPN। किल स्विच केवल दूसरा है। अकेले always-on के साथ टनल गिरने के बाद वापस आता है, और अनुरोध के बीच में मौजूद कोई भी ऐप तब तक Wi-Fi या मोबाइल डेटा से नेटवर्क तक पहुँच सकता है।
प्रबंधित डिवाइस नीति API में वही विभाजन रखते हैं। setAlwaysOnVpnPackage() पैकेज का नाम और lockdownEnabled फ़्लैग लेता है; जो एडमिन पैकेज सेट करके फ़्लैग false छोड़ देता है, उसने लगातार बना टनल बनाया है, बंद डिवाइस नहीं। कंसोल की भाषा यह अंतर शायद ही कभी दिखाती है।
स्थिति कंसोल के बजाय डिवाइस से पढ़ें: adb shell settings get global always_on_vpn_app और adb shell settings get global always_on_vpn_lockdown। अगर पहला null लौटाता है, तो प्लेटफ़ॉर्म स्तर पर कोई पैकेज लागू नहीं है; अगर दूसरा 0 लौटाता है, तो प्लेटफ़ॉर्म कुछ भी नहीं रोक रहा। Android VPN गाइड इन्हें एक मोड के बजाय अलग-अलग क्षमताओं के रूप में बताता है।
जाँच 2: ब्लॉक किस परत का है?
लेबल क्लाइंट में रहते हैं और ब्लॉक आम तौर पर फ़ायरवॉल में, इसलिए वही शब्द हर प्लेटफ़ॉर्म पर अलग अर्थ रखता है। नीचे दी पंक्तियाँ वही हैं जिन्हें किसी पर भी भरोसा करने से पहले पुष्टि करना चाहिए।
| Where you see the label | What the label promises | What actually blocks |
|---|---|---|
| Android VPN profile | Always-on VPN | Block connections without VPN |
| Android device policy | Always-on package | lockdownEnabled flag |
| Windows built-in VPN | Always On tunnel | Outbound firewall rules |
| WireGuard for Windows | Tunnel service | Block untunneled traffic option |
| wg-quick on Linux | Route via AllowedIPs | Your own nftables or iptables rules |
Windows उस लेबल का सबसे साफ़ उदाहरण है जो ब्लॉक नहीं करता। वहाँ Always On टनल की निरंतरता बताता है: मशीन प्रमाणीकरण के लिए डिवाइस टनल, साइन-इन खाते के लिए यूज़र टनल, जो प्रोफ़ाइल XML या Add-VpnConnection से सेट होती है। उस प्रोफ़ाइल में कुछ भी टनल न होने पर बाहर जाने वाला पैकेट नहीं रोकता, और आउटबाउंड फ़िल्टरिंग डिफ़ॉल्ट रूप से चालू नहीं है, इसलिए Wi-Fi पर लैपटॉप VPN बंद होने पर भी काम करता रहता है।
WireGuard उसी तरह बँटता है, पर क्लाइंट के हिसाब से। WireGuard for Windows में प्रति-टनल Block untunneled traffic विकल्प है जो फ़िल्टर नियम लगाता है; Linux टूलींग में ऐसा कोई स्विच नहीं। wg-quick हर AllowedIPs प्रविष्टि के लिए एक रूट और एक fwmark नियम जोड़ता है, और wg-quick down दोनों हटा देता है, इसलिए भौतिक डिफ़ॉल्ट रूट बिना कोई पैकेट गिराए फिर से संभाल लेता है।
Apple प्लेटफ़ॉर्म पर always-on पर्यवेक्षित डिवाइसों के लिए प्रबंधन-प्रोफ़ाइल सुविधा के रूप में आता है और चेकबॉक्स के बजाय on-demand नियमों में व्यक्त होता है। पेलोड से जिस सवाल का जवाब चाहिए वह यह है कि विफल टनल ट्रैफ़िक रोकता है या सिर्फ़ दूसरा कनेक्शन माँगता है। मेन्यू का शीर्षक यह नहीं बताएगा।
जाँच 3: खाई नापें, आइकन नहीं
चार बदलाव मायने रखते हैं, और वे अलग-अलग तरह से विफल होते हैं: किसी के लॉग इन करने से पहले बूट, स्लीप और रिज़्यूम, Wi-Fi से मोबाइल डेटा पर जाना, और क्लाइंट क्रैश जो टनल इंटरफ़ेस को आधा कॉन्फ़िगर छोड़ देता है। इनमें से एक पर साफ़ पुनः कनेक्शन बाकी तीन के बारे में कुछ साबित नहीं करता।
सबसे सस्ता परीक्षण जानबूझकर टनल बंद करता है और फिर बाहर निकलने की कोशिश करता है। टनल बंद होने पर curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com का 200 लौटाना मतलब नीति fail-open है; टाइमआउट या अस्वीकृत कनेक्शन मतलब कुछ अभी भी रोक रहा है। ip route get 1.1.1.1 उस इंटरफ़ेस का नाम बताता है जो पैकेट ले जाएगा, जो आम तौर पर ट्रे आइकन से ज़्यादा जानकारी देता है, और systemctl status wg-quick@wg0 दिखाता है कि इंटरफ़ेस साफ़ तरह से हटा था या नहीं।
वही जाँच दूसरी विंडो में चलाएँ जब नेटवर्क बदल रहा हो, सिर्फ़ स्थिर होने के बाद नहीं। गिरावट और दोबारा कोशिश के बीच का अंतराल ही असली बात है, और नाम-रिज़ॉल्यूशन सबसे तेज़ तरीका है यह देखने का कि ट्रैफ़िक बच गया: अगर टनल बंद होने पर स्थानीय रिज़ॉल्वर जवाब देता है, तो ब्लॉक पूरा नहीं है।
जाँच 4: लॉक करने से पहले अपवाद तय करें
दो अपवाद संरचनात्मक हैं। क्लाइंट को खुद VPN सर्वर तक पहुँचना होता है, इसलिए जो नियम-सेट सब कुछ गिरा देता है वह उस पुनः कनेक्शन को भी रोकता है जो सुरक्षा वापस लाएगा। कैप्टिव पोर्टल तक ऐसे टनल से नहीं पहुँचा जा सकता जो चालू न हो, इसलिए होटल के Wi-Fi पर बंद डिवाइस को पोर्टल खोलने का लिखित तरीका चाहिए, अनौपचारिक नहीं।
एक न्यूनतम ढाँचा, एंडपॉइंट की अनुमति और बाकी सब गिरा हुआ:
table inet vpnlock {
chain output {
type filter hook output priority 0; policy drop;
oifname "lo" accept
ip daddr 203.0.113.10 udp dport 51820 accept
oifname "wg0" accept
}
}उस एंडपॉइंट पंक्ति को स्थिरांक नहीं, चर मानें। प्रदाता पते बदलते हैं, और पुराना अपवाद ही आम कारण है कि काम करता किल स्विच ऐसा डिवाइस बन जाता है जो दोबारा कनेक्ट नहीं हो पाता। स्थानीय प्रिंटर, NAS शेयर और डेवलपमेंट सेवाएँ उसी लिखित सूची में होनी चाहिए, वरना वे एक-एक सपोर्ट टिकट में पकड़ी जाती हैं।
जाँच 5: दर्ज करें कि आपने असल में क्या साबित किया
चार कॉलम की तालिका रखें और उसे परीक्षण से भरें: स्थिति, अपेक्षित व्यवहार, देखा गया व्यवहार, साक्ष्य। पंक्तियाँ जाँच 3 के बदलाव और एक जानबूझकर विफलता हैं। जिस पंक्ति को आप कमांड आउटपुट से नहीं भर सकते, वह पंक्ति आपने परखी नहीं, और जो डिवाइस पुनः कनेक्शन की पंक्ति पास करके बूट की पंक्ति में विफल होता है वह इतना आम है कि अतिरिक्त दस मिनट बनते हैं।
इसे पूरा कहने से पहले:
- पक्का करें कि ब्लॉकिंग सेटिंग पुनः कनेक्शन सेटिंग से अलग है, और डिवाइस पर उसका मान पढ़ें।
- जानें कि ब्लॉक कौन-सी परत लागू करती है - क्लाइंट विकल्प, डिवाइस नीति या फ़ायरवॉल - और वह कहाँ कॉन्फ़िगर है।
- एक जाँच कमांड रखें जो ब्लॉक साबित करे, और उसे बदलाव के दौरान चलाएँ, बाद में नहीं।
- अपवाद सूची लिखें, एंडपॉइंट सहित, और नोट करें कि उसे कौन ताज़ा करता है।
- प्रबंधित हार्डवेयर पर लागू नीति को अकेला छोड़ें; ब्लॉक हटाना टनल सुधारने के बजाय आवश्यकता बदल देता है।