सुरंग घर की लाइन से जुड़ती है और होटल या दफ़्तर के नेटवर्क पर अटक जाती है, और सर्वर को पोर्ट 443 पर ले जाने से कुछ नहीं बदला। यह नतीजा इतना आम है कि इसका एक आकार है: पोर्ट आसान हिस्सा था, और बाकी फ़ैसला उस सबका है जो क्लाइंट और सर्वर के बीच बैठा है। दो सवाल ज़्यादातर मामले तय कर देते हैं, और उनमें से कोई भी सिफ़र के बारे में नहीं है। क्या नेटवर्क उस पते पर TLS हैंडशेक स्वीकार करता है, और क्या सुरंग चालू रहने के दौरान क्लाइंट अपने आवरण तक मार्ग बनाए रखता है?

हैंडशेक संख्या से ज़्यादा बता देता है

TCP 443 पर एक मूल VPN श्रोता पहले पैकेट से ही अपना प्रोटोकॉल बोलता है। ClientHello में एक संस्करण फ़ील्ड, एक यादृच्छिक मान और एक्सटेंशन की सूची होती है, और कुछ सौ बाइट पढ़ने वाला उपकरण कुछ भी डिक्रिप्ट किए बिना अंतर पहचान सकता है। पोर्ट संख्याएँ संतुष्ट करना सस्ता है, और फ़िल्टर वास्तव में प्रोटोकॉल का आकार ही जाँचता है। नियम आमतौर पर प्रति प्रोटोकॉल भी लिखे जाते हैं, इसलिए TLS की जाँच करने वाली नीति UDP के बारे में कुछ नहीं कहती।

मान्य TLS सत्र पर ज़ोर देने वाला पारदर्शी प्रॉक्सी सेटअप के दौरान ही कनेक्शन गिरा देता है, अक्सर TCP हैंडशेक पूरा होने के बाद। यह ब्यौरा बाद में मायने रखता है, क्योंकि इसका मतलब है कि सॉकेट बनने के बाद क्लाइंट लॉग रुक जाता है।

स्ट्रीम को लपेटने से दो विफलता-बिंदु बनते हैं

stunnel जैसा TLS आवरण अपेक्षित आकार लौटा देता है: क्लाइंट स्थानीय श्रोता से जुड़ता है, आवरण सर्वर के साथ 443 पर असली TLS सत्र खोलता है, और सर्वर पर दूसरा आवरण डिक्रिप्ट किए गए बाइट VPN डेमन तक भेजता है। बाहरी सत्र अब किसी भी दूसरे HTTPS कनेक्शन जैसा दिखता है। सर्वर पर VPN डेमन को सिर्फ़ loopback पर सुनना चाहिए, क्योंकि आवरण के बाहर किसी को उस तक पहुँचने की ज़रूरत नहीं है।

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

आवरण तक का मार्ग ही जाल है

सुरंग ऊपर आते ही डिफ़ॉल्ट मार्ग उसी की ओर इशारा करता है, और बाहरी TLS सत्र को ऐसा रास्ता चाहिए जो उस सुरंग में न जाए जिसे वह ढो रहा है। सामान्य VPN क्लाइंट उस पते की रक्षा करता है जिसे वह डायल करता है; आवरण वाला क्लाइंट अपने ही loopback को डायल करता है, इसलिए आवरण का गंतव्य पता उस सुरक्षा के लिए अदृश्य है।

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

सटीक पते आप ही भरें, और मार्ग कनेक्शन के पूरे जीवनकाल तक मौजूद रहना चाहिए, सिर्फ़ शुरुआत में नहीं। एक छोटी आवरण स्क्रिप्ट जो क्लाइंट से पहले मार्ग जोड़ती है और बाद में हटा देती है, याद रखे गए आदेश से ज़्यादा भरोसेमंद है।

Android पर उस अपवाद का समतुल्य प्रति-ऐप सेटिंग है: आवरण ऐप को सुरंग से बाहर रखें ताकि उसका अपना ट्रैफ़िक मोबाइल कनेक्शन से बाहर जाए। बाहर न रखने पर आवरण उसी सुरंग में भेज दिया जाता है जिसे वह बनाना चाहता है, और फिर से जुड़ने का चक्र सर्वर की समस्या जैसा लगता है।

कुछ बदलने से पहले समय-भाव पढ़ें

हर बार उसी अंतराल के बाद मरने वाला सत्र क्रिप्टोग्राफ़िक विफलता नहीं, नीति का हस्ताक्षर है, और लंबी अवधि की प्रवाह सीमाएँ ठीक वही पैटर्न बनाती हैं। हैंडशेक के तुरंत बाद रीसेट होने वाला कनेक्शन ऐसे प्रॉक्सी की ओर इशारा करता है जिसे प्रमाणपत्र श्रृंखला पसंद नहीं आई।

दोनों नेटवर्क से किसी सामान्य HTTPS साइट के प्रमाणपत्र जारीकर्ता की तुलना करें। अगर प्रतिबंधित नेटवर्क पर जारीकर्ता अलग है, तो बीच में कुछ TLS समाप्त कर रहा है, और कोई भी आवरण उस अवरोधन को बिना बदलाव पार नहीं करेगा। वही तुलना आपको बताती है कि अवरोध आपके सर्वर के नाम को लक्ष्य बनाता है या उस पते के हर TLS सत्र को।

देखा गया व्यवहार लिखें: सत्र कितनी देर चला, सॉकेट खुला या नहीं, आवरण ने हैंडशेक लॉग किया या नहीं। इनमें से हर बात अगली परीक्षा को संकरा करती है।

एक बार में एक चर जाँचें

पहले UDP जाँचें, क्योंकि कुछ नेटवर्क उसे पूरी तरह गिरा देते हैं और UDP विफलता 443 के बारे में कुछ नहीं कहती। फिर आवरण के बिना TCP 443 आज़माएँ, फिर 443 पर आवरण। हर क़दम पर क्लाइंट लॉग पढ़ें और व्यवहार बदलते ही रुक जाएँ।

हर प्रयास में एक तत्व बदलें। नया पोर्ट, नया आवरण और नया सिफ़र एक ही दौर में रखें तो आप बता नहीं पाएँगे कि तीन में से कौन मायने रखता था।

संबंधित लेख