समझौता-ग्रस्त होस्ट पर किल स्विच क्या कवर करता है, यह कैसे जाँचें

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

सर्वर से नहीं, क्लाइंट से शुरू करें

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

इसलिए पहली बात यह तय करनी है कि इस डिवाइस पर नीति किसकी है और उसे क्या ओवरराइड करने की अनुमति है। प्रबंधित कार्य मशीन पर जवाब आमतौर पर संगठन का एंडपॉइंट एजेंट होता है, और व्यक्तिगत VPN उन क्षमताओं को नहीं हटाता, टनल कैसे भी कॉन्फ़िगर हो।

पहला चरण: उन रास्तों पर ब्लॉक की पुष्टि करें जिन्हें आप कवर मानते हैं

टनल को क्लाइंट पर नहीं, दूर के सिरे पर बंद करें, ताकि क्लाइंट अब भी माने कि उसे जुड़ा होना चाहिए। फिर वही आज़माएँ जो कोई व्यक्ति वास्तव में आज़माएगा:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

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

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

दूसरा चरण: DNS और IPv6 को अलग रास्तों के रूप में जाँचें

नाम विभेदन वह अंतराल है जो अधिकांश कार्यान्वयनों में बचा रहता है, क्योंकि क्वेरी सिस्टम रिज़ॉल्वर के अलावा किसी और चीज़ से बाहर जा सकती है। ऐसे उपकरण से पूछें जो आपके रिज़ॉल्वर कॉन्फ़िगरेशन को नज़रअंदाज़ करता है, और वहीं v6 पक्ष भी जाँचें:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

टनल बंद होने पर दोनों नाम क्वेरी के खाली उत्तर ही वह परिणाम हैं जो आप चाहते हैं। अगर दूसरी क्वेरी उत्तर देती है, तो हार्डकोड किया गया रिज़ॉल्वर पता पहुँच योग्य है और टनल मशीन से बाहर जाने का एकमात्र रास्ता नहीं है। अगर केवल v6 अनुरोध सफल होता है, तो नीति IPv4 को कवर करती है और IPv6 को नज़रअंदाज़ करती है, जो दूसरे पता परिवार में वही लीक है।

ब्राउज़र इसे बाहर से पढ़ना कठिन बनाते हैं, क्योंकि DNS over HTTPS के लिए कॉन्फ़िगर किया गया ब्राउज़र क्वेरी को HTTPS अनुरोध से हल करता है: क्वेरी उतनी ही अवरुद्ध है जितना उस सिरे तक पोर्ट 443 अवरुद्ध है। जिस होस्ट पर नीति स्थानीय सबनेट की अनुमति देती है, वहाँ वह अनुरोध अब भी LAN के रिज़ॉल्वर तक पहुँच सकता है।

तीसरा चरण: नेटवर्क एक्सपोज़र को एंडपॉइंट एक्सपोज़र से अलग करें

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

यही बात उस मॉनिटरिंग सॉफ़्टवेयर पर भी लागू होती है जिसे किसी नियोक्ता ने जानबूझकर स्थापित किया है। रास्ते रोकने से वह हटता नहीं, और नया VPN सर्वर खरीदना समाधान नहीं है, क्योंकि एक्सपोज़र टनल से पहले है।

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

चौथा चरण: वह दावा लिखें जिसे आपका परीक्षण समर्थन देता है

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

दोनों समस्याएँ अलग रखें और हर एक को उसका अपना नियंत्रण दें:

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

अगले अपडेट के बाद क्रम फिर चलाएँ, क्योंकि किल स्विच ऐसा कॉन्फ़िगरेशन है जो संस्करणों के साथ चलता है। परीक्षण ही वह एकमात्र प्रमाण है कि जिस व्यवहार पर आप भरोसा करते हैं वह अब भी वही है जो आपको मिलता है।