क्या VPN किल स्विच रीबूट के बाद टिकता है? इसे कैसे जाँचें

रीबूट करना लोगों द्वारा किल स्विच परखने का सबसे आम तरीका है, और यही वह परीक्षण है जो सबसे ज़्यादा झूठ बोलता है। क्लाइंट में चेकबॉक्स एक वरीयता मात्र है; असली बात यह है कि क्या कोई चीज़ नेटवर्क स्टैक के उठने के क्षण और टनल के वास्तव में स्थापित होने के क्षण के बीच ब्लॉक लागू करती है। Windows पर वह चीज़ आमतौर पर Windows Filtering Platform में एक फ़िल्टर होती है, Linux पर किसी यूनिट द्वारा लोड किया गया नियम-समूह, macOS पर pf एंकर, Android पर सिस्टम के अपने ऑलवेज़-ऑन और लॉकडाउन फ़्लैग। ये व्यवस्थाएँ रीबूट के दौरान बहुत अलग व्यवहार करती हैं, और किसी के भी साइन इन कर सकने से पहले केवल प्लेटफ़ॉर्म-स्तरीय व्यवस्थाएँ ही अपनी जगह पर होती हैं।

रीबूट तीन अलग सवाल पूछता है

सवाल को बाँटिए। पहला, क्या नीति डिस्क पर ऐसे रूप में मौजूद है जिसे बूट के समय कोई चीज़ पढ़ती है? दूसरा, क्या वह पाठक किसी भी ट्रैफ़िक के बाहर निकलने से पहले चलता है? तीसरा, क्या नीति उस ट्रैफ़िक को ढकती है जिसकी आपको परवाह है, यानी हर प्रक्रिया, दोनों एड्रेस परिवार और DNS। पहले पर हाँ और दूसरे पर ना ठीक वही विफलता पैदा करते हैं जिसे लोग ऐसे किल स्विच के रूप में बताते हैं जो रीबूट के बाद नहीं टिकता: शुरू में कुछ सेकंड के लिए ट्रैफ़िक बाहर निकल जाता है, और कोई तब तक ध्यान नहीं देता जब तक कोई देखने न जाए।

परतों को अलग रखिए। सहेजा गया फ़ायरवॉल नियम-समूह, बूट पर शुरू होने वाली सेवा और क्लाइंट की वरीयता तीन अलग वस्तुएँ हैं जिनके तीन अलग जीवनकाल हैं। वरीयता रीबूट के बाद टिकती है क्योंकि वह कॉन्फ़िग फ़ाइल में एक मान है। नियम ही एकमात्र चीज़ हैं जो पैकेट ब्लॉक करते हैं, और वे उस कर्नेल के साथ गायब हो जाते हैं जो उन्हें थामे हुए था।

वह वस्तु खोजिए जो ब्लॉक बहाल करती है

Linux पर netfilter नियम कर्नेल में रहते हैं। जब तक आपने व्यवस्था न की हो, बूट के समय कोई उन्हें वापस नहीं लिखता: iptables-save के साथ netfilter-persistent, nftables.service लोड करता है /etc/nftables.conf, या कोई systemd यूनिट जो आपकी अपनी स्क्रिप्ट चलाती है। जाँचिए कि क्या सक्षम है, यह याद करने के बजाय कि आपने क्या कॉन्फ़िगर किया था।

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

बूट के कुछ सेकंड बाद खाली नियम-समूह शीर्षक के सवाल का जवाब है। Windows पर क्लाइंट सेवा से पूछिए कि वह कैसे शुरू होती है, फिर टनल के नीचे होने पर प्लेटफ़ॉर्म फ़िल्टर की स्थिति डंप कीजिए।

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

दूसरा कमांड wfpstate.xml को मौजूदा डायरेक्टरी में लिखता है। ऐसे फ़िल्टर खोजिए जिनमें ब्लॉक क्रिया हो और जो क्लाइंट के जुड़ने से पहले से मौजूद हों। Base Filtering Engine बूट में जल्दी शुरू होता है और स्थायी फ़्लैग के साथ जोड़े गए फ़िल्टर बहाल करता है, इसीलिए कुछ किल स्विच किसी भी क्लाइंट विंडो के बनने से पहले ट्रैफ़िक ब्लॉक करते हैं और कुछ नहीं। macOS पर sudo pfctl -s info बताता है कि pf सक्षम है या नहीं, sudo pfctl -s rules दिखाता है कि क्या लोड है, और VPN क्लाइंट आमतौर पर अपने नियम मुख्य नियम-समूह के बजाय किसी एंकर से जोड़ते हैं। जो नियम utun3 का नाम लेता है वह अगले बूट के बाद किसी दूसरे इंटरफ़ेस की ओर संकेत कर सकता है, क्योंकि वह नंबर रनटाइम में दिया जाता है।

नेटवर्क उठने और टनल उठने के बीच के अंतराल पर नज़र रखिए

खतरनाक अवधि पूरा रीबूट नहीं है, बल्कि वह अंतराल है। इंटरफ़ेस को एक क्षण पर लीज़ और डिफ़ॉल्ट रूट मिलता है, VPN सेवा दूसरे क्षण पर शुरू होती है, और टनल और बाद में प्रमाणीकरण करता है, कभी-कभी तो उपयोगकर्ता के साइन इन करने और क्रेडेंशियल एजेंट के चलने के बाद ही। अगर ब्लॉक सबसे अंत में लागू होता है, तो अंतराल में सब कुछ खुले में बाहर चला जाता है।

systemd होस्ट पर अनुमान लगाने के बजाय क्रम पढ़िए। systemctl cat को VPN और फ़ायरवॉल यूनिटों पर चलाइए और After= या Before= को network-pre.target और network-online.target के सामने देखिए। network-online.target के बाद क्रमबद्ध फ़ायरवॉल यूनिट इंटरफ़ेस से हार जाती है; जिसे network-pre.target माँगता है और जो उससे पहले क्रमबद्ध है, वह जीतती है। Windows पर समतुल्य सवाल सेवा का स्टार्ट प्रकार और उसकी निर्भरताएँ हैं, क्योंकि Manual पर सेट सेवा बूट-कालीन प्रक्रिया को ब्लॉक नहीं कर सकती। अगर आपकी आवश्यकता में साइन-इन से पहले का ट्रैफ़िक भी शामिल है, तो केवल डिवाइस-स्तरीय व्यवस्था ही उसे पूरा करती है: Always On VPN डिवाइस टनल मशीन प्रमाणपत्र से प्रमाणीकरण करता है और उपयोगकर्ता के लॉग इन करने से पहले जुड़ जाता है, और माइक्रोसॉफ़्ट डिवाइस टनल के कॉन्फ़िगरेशन का दस्तावेज़ बनाती है उपयोगकर्ता टनल से अलग। Android दूसरा रास्ता लेता है, ऑलवेज़-ऑन VPN थोपता है और उसके बिना कनेक्शनों को ऐप प्रक्रिया से नहीं बल्कि सिस्टम से ब्लॉक करता है।

परीक्षण चलाइए, फिर दो समयरेखाओं की तुलना कीजिए

ऐसे गंतव्य के साथ रीबूट कीजिए जो लीक होने पर कुछ भी महँगा न पड़े, और स्थिति को अंतराल के बाद नहीं बल्कि अंतराल के दौरान कैप्चर कीजिए। सबसे साफ़ तरीका बूट-कालीन प्रोब है: कोई oneshot यूनिट या शेड्यूल किया गया कार्य जो प्लेटफ़ॉर्म जितनी जल्दी अनुमति दे उतनी जल्दी शुरू होता है, डिफ़ॉल्ट रूट और फ़ायरवॉल की स्थिति दर्ज करता है, छोटे टाइमआउट के साथ एक अनुरोध आज़माता है और स्थानीय फ़ाइल में एक पंक्ति जोड़ता है। उस रिकॉर्ड की तुलना journalctl -b -u या सिस्टम लॉग से मिलने वाले VPN सेवा के शुरू होने के समय से कीजिए।

फिर सामान्य परीक्षण चलाइए: टनल ऊपर, कनेक्शन काटिए, देखिए कि सीधा ट्रैफ़िक ब्लॉक होता है या नहीं, बहाल कीजिए। दूसरे में पास होना और पहले में विफल होना सामान्य परिणाम है, और इसका मतलब है कि प्रवर्तन क्लाइंट-पक्ष पर है, क्लाइंट के जुड़ने पर लागू होता है, बूट पर नहीं। जिस अंतिम मशीन का मैंने ऑडिट किया, उसमें ब्लॉक NetworkManager की डिस्पैचर स्क्रिप्ट से आया था: मौजूद और सही और इंटरफ़ेस के उठने से पहले के सेकंडों के लिए बेकार। दोनों परिणाम लिख लीजिए, क्योंकि रीबूट में टिकना तभी मायने रखता है जब आप बताएँ कि कौन-सी परत टिकी और किस क्षण से।

वापसी का रास्ता तोड़े बिना अंतराल बंद कीजिए

अगर बूट पर ब्लॉक नहीं है, तो दूसरा क्लाइंट नियम जोड़ने के बजाय प्रवर्तन को एक परत नीचे ले जाइए। नियम-समूह सहेजिए और उसे ऐसी यूनिट से लोड कीजिए जो नेटवर्क के उपयोग योग्य होने से पहले क्रमबद्ध हो, और सुनिश्चित कीजिए कि उस यूनिट को ऐसा DNS लुकअप या नेटवर्क माउंट नहीं चाहिए जिसे उसे बचाना है। दायरा समय जितना ही ज़रूरी है: उपयोगकर्ता ID या cgroup से मेल खाने वाले नियम हर सिस्टम डेमॉन को ब्लॉक से बाहर छोड़ देते हैं, और केवल IPv4 संभालने वाला नियम-समूह IPv6 और DNS को पहुँच योग्य छोड़ देता है।

अपने लिए वापसी का रास्ता छोड़िए। जो मशीन बूट पर सब कुछ ब्लॉक करती है और फिर प्रमाणीकरण नहीं कर पाती, उसके पास नेटवर्क ही नहीं होता, और उपाय ब्लॉक हटाना नहीं बल्कि क्रेडेंशियल या क्रम ठीक करना है। स्थानीय कंसोल के लिए प्रलेखित प्रक्रिया और टनल को वास्तव में जिसकी ज़रूरत है उसके लिए एक संकीर्ण, जानबूझकर किया गया अपवाद रखिए, जैसे सर्वर का पता और टनल से पहले इस्तेमाल होने वाला रिज़ॉल्वर।

व्यवस्था पर भरोसा करने से पहले चार चीज़ें क्रम से पुष्ट कीजिए। नीति वहाँ संग्रहीत है जहाँ से बूट पढ़ता है। वह पाठक इंटरफ़ेस के उपयोग योग्य होने से पहले चलता है। ब्लॉक दोनों एड्रेस परिवारों और DNS को ढकता है। ब्लॉक सक्रिय रहते हुए भी VPN प्रमाणीकरण कर सकता है। जब चारों लागू होते हैं, रीबूट कुछ नहीं बदलता।