Always-on र kill switch एउटै सेटिङ स्क्रिनमा दुई लाइनको दूरीमा हुन्छन्, त्यसैले मानिसहरू तिनलाई एउटै सुविधाका दुई नामका रूपमा पढ्छन्। तिनीहरू त्यस्ता होइनन्। Always-on पुनः जडान नीति हो: बुटमा सुरुङ सुरु गर्नु, क्र्यास वा नेटवर्क परिवर्तनपछि त्यसलाई फर्काउनु, र असफल हुँदा फेरि प्रयास गरिरहनु। Kill switch ट्राफिक नीति हो: सुरुङ बन्द हुँदा कुन प्याकेटहरू अझै मेसिनबाट बाहिर जान सक्छन् भनेर यसले नाम दिन्छ। पहिलो दोस्रोबिना सक्रिय गर्न सकिन्छ, र धेरैजसो प्ल्याटफर्ममा पूर्वनिर्धारित नतिजाले त्यो अन्तरालमा पनि ट्राफिक बाहिर जान दिन्छ।

जाँच 1: ब्लक आफ्नै स्विच हो?

Android 10 र त्यसपछिका संस्करणमा, सुरक्षित VPN प्रोफाइलले गियर आइकनपछाडि दुई स्वतन्त्र टगल खोल्छ: Always-on VPN र Block connections without VPN। kill switch दोस्रो मात्र हो। एक्लै 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 labelWhat the label promisesWhat actually blocks
Android VPN profileAlways-on VPNBlock connections without VPN
Android device policyAlways-on packagelockdownEnabled flag
Windows built-in VPNAlways On tunnelOutbound firewall rules
WireGuard for WindowsTunnel serviceBlock untunneled traffic option
wg-quick on LinuxRoute via AllowedIPsYour 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 सर्भरमा पुग्नुपर्छ, त्यसैले सबै खसाल्ने नियमसमूहले सुरक्षा फर्काउने पुनःजडान पनि रोक्छ। Captive portal पनि नउठेको सुरुङबाट पुग्न सकिँदैन, त्यसैले होटलको 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
  }
}

त्यो इन्डपोइन्ट लाइनलाई स्थिरांक होइन, चर मान्नुहोस्। प्रदायकहरू ठेगाना फेर्छन्, र पुरानो अपवाद नै काम गर्ने kill switch पुनःजडान गर्न नसकिने यन्त्र बन्ने सामान्य कारण हो। स्थानीय प्रिन्टर, NAS साझेदारी र विकास सेवाहरू त्यही लिखित सूचीमा पर्छन्, नत्र ती एक-एक सहयोग टिकटमा भेटिन्छन्।

जाँच 5: वास्तवमा के प्रमाणित गर्नुभयो त्यो लेख्नुहोस्

चार स्तम्भको तालिका राख्नुहोस् र परीक्षणले भर्नुहोस्: स्थिति, अपेक्षित व्यवहार, अवलोकन गरिएको व्यवहार, प्रमाण। पङ्क्तिहरू जाँच 3 का संक्रमण र एउटा जानाजान असफलता हुन्। कमाण्ड आउटपुटले भर्न नसकिने पङ्क्ति तपाईंले नपरीक्षण गरेको पङ्क्ति हो, र पुनःजडान पङ्क्ति पास गरेर बुट पङ्क्तिमा असफल हुने यन्त्र पर्याप्त सामान्य छ, त्यसैले थप दस मिनेट सार्थक हुन्छ।

यसलाई सकियो भन्नुअघि:

  • ब्लकिङ सेटिङ पुनःजडान सेटिङभन्दा अलग छ भनी पुष्टि गर्नुहोस्, र त्यसको मान यन्त्रमा पढ्नुहोस्।
  • ब्लक कुन तहले लागू गर्छ - क्लाइन्ट विकल्प, यन्त्र नीति वा फायरवाल - र त्यो तह कहाँ कन्फिगर हुन्छ जान्नुहोस्।
  • ब्लक प्रमाणित गर्ने एउटा जाँच कमाण्ड राख्नुहोस्, र त्यो संक्रमणको समयमा चलाउनुहोस्, पछि होइन।
  • अपवादको सूची इन्डपोइन्टसहित लेख्नुहोस्, र त्यसलाई कसले अद्यावधिक गर्छ टिप्नुहोस्।
  • व्यवस्थित हार्डवेयरमा लागू नीतिलाई बाँकी राख्नुहोस्; ब्लक हटाउनु सुरुङ सुधार्नुको सट्टा आवश्यकता बदल्नु हो।

सम्बन्धित लेखहरू