OpenVPN अझै 443 मा अवरुद्ध? नेटवर्कले के जाँच्छ हेर्नुहोस्

सुरुङ घरको लाइनबाट जोडिन्छ र होटेल वा अफिसको नेटवर्कमा अड्किन्छ, र सर्भरलाई पोर्ट 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 मा आवरण। हरेक चरणमा क्लाइन्ट लग पढ्नुहोस् र व्यवहार बदल्नेबित्तिकै रोक्नुहोस्।

हरेक प्रयासमा एउटा तत्व बदल्नुहोस्। नयाँ पोर्ट, नयाँ आवरण र नयाँ सिफर एउटै दौडमा राख्दा तीनमध्ये कुन महत्त्वपूर्ण थियो भन्न सक्नुहुन्न।