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ला न्याय देते.