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 पर /8 मास्क के साथ 10.184.178.50 जैसा पता मिलता है, तो हर 10.x गंतव्य परिभाषा से स्थानीय होता है। 10.4.0.1 के लिए पैकेट तब LAN पर जाते हैं, सुरंग चालू रहती है, और नाम विश्लेषण विफल होता है।

ip addr अतिव्यापन को एक नज़र में उजागर करता है, और ip route get 10.4.0.1 दिखाता है कि पैकेट वास्तव में कहाँ पहुँचाया जाएगा। चूँकि दिखाई देने वाला लक्षण रिज़ॉल्वर की विफलता है, यह मामला अक्सर DNS परिवर्तनों के कई दौर झेल जाता है।

पूल को फिर से क्रमांकित करें या उस एक्सेस नेटवर्क को दायरे से बाहर रखें। कोई भी क्लाइंट-पक्ष सेटिंग अतिव्यापन से उबरती नहीं है।

TCP विकल्प और मार्ग-सुधार के बीच निर्णय

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

परिणाम उपयोगकर्ता के बजाय नेटवर्क के अनुसार दर्ज करें। उसी विफलता की अगली रिपोर्ट तब प्रमाणपत्र-सिद्धांत के बजाय ज्ञात चरण से शुरू होती है। वही रिकॉर्ड स्थायी दूसरे श्रोता को भी न्यायसंगत ठहराता है, अगर कभी ज़रूरत पड़े।