एन्क्रिप्शन न तोडता नेटवर्क तुमचा VPN ब्लॉक करू शकते का?
एन्क्रिप्शन सामग्रीचे रक्षण करते, पोहोचवण्याचे नाही. ब्लॉकलिस्ट, परवानगी-यादी आणि पूर्ण बंदी यांची तुलना करा, नंतर एका निरीक्षणातून खरोखर काय सिद्ध होऊ शकते ते विचारा.
कोणत्याही ऑपरेटरला टनेल थांबवण्यासाठी सत्र-किल्लीची गरज नाही: मार्गावरील पॅकेट टाकून द्या आणि ती अयशस्वी होते, तर क्रिप्टोग्राफी तिच्या रचनेने वचन दिल्याप्रमाणेच मजबूत राहते. एन्क्रिप्शन संभाषण जे वाहते त्याचे रक्षण करते, कोणत्याही नेटवर्कची ते वाहण्याची तयारी नाही. या दोन गुणधर्मांचे विभाजन केल्यास ब्लॉक न करण्याबद्दलचा वाद कोणती धोरणे लागू आहेत आणि ती किती दूर पोहोचतात या प्रश्नात बदलतो. खालील तुलना उपलब्धता आणि गोपनीयता वेगळ्या ठेवते, कारण VPN ब्लॉकिंगबद्दलची बहुतेक ठाम विधाने त्यांना गपचूप एकत्र करतात.
पोहोचण्याची क्षमता मार्गाचा निर्णय आहे
प्रत्येक वहन पॅकेट पुढे पाठवणाऱ्या मार्गावर अवलंबून असते, आणि येथील प्रत्येक धोरणाचा प्रश्न त्या पाठवण्याच्या निर्णयावर येतो. पॅकेट टाकून देणारा नियम गोपनीयतेला हात न लावता उपलब्धता बदलतो, आणि अशाच प्रकारे एखादी टनेल निर्दोष एन्क्रिप्ट असूनही त्याच क्षणी पूर्णपणे निरुपयोगी असू शकते. त्या निकालातील काहीही सिफर तोडण्याची किंवा किल्ली परत मिळवण्याची मागणी करत नाही. फक्त मार्गावरील नियंत्रणाची मागणी करते.
गोंधळ सहसा दोन गुणधर्म एकच शब्द वाटून घेतल्याने सुरू होतो. मजबूत क्रिप्टोग्राफी प्रवाह कोण वाचू शकतो हे सांगते; मधले उपकरण तो जाऊ देईल का हे काहीही सांगत नाही. म्हणून VPN ब्लॉक करता येत नाही या विधानाखाली दुसरे विधान लागते, म्हणजे मार्गावर कोणीही पॅकेट टाकून देण्यास तयार नाही.
अंमलबजावणीच्या शैली आणि प्रत्येकाची किंमत
तीन शैली बहुतेक वास्तविक धोरणे व्यापतात, आणि ते काय माहीत असावे, चालवण्यास किती खर्च येतो आणि दुसरे कोण त्रास सहन करते यात वेगळे आहेत. त्यातील प्रत्येक काहीही डिक्रिप्ट न करता टनेल नाकारू शकते. फरक महत्त्वाचे आहेत कारण ब्लॉकिंग हाच शब्द तिन्हींसाठी वापरला जातो.
| Style | Default | What it must know | Who else is affected |
|---|---|---|---|
| Blocklist | Allow, minus listed destinations | Addresses and ports of known endpoints | Unrelated tenants on a listed address |
| Allowlist | Deny, plus approved destinations | A maintained definition of permitted traffic | Anything outside the approved set |
| Shutdown | Deny broadly for a period | Nothing about the protocol | Ordinary services along the same path |
ती तक्ता खर्चाचा नकाशा आहे, क्रमवारी नाही. ब्लॉकलिस्ट सुरू करणे स्वस्त आणि अचूक ठेवणे महाग; परवानगी-यादी शोधाची अदलाबदल परवानगी असलेल्या संचाच्या देखभालीशी करते, आणि पूर्ण बंदीला कोणतेही वर्गीकरण लागत नाही. त्यांना वेगळे करणारी गोष्ट तांत्रिक सूक्ष्मता नाही, तर प्रत्येक सततचा श्रम कुठे ठेवते ही आहे. कागदावर सोपे दिसणाऱ्या धोरणात सहसा दुसरीकडे लपलेली देखभालीची ओळ असते.
ब्लॉकलिस्ट या गोष्टीपुरती मर्यादित आहे की पत्ता सेवेला किती चांगले नाव देतो
ब्लॉकलिस्ट आधीच ओळखलेल्या गंतव्यांना नाकारते आणि उर्वरित साधारणपणे उपलब्ध ठेवते. ती अमलात आणण्यासाठी स्पष्ट मजकूर नव्हे तर पत्ते आणि पोर्ट लागतात, आणि त्यामुळे सुरुवातीला ती स्वस्त पडते. खर्च नंतर येतो, कारण एकेकाळी एका पुरवठादाराची ओळख करून देणारी श्रेणी नंतर डझनभर असंबंधित भाडेकरूंना आसरा देऊ शकते. प्रत्येक पत्ता बदलल्यास यादीत संपादन करावे लागते, आणि प्रत्येक जुनी नोंद निर्दोष रहदारी आपल्यासोबत घेऊन जाते.
या प्रतिकृतिमध्ये अचूकता गंतव्य सेवेची किती चांगली ओळख करते यावर मर्यादित आहे, आणि गर्दीचे सामायिक टोक खराब ओळखकर्ता आहे. ही रचनात्मक मर्यादा आहे, अंमलबजावणीतील दोष नाही, म्हणून चांगली साधने ती दूर करत नाहीत. ब्लॉकलिस्ट का वाढतात हेही यामुळे स्पष्ट होते: प्रत्येक नवीन टोक लहान भर म्हणून दिसते, आणि दुष्परिणाम यादीसोबत वाढतो.
परवानगी-यादी देखभालीचा भार हलवते
परवानगी-यादी पूर्वनिर्धारित उलटते, जेणेकरून आधीच निवडलेली गंतव्ये किंवा रहदारीचे प्रकारच पुढे जाऊ शकतात. प्रत्येक प्रतिबंधित टोकाची यादी करावी लागत नाही, जे प्रतिबंधित संच मोठा असताना किंवा वेगाने बदलत असताना उपयोगी पडते. त्याऐवजी तिला परवानगी असलेल्याची देखभाल केलेली व्याख्या आणि त्या व्याख्येशी जुळणारी अंमलबजावणी लागते.
अशा व्याख्येतील नेहमीचा कमकुवत मुद्दा म्हणजे पोर्ट क्रमांक. पोर्टला परवानगी देणे म्हणजे तो वापरू शकणाऱ्या प्रत्येक अनुप्रयोगाची ओळख करणे नव्हे, त्यामुळे पोर्ट-आधारित परवानगी-यादी अनेकदा लेखकाच्या हेतूपेक्षा जास्त स्वीकारते. प्रोटोकॉलच्या बोटांच्या ठशांनाही वेगळ्या कोनातून तीच समस्या आहे, कारण ते रहदारीचा आकार ओळखतात, हेतू नाही. म्हणून परवानगी-यादी आपोआप ब्लॉकलिस्टपेक्षा अचूक नसते; ती वेगळ्या गोष्टीबद्दल अचूक असते.
एक निरीक्षण कशाला आधार देऊ शकते आणि कशाला नाही
ब्लॉकिंगबद्दलचे कोणतेही विधान हातात चार प्रश्न घेऊन वाचले पाहिजे: कोणती प्रवेश नेटवर्क, कोणती गंतव्ये, कोणते प्रोटोकॉल आणि कोणती निरीक्षण कालावधी. आज एका मोबाइल नेटवर्कवर दिसलेली अयशस्वीता उद्या दुसऱ्या नेटवर्कवरून त्याच टोकाबद्दल काहीही सांगत नाही. एकदा चाललेली टनेलही टिकाऊ उपलब्धतेबद्दल काहीही सांगत नाही.
अयशस्वीतेच्या कारणाबद्दल सिद्धांत मांडण्यापूर्वी तिचा आकार पाहता येतो. शांत अडकणे, तत्काळ नकार आणि जोडल्यानंतरचे पुनर्संचयन वेगवेगळ्या अंमलबजावणी शैलींकडे निर्देश करतात, आणि दोन आदेश त्यांना वेगळे करतात:
curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.comवेळेच्या मर्यादेत संपणारे अडकणे शांत टाकून देण्याकडे, जलद नकार मार्गावरील नाकारणाऱ्या उपकरणाकडे, आणि जोडल्यानंतरचे पुनर्संचयन गहाळ मार्गाकडे नव्हे तर स्थितीय हस्तक्षेपाकडे निर्देश करते. सेक्सॉरशिप तंत्रांवरील RFC 9505 सर्वेक्षण त्या आकारांमागील नियंत्रण-बिंदू आणि हस्तक्षेपाच्या प्रतिकृतींचे वर्णन करते. पण त्यांपैकी कोणतेही धोरण किती व्यापकपणे लागू होते हे सांगत नाही. टिकाऊपणा पोहोचण्यापेक्षा मजबूत विधान आहे: टोके, सॉफ्टवेअर, धोरणे आणि परवानगी असलेल्या सेवा सर्व बदलतात, म्हणून अनिश्चित काळाच्या परिणामकारकतेसाठी एका क्षणी दिसलेल्या पत्त्यांची यादी नव्हे तर अंमलबजावणी सुरू राहील अशा गृहीतकांची गरज असते.