होटलको वाइफाइमा OpenVPN जोडिँदैन? TCP 443 प्रयास गर्नुहोस्

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

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

क्लाइन्टबाट सुरु गर्नुहोस्: स्थिति रेखा पढ्नुहोस्

स्थिति रेखाले कुन चरण असफल भयो भन्छ। जोडिँदै मा अड्किएको क्लाइन्ट अझै होस्ट समाधान गर्दै वा बाहिरी सकेट खोल्दै छ; सर्भरको प्रतीक्षा सम्म पुगेको क्लाइन्टसँग बाटो छ तर जवाफ छैन; प्रमाणीकरण गरेर त्यसपछि झर्नेलाई पूरै अर्को समस्या छ। क्लाइन्ट लग र प्रोफाइलका आफ्नै remote र proto क्षेत्रहरूले क्लाइन्ट के गर्न खोज्दै छ भन्ने देखाउँछन्, र कमाण्ड-लाइन क्लाइन्टमा --verb 4 ले त्यही विवरण छाप्छ। त्यसलाई तपाईंको अगाडिको नेटवर्कसँग तुलना गर्नु नै 'भीपीएन ब्लक छ' भन्नेलाई ठोस दाबीमा बदल्छ।

त्यसपछि तपाईंसँग पहिले नै भएका औजारहरूले नेटवर्क जाँच्नुहोस्। nc -vzu 203.0.113.10 1194 ले UDP डेटाग्राम पठाउँछ, curl -v telnet://203.0.113.10:443 ले TCP हात मिलाउने क्रम पूरा हुन्छ कि भन्ने जनाउँछ, र HTTPS पृष्ठ लोड गर्ने ब्राउजरले बाहिर जाने 443 त्यो एक होस्टसम्म पुग्छ भन्ने मात्र प्रमाणित गर्छ। साना जाँचहरूले भीपीएन क्लाइन्टले जवाफ दिन नसक्ने कुराको जवाफ दिन्छ: कुन पोर्ट र कुन प्रोटोकल यो नेटवर्कबाट बाहिर जान्छ।

तीन नेटवर्क व्यवहार क्लाइन्टबाट उस्तै देखिन्छन् र फरक जवाफ चाहिन्छ। बाहिर जाने 443 खुला हुन सक्छ, मात्र प्रोक्सीलाई अनुमति हुन सक्छ, वा 443 पारदर्शी रूपमा त्यस्तो जाँच बाकसमा पठाइन सक्छ जसले त्यसले के बोकेको छ पढ्न सक्दैन। पहिलो तलको प्रोफाइल परिवर्तनले सुधार्छ, दोस्रो प्रोक्सी सेटिङले, र तेस्रोले हात मिलाउने क्रम पूरा गरेर निरीक्षकलाई प्रवाह मन नपर्दा रोकिन सक्छ। तपाईंको अगाडि तीनमध्ये कुन छ भन्ने थाहा पाउनु दस मिनेटको परिवर्तन र आधा दिन क्लाइन्ट पुनःस्थापना गर्ने बीचको फरक हो।

लिसनर र प्रोफाइल सँगै सार्नुहोस्

सर्भरतर्फ लिसनरलाई नेटवर्कले अनुमति दिने कुरामा राख्नुहोस्: सर्भर कन्फिगरेसनमा port 443 र proto tcp, त्यसपछि सेवा पुनः सुरु गरेर ss -lntp ले सकेट पुष्टि गर्नुहोस्। क्लाइन्टतर्फ प्रोफाइलले सहमत हुनुपर्छ, किनभने ट्रान्सपोर्ट र पोर्ट टनेल बाहिर छन्: .ovpn मा proto tcp र port 443, वा एपको सेटिङ स्क्रिनमा सम्बन्धित क्षेत्रहरू। अझै UDP 1194 तर्फ लक्षित प्रोफाइल ठ्याक्कै पहिले जस्तै असफल हुन्छ, र पहिले नै सुधारिएको फायरवाललाई दोष दिन मन लाग्छ। यदि त्यही होस्टले 443 मा HTTPS पनि जवाफ दिन्छ भने दुई लिसनरले त्यो ठेगाना र प्रोटोकल साझा गर्न सक्दैनन्; भीपीएनलाई दोस्रो ठेगाना दिनुहोस् वा अगाडि डिमल्टिप्लेक्सर राख्नुहोस्।

दुवै छेउमा tcpdump -ni any port 443 ले पहिलो जडान हेर्नुहोस्। क्लाइन्टबाट निस्केर कहिल्यै नपुग्ने प्याकेट भनेको नेटवर्कले जे भए पनि फिल्टर गर्दै छ, वा प्रोफाइलको ठेगाना तपाईंले ठानेको होइन। जवाफ बिना पुग्ने प्याकेटले तपाईंलाई सर्भर लगमा फर्काउँछ, जहाँ प्रोटोकलको अमेल तुरुन्तै फालिएको प्याकेटको रूपमा देखिन्छ।

जब नेटवर्कबाट मात्र प्रोक्सी बाहिर जान्छ

केही अतिथि नेटवर्कले HTTP प्रोक्सीबाहेक केही दिँदैनन्, जो बन्द पोर्टभन्दा फरक बाधा हो र OpenVPN भन्दा धेरैलाई बाहिर राख्छ। मात्र PPTP, L2TP/IPsec वा नाङ्गो IPsec बोल्ने क्लाइन्टसँग त्यसबाट निस्कने बाटो छैन, किनभने ती डिजाइनले आफ्नो बाहिरी प्रोटोकल सिधै सर्भरमा पुग्ने अपेक्षा गर्छन्। OpenVPN ले सक्छ, क्लाइन्ट प्रोफाइलमा http-proxy proxy.example.net 8080 भएमा, प्रोक्सीले तपाईंको पोर्टसम्म CONNECT विधिलाई अनुमति दिएमा। SOCKS प्रोक्सी अझ सजिलो छ, किनभने यसले भित्र के छ भन्ने वास्ता नगरी प्रवाह अगाडि पठाउँछ।

क्लाइन्टमा प्रोक्सी समर्थन नभएको ठाउँमा 443 माथिको SSH टनेल सामान्यतया बाँकी रहन्छ। यसले दोस्रो तह थप्छ, र नेटवर्कको सञ्चालकले यसबारे राय राख्न सक्छ, त्यसैले यसलाई वास्तुकला नभई एक यात्राको पुलका रूपमा लिनुहोस्।

राख्नुअघि वैकल्पिक बाटोको मूल्य आँक्नुहोस्

TCP भित्रको TCP को ज्ञात मूल्य हुन्छ। जब बाहिरी जडान TCP हुन्छ र पेलोड पनि TCP, तब हराएको खण्डले दुवै तहमा पुनःप्रेषण गराउँछ, र भित्री जडानले देख्न नसक्ने हानिबाट पछाडि हट्छ। ब्राउजिङले त्यो सहन्छ; अन्तरक्रियात्मक सत्र र कलहरूले त्यो महसुस गर्छन्। TCP 443 लिसनरलाई त्यसको माग गर्ने नेटवर्कका लागि वैकल्पिक बाटोका रूपमा राख्नुहोस्, र अझै त्यसलाई जान दिने सबैका लागि UDP लाई पूर्वनिर्धारित रहन दिनुहोस्।

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