Always-on VPN विरुद्ध kill switch: तुम्ही प्रत्यक्षात काय सुरू केले?
Always-on VPN टनेल पुन्हा जोडते; kill switch त्याशिवाय काय बाहेर जाऊ शकते हे ठरवते. लेबलवर विश्वास ठेवण्यापूर्वी पाच तपासण्या.
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 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 सर्व्हरपर्यंत पोहोचावे लागते, म्हणून सर्व काही टाकून देणारा नियमसंच संरक्षण परत आणणारी पुनर्जोडणीही रोखतो. 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 मधील संक्रमणे आणि एक मुद्दाम अयशस्वीता आहेत. कमांड आउटपुटने भरता न येणारी ओळ म्हणजे तुम्ही तपासली नाही अशी ओळ, आणि पुनर्जोडणीची ओळ पास होऊन बूटच्या ओळीत अयशस्वी होणारे उपकरण पुरेसे सामान्य आहे, म्हणून अधिक दहा मिनिटे मोलाची आहेत.
हे पूर्ण म्हणण्यापूर्वी:
- ब्लॉकिंग सेटिंग पुनर्जोडणी सेटिंगपेक्षा वेगळी असल्याची खात्री करा आणि तिचे मूल्य उपकरणावर वाचा.
- ब्लॉक कोणता स्तर लागू करतो - क्लायंट पर्याय, उपकरण धोरण किंवा फायरवॉल - आणि तो स्तर कुठे संरचित आहे हे जाणून घ्या.
- ब्लॉक सिद्ध करणारी एक तपासणी कमांड ठेवा आणि ती संक्रमणाच्या वेळी चालवा, नंतर नाही.
- अपवादांची यादी एंडपॉइंटसह लिहा आणि ती कोण अद्ययावत करतो ते नोंदवा.
- व्यवस्थापित हार्डवेअरवर लागू केलेले धोरण तसेच ठेवा; ब्लॉक काढणे टनेल दुरुस्त करण्याऐवजी आवश्यकता बदलते.