सम्झौता भएको होस्टमा किल स्विचले के समेट्छ भनेर कसरी परीक्षण गर्ने

किल स्विच सक्रिय गर्नुहोस्, टनेल सर्भर अफलाइन गर्नुहोस् र मेसिनले अझै के गर्छ हेर्नुहोस्। यो परीक्षण गर्न लायक छ, किनभने यसले फायरवालले वास्तवमा के लागू गर्छ र तपाईंले के अनुमान गर्नुभयो छुट्याउँछ, र नतिजाहरू अधिकांश उत्पादन पृष्ठहरूले संकेत गरेभन्दा साँघुरा छन्। किल स्विचले नेटवर्क बाटोहरू नियन्त्रण गर्छ; यसले यन्त्रमा पहिले नै चलिरहेको सफ्टवेयरलाई नियन्त्रण गर्दैन। क्लाइन्ट 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 ले कस्तो व्यवहार गरे, र टनेल खस्दा ब्लक टिक्यो कि टिकेन। तपाईं अपरेटिङ सिस्टम सफा छ भन्न सक्नुहुन्न, र टाढाको छेउको सेवाले तपाईंको लगइन गोप्य राख्छ भनेर पनि भन्न सक्नुहुन्न।

दुई समस्यालाई छुट्टै राख्नुहोस् र प्रत्येकलाई आफ्नै नियन्त्रण दिनुहोस्:

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

अर्को अपडेटपछि क्रम फेरि चलाउनुहोस्, किनभने किल स्विच संस्करणसँगै सर्ने कन्फिगरेसन हो। तपाईं भर पर्नुभएको व्यवहार अझै तपाईंले पाउने व्यवहार हो भन्ने एकमात्र प्रमाण परीक्षण हो।