वेब मात्र नेटवर्कमा 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 सामान्यतया पहिलो बलि हो, र अनुमान गर्नुको सट्टा यसलाई पुष्टि गर्न लायक छ। TCP 443 चलिरहँदा WireGuard वा पूर्वनिर्धारित OpenVPN ले कहिल्यै ह्यान्डशेक पूरा गर्दैन भने नेटवर्कले 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

हातले सुरु गरेको क्लाइन्ट चलिरहन दिनु भनेको अर्को अफिस भ्रमणमा ल्यापटप बिग्रिएको नेटवर्कसँग रहनु हो। शेल प्रोफाइलमा छोडिएका प्रोक्सी चलले हप्तापछि असम्बन्धित उपकरण बिगार्छ, र तिनलाई डिबग गर्ने व्यक्तिले दुई घटना जोड्नेछैन।

त्यसपछि चार लाइन लेख्नुहोस्: नेटवर्क, समयछाप, असफल चरण र देखेको जारीकर्ता। एउटा क्याम्पसमा चल्ने र अर्कोमा असफल हुने बाटो सामान्य हो, र अर्को व्यक्तिले फरक प्रोक्सी, रिजोल्भर वा फिल्टर थियो भन्ने जान्नु आवश्यक छ। जवाफ नेटवर्कले दूरस्थ पहुँच निषेध गर्छ भन्ने भए, त्यहीँ रोक्नुहोस् र प्रशासकसँग समर्थित बाटो माग्नुहोस्, नपढेको नीतिमा घुम्ती बाटो नलैजानुहोस्।