तुम्ही टनेलमधून वगळलेल्या ॲपला तुमचा किल स्विच ब्लॉक करेल का?

किल स्विच चालू आहे, एक ॲप जाणूनबुजून टनेलमधून वगळले आहे, आणि दोन्ही आवश्यकता आता एकमेकांच्या विरोधात आहेत। एक सांगते की टनेलशिवाय काहीही बाहेर जाऊ शकत नाही, दुसरी सांगते की या प्रोग्रामने थेट जायला हवे। प्रत्येक क्लायंट हा संघर्ष वेगळ्या पद्धतीने सोडवतो, आणि सेटिंग्ज पान कोणता नियम जिंकतो हे क्वचितच स्पष्ट करते। कोणत्याही लेबलवर विश्वास ठेवण्यापूर्वी प्रत्येक ॲपसाठी धोरण लिहा।

दोन धोरणे, एक मशीन

किल स्विच हे अपयशाबद्दलचे वचन आहे: जेव्हा टनेल रहदारीचे संरक्षण करत नाही, तेव्हा रहदारी थांबते। विभाजित टनेल हे निवडीबद्दलचे वचन आहे: हे प्रोग्राम किंवा गंतव्ये टनेल वापरतात, आणि ती वापरत नाहीत। दुसरे वचन अशी रहदारी निर्माण करते ज्याबद्दल पहिल्याने निर्णय घ्यायचा आहे। कोणतेही वचन चुकीचे नाही; फक्त वेगवेगळ्या लोकांनी ती वेगवेगळ्या धोक्यांसाठी लिहिली।

तीन परिणाम शक्य आहेत आणि त्यापैकी फक्त एकच तैनातीचा उद्देश होता। वगळलेले ॲप व्यत्ययादरम्यान थेट राहू शकते, जे विभाजनाचा आदर करते आणि किल स्विच तोडते। ते बाकीच्या सर्वांसोबत ब्लॉक केले जाऊ शकते, जे किल स्विचचा आदर करते आणि विभाजन तोडते। किंवा इंटरफेस अदृश्य झाल्यानंतर प्लॅटफॉर्म नियमाचे मूल्यांकन कसे करते यावर अवलंबून ते फक्त कधीकधी ब्लॉक केले जाऊ शकते। तोच शेवटचा प्रसंग तिकिटे निर्माण करतो।

नियमापूर्वी ॲपची यादी लिहा

टनेल वापरायचे प्रोग्राम, थेट जायचे प्रोग्राम, आणि कोणत्याही यादीत कधीही दिसू नयेत अशी नावे किंवा गंतव्ये यांची यादी करा। रिझॉल्व्हरचे वर्तन आणि IPv6 बाजू वेगळी समाविष्ट करा, कारण दोन्ही पान रहदारीपेक्षा वेगळे धोरण अनुसरू शकतात।

प्रत्येक ॲपचे नियम सामान्यतः एक्झिक्युटेबल फाइल किंवा पॅकेजशी जुळतात, त्यातील प्रोफाइलशी नाही। ब्राउझर प्रोफाइल, खाजगी विंडो आणि एक्स्टेन्शन स्वतःची नेटवर्क ओळख ठेवत नाहीत, त्यामुळे प्रोसेसला जे मिळाले ते ते वारसाहक्काने घेतात। त्या ब्राउझरने सुरू केलेली सहाय्यक प्रोसेस तोच नियम अजिबात वारसाहक्काने घेऊ शकत नाही।

एक नाही, दोन याद्या लागतात: टनेलने काय वाहून न्यायचे आहे, आणि कशालाही कारणाने त्याबाहेर जाऊ नये। दोन्हीत दिसणारे ॲप अंमलबजावणीचा तपशील नाही तर आवश्यकतेचा संघर्ष आहे, आणि क्लायंट संरचीत करण्यापूर्वी तो सोडवावा लागतो।

व्यत्ययादरम्यान क्लायंट काय करतो

काही अंमलबजावणी व्यत्ययादरम्यान वगळलेली ॲप ब्लॉक करतात आणि पुन्हा जोडल्यावर त्यांचा प्रवेश पुनर्संचयित करतात। इतर थेट मार्ग सतत टिकवतात, जे विभाजनाशी सुसंगत आहे आणि सुरक्षा गुणधर्म म्हणून कमकुवत आहे। प्लॅटफॉर्म स्तरावरील लॉकडाउन क्लायंटची प्रत्येक ॲपशी निवड पूर्णपणे रद्द करू शकते। हा फरक दिसण्यापुरता नाही, कारण वगळलेले ॲप धोरणातील अपवाद आहे की भोक, हे तोच ठरवतो।

VPN शिवाय कनेक्शन ब्लॉक करण्याच्या पर्यायासह Androidचा सतत-चालू VPN हा सर्वात स्पष्ट प्रसंग आहे, कारण लॉकडाउन क्लायंट नाही तर प्लॅटफॉर्म लागू करतो, आणि टनेल बंद असताना वगळलेले पॅकेज बाकीच्या सर्वांसोबत ब्लॉक होते। स्वतःच्या ड्रायव्हरमध्ये प्रत्येक ॲपचे अपवाद लागू करणारा डेस्कटॉप क्लायंट सामान्यतः वगळलेली प्रोसेस भौतिक इंटरफेसवर सोडतो, कारण त्या प्रोसेसची रहदारी त्याची होतीच नाही। दोन्ही वर्तन समर्थनीय आहेत आणि त्यापैकी एकच वगळलेले ॲप वापरण्यायोग्य राहिले पाहिजे या आवश्यकतेशी जुळते। निकालाचा अर्थ लावण्यापूर्वी कोणता घटक नियम लागू करतो ते विचारा।

तुमच्यासमोरच्या ऑपरेटिंग सिस्टमचे वर्तन वाचा, दुसरीकडे त्याच नावाची सेटिंग नाही। अंमलबजावणी API वेगळ्या आहेत, आणि एक चेकबॉक्स डेस्कटॉपवर आणि फोनवर पूर्णपणे वेगळ्या गोष्टी दर्शवू शकतो। आवृत्तीही महत्त्वाची आहे, कारण लॉकडाउन नियंत्रण Android आवृत्त्यांदरम्यान स्क्रीनदरम्यान सरकले आहे, आणि क्लायंट बाजूची अपवाद यादी प्लॅटफॉर्म लॉकडाउनइतकेच नियंत्रण नाही।

तीन क्षण: टनेल चालू, टनेल बंद, पुन्हा जोडणी

तीन क्षणांमध्ये निरुपद्रवी विनंत्या वापरा: टनेल काम करत असताना, तुम्हाला महत्त्वाच्या असलेल्या अपयशादरम्यान, आणि पुन्हा जोडल्यानंतर। एका ब्राउझरच्या निकालाने वगळलेल्या ॲपचे वर्तन सिद्ध होऊ शकत नाही।

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

बहिर्गमन पत्ता कोणता मार्ग घेतला हे दाखवतो, आणि स्पष्ट इंटरफेस चाचणी टनेल हाच एकमेव उपलब्ध निर्गम असताना काय होते ते दाखवते। यापैकी काहीही चालवण्यापूर्वी प्रत्येक ओळीच्या शेजारी अपेक्षित निकाल लिहा, अन्यथा आउटपुटचा अर्थ नंतर लावला जाईल।

वगळलेले ॲप ऑफलाइन गेल्यास, रुंद फायरवॉल परवानगी जोडण्यापूर्वी धोरणाची प्राधान्यक्रम तपासा, कारण ती दुरुस्ती तुम्ही चाचणी करत असलेला फरक नष्ट करते। ते थेट राहिल्यास, तो दस्तऐवजीकृत अपवाद होता आणि अपघाती माघार नव्हता याची खात्री करा। संपूर्ण उपकरणासाठी कठोर आवश्यकता असल्यास, हाताने चाचणी करता येईपर्यंत अपवाद यादी लहान करा।