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