OpenVPN घरमा चल्छ तर एउटा नेटवर्कमा चल्दैन: UDP कि TCP?

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

कुन चरण असफल भयो भन्नेले कुन तुलना महत्त्वपूर्ण छ भन्ने बताउँछ

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

पछि होइन, पुनः प्रयास गर्दा क्याप्चर गर्नुहोस्। क्लाइन्टमा tcpdump -ni any udp port 1194 ले कुनै प्रतिक्रिया फर्किन्छ कि भनेर देखाउँछ। तपाईंले नियन्त्रण गर्ने सर्भरको WAN इन्टरफेसमा दोहोर्याउनुहोस्, जसले ती प्याकेट टाढाको छेउसम्म पुग्छन् कि भनेर खुलासा गर्छ।

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

UDP फिल्टरिङ र बन्द पोर्ट

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

पोर्ट 443 मा TCP प्रोफाइल सामान्य उपाय हो, किनकि यो सामान्य HTTPS प्रवाहसँग मिल्दोजुल्दो छ र अधिकांश क्याप्टिभ पोर्टल र बाहिरी फिल्टर पार गर्छ। दुई सर्त पूरा हुनुपर्छ। सर्भरले proto tcp-server सँग सुन्नुपर्छ र क्लाइन्टले proto tcp-client सँग मिल्नुपर्छ, र अपरेटरले त्यो वैकल्पिक इन्डपोइन्ट प्रकाशित गर्नुपर्छ। काम गर्ने UDP प्रोफाइललाई TCP 443 भनेर पुनर्लेखन गर्दा अर्को छेउमा कोही नसुन्दा केही हुँदैन।

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

पुराना प्रोटोकलहरू यो अक्षमा कमजोर देखिन्छन्। PPTP लाई TCP 1723 प्लस GRE चाहिन्छ, र GRE पोर्ट होइन, IP प्रोटोकल 47 हो, त्यसैले सामान्य पोर्ट फर्वार्डले यसलाई व्यक्त गर्न सक्दैन।

जब स्विचले प्याकेट छोड्छ

व्यवस्थापित स्विचले जानाजान टनेल छोड्न सक्छ। केही HPE र Aruba मोडेलहरूले आफ्नो उन्नत सुरक्षा खण्डमा UDP फ्लड संरक्षण नियन्त्रण दिन्छन्, कहिलेकाहीँ Prevent UDP Blat Attack लेबल गरिएको। त्यो नियन्त्रण सक्रिय भएपछि स्विचपछाडिको सर्भरले केही पनि जवाफ दिँदैन र हरेक क्लाइन्ट उही तरिकाले समय सकिन्छ। यसलाई हटाएर चलिरहेको कन्फिगरेसन बचत गर्नु नै पूरै मर्मत हो, तर स्विच साँच्चै मार्गमा छ भनी प्रमाणित गरेपछि मात्र।

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

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

DNS असफलता जस्तो देखिने ठेगाना ओभरल्याप

10.0.0.0/8 भित्र नम्बर गरिएको पहुँच नेटवर्क टनेल पूलसँग ओभरल्याप हुन सक्छ, र रिजोल्भर सामान्यतया त्यही पूलभित्र बस्छ। ल्यापटपले Wi-Fi मा 10.184.178.50 जस्तो ठेगाना /8 मास्कसँग पाउँदा, हरेक 10.x गन्तव्य परिभाषाअनुसार स्थानीय हुन्छ। 10.4.0.1 का लागि प्याकेट त्यसपछि LAN मा जान्छ, टनेल चालु रहन्छ, र नाम रिजोल्युसन असफल हुन्छ।

ip addr ले ओभरल्याप एकै नजरमा देखाउँछ, र ip route get 10.4.0.1 ले प्याकेट वास्तवमा कहाँ पुर्‍याइने हो देखाउँछ। देखिने लक्षण रिजोल्भर असफलता भएकोले, यो प्रायः धेरै चरणको DNS परिवर्तनपछि पनि बाँच्छ।

पूल पुनः नम्बर गर्नुहोस् वा त्यो पहुँच नेटवर्कलाई दायराबाहिर राख्नुहोस्। कुनै पनि क्लाइन्ट-साइड सेटिङले ओभरल्यापबाट सुधार गर्दैन।

TCP ब्याकअप र मार्ग सुधारबीच छनोट

तपाईंले मार्ग नियन्त्रण गर्नुहुन्न र प्रयोगकर्ताले आजै काम गर्नुपर्छ भने TCP ब्याकअप छान्नुहोस्, र यसको लागत स्वीकार गर्नुहोस्: TCP भित्रको TCP हानि भएका लिङ्कमा नराम्रो व्यवहार गर्छ, र ब्याकअपलाई तपाईंले चलाउने listener चाहिन्छ। ब्लक तपाईंको आफ्नै पूर्वाधारमा छ भने मार्ग सुधार छान्नुहोस्, किनकि फायरवाल नियम दोस्रो listenerभन्दा सस्तो हुन्छ। जसरी भए पनि तहहरू क्रममा पार गर्नुहोस्: लिङ्क, बाह्य यातायात, वार्ता, आन्तरिक राउटिङ. त्यो नेटवर्कमा असफल भएको चरण मात्र महत्त्वपूर्ण तथ्य हो।

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