केवल वेब नेटवर्क पर VPN ब्लॉक? परतों पर काम करें

कैंपस या होटल का ऐसा नेटवर्क जहाँ ब्राउज़र चलता है और हर टनल मर जाता है, एक समस्या नहीं, चार परतें हैं। रास्ता सिर्फ़ TCP 443 की अनुमति दे सकता है, प्रमाणित प्रॉक्सी मांग सकता है, हैंडशेक की जाँच कर सकता है, या नीति से दूरस्थ पहुँच पर सीधे रोक लगा सकता है। इन्हें क्रम से निपटाने पर नेटवर्क नियम ठीक करने के लिए नया क्लाइंट खरीदने की ज़रूरत नहीं पड़ती। नीचे दी रनबुक लगभग दस मिनट लेती है और इस लिखित जवाब पर खत्म होती है कि किस परत ने आपको ठुकराया।

साबित करें कि कौन सी परत कनेक्शन ठुकराती है

VPN क्लाइंट से शुरू न करें। उसी होस्ट पर सादा HTTPS अनुरोध से शुरू करें और समय-चरण पढ़ें, क्योंकि जो चरण विफल होता है वह बताता है कि कौन सा उपकरण ज़िम्मेदार है:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

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

अब वह प्रमाणपत्र देखें जो आपको वास्तव में मिलता है। यह जानने का सबसे तेज़ तरीका है कि आप सर्वर से बात कर रहे हैं या ऐसे मध्य बॉक्स से जिसने सत्र को फिर से हस्ताक्षरित किया:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

प्रॉक्सी-सजग क्लाइंट पहला पैकेट बदलता है, नीति नहीं

अगर नेटवर्क प्रमाणित प्रॉक्सी के ज़रिए CONNECT मांगता है, तो VPN क्लाइंट को बताना होगा, वरना वह ऐसे पते पर सॉकेट खोलने की कोशिश करेगा जिसे रूट नहीं कर सकता। प्रॉक्सी को क्लाइंट से अलग जाँचें, ताकि विफलता का एक ही स्पष्टीकरण हो:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

पहला कमांड साबित करता है कि प्रॉक्सी गंतव्य ले जाएगा। दूसरा क्लाइंट से 443 पर TCP इस्तेमाल करने को कहता है, यही एकमात्र परिवहन है जिसे ज़्यादातर केवल-वेब रास्ते आगे बढ़ाते हैं। अगर पहला सफल हो और दूसरा फिर भी विफल रहे, तो प्रॉक्सी बाधा नहीं है।

कुछ क्लाइंट ओवरराइड की जगह ऑपरेटिंग सिस्टम का प्रॉक्सी पढ़ते हैं, और कुछ दोनों में से कोई नहीं पढ़ते। सिस्टम-व्यापी सेटिंग लागू है यह मानने से पहले एप्लिकेशन का अपना दस्तावेज़ देखें। जो क्लाइंट ऐसे रिज़ॉल्वर से एंडपॉइंट हल करता है जिसे प्रॉक्सी सेवा नहीं देता, वह भी यहाँ विफल होगा, इसीलिए DNS बदलाव समाधान जैसा लग सकता है जबकि वह केवल चक्कर है।

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

पोर्ट 443 पहुँच योग्य है, अनुमत नहीं

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

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

UDP आम तौर पर पहला शिकार होता है, और यह अनुमान लगाने के बजाय पुष्टि करने योग्य है। अगर WireGuard या डिफ़ॉल्ट OpenVPN कभी हैंडशेक पूरा नहीं करता जबकि TCP 443 काम करता है, तो नेटवर्क UDP गिरा रहा है, और कोई भी कुंजी पुनर्जनन इसे नहीं बदलेगा:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

कल काम कर रहे साथी के पास खाली हैंडशेक समय-मोहर UDP का जवाब है। दो DNS प्रश्न दूसरे सवाल का जवाब देते हैं: अगर स्थानीय रिज़ॉल्वर और सार्वजनिक रिज़ॉल्वर एंडपॉइंट पते पर सहमत न हों, तो आपको स्टीयर किया जा रहा है और परिवहन का तर्क गलत है।

जाँचें कि मशीन से वास्तव में क्या गया

क्लाइंट लॉग बताते हैं कि क्लाइंट क्या मानता है। कैप्चर बताता है कि नेटवर्क ने क्या देखा, और दोनों का अंतर वहीं है जहाँ इनमें से ज़्यादातर मामले हल होते हैं:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

अगर SYN पैकेट दिखें और SYN-ACK नहीं, तो रोक ऊपर की ओर है और क्लाइंट निर्दोष है। अगर सर्वर का न हो ऐसे पते पर पूरा हैंडशेक दिखे, तो आप प्रॉक्सी या इंटरसेप्टर से बात कर रहे हैं। अगर कुछ भी न दिखे, तो कोई निष्कर्ष निकालने से पहले जाँचें कि सही इंटरफ़ेस पर कैप्चर किया।

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

वापसी, और वह नोट जो रखने लायक है

बदलाव जिस क्रम में किए थे उसके उलटे क्रम में हटाएँ। प्रॉक्सी चर हटाएँ, हाथ से शुरू किया क्लाइंट बंद करें, और जोड़ा कोई भी रूट या रिज़ॉल्वर ओवरराइड हटाएँ:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

हाथ से शुरू किए क्लाइंट को चलता छोड़ना वह तरीका है जिससे लैपटॉप अगली दफ़्तर यात्रा पर टूटे नेटवर्क के साथ रह जाता है। शेल प्रोफ़ाइल में छोड़े गए प्रॉक्सी चर हफ़्तों बाद असंबंधित औज़ार तोड़ते हैं, और उन्हें डिबग करने वाला दोनों घटनाओं को नहीं जोड़ेगा।

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