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