तडजोड झालेल्या होस्टवर किल स्विच काय संरक्षित करतो हे कसे तपासावे

किल स्विच सुरू करा, टनल सर्व्हर ऑफलाइन करा आणि मशीन अजून काय करते ते पहा। ही चाचणी करण्यासारखी आहे, कारण ती फायरवॉल प्रत्यक्षात काय लागू करतो आणि तुम्ही काय गृहीत धरले होते हे वेगळे करते, आणि निकाल बहुतेक उत्पादन पाने सुचवतात त्यापेक्षा अरुंद आहेत। किल स्विच नेटवर्क मार्ग नियंत्रित करतो; तो डिव्हाइसवर आधीच चालू असलेल्या सॉफ्टवेअरला नियंत्रित करत नाही। क्लायंट 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 ने कसे वागले आणि टनल पडल्यावर ब्लॉक टिकला का। तुम्ही असे म्हणू शकत नाही की ऑपरेटिंग सिस्टम स्वच्छ आहे, आणि दूरच्या टोकावरील सेवा तुमचे लॉगिन खाजगी ठेवेल असेही म्हणू शकत नाही।

दोन्ही समस्या वेगळ्या ठेवा आणि प्रत्येकाला त्याचे स्वतःचे नियंत्रण द्या:

• किल स्विच: निर्धारित अयशस्वीता आवश्यकता, प्रत्येक क्लायंट अपग्रेडनंतर पुनरावृत्ती होणाऱ्या आउटेज चाचणीने सत्यापित।
• डिव्हाइस विश्वास: समर्थित अद्यतने, विश्वासार्ह स्रोताकडून एंडपॉइंट संरक्षण, अस्पष्ट परवानग्या आणि प्रमाणीकरण विनंत्या यांचे पुनरावलोकन।
• घटना: तडजोडीचा संशय असल्यास प्लॅटफॉर्म किंवा संस्थेच्या प्रक्रियेचे पालन करा; नवीन सर्व्हर स्वच्छतेची पायरी नाही।
• प्रकटीकरण: मदत मागताना खाजगी की किंवा संपूर्ण निदान संग्रह पेस्ट करू नका, कारण लॉग आणि स्क्रीनशॉट कनेक्शनप्रमाणेच तीच रहस्ये वाहतात।

पुढील अद्यतनानंतर क्रम पुन्हा चालवा, कारण किल स्विच आवृत्त्यांसोबत हलणारे कॉन्फिगरेशन आहे। तुम्ही अवलंबून असलेले वर्तन अजूनही तुम्हाला मिळणारे वर्तन आहे याचा एकमेव पुरावा चाचणी आहे।