OpenVPN चे UDP उत्तर चुकीच्या पत्त्यावरून का येते

OpenVPN क्लायंट एका पत्त्यावर डायल करतो, सर्व्हर दुसऱ्या पत्त्यावरून उत्तर देतो, आणि टनेल कधीच वर येत नाही। सर्व्हर लॉग पॅकेट येत असल्याचे दाखवतो आणि कॅप्चर उत्तर जात असल्याचे दाखवते, त्यामुळे दोष क्लायंटवर मारला जातो। अनेक इंटरफेस असलेल्या होस्टवर, किंवा एकाच इंटरफेसवर अनेक पत्ते असताना, कोणता पत्ता वापरात आहे यावर दोन्ही बाजू सहज सहमत होत नाहीत। उत्तर IP स्तरावर वैध आहे, तरीही अनेक क्लायंट असे डेटाग्राम टाकून देतात ज्याचा स्रोत त्यांनी संपर्क केलेला पत्ता नाही।

स्रोत बदलल्यावर क्लायंट काय पाहतो

विशिष्ट स्थानिक पत्त्याशी बांधलेले नसलेल्या UDP सॉकेटला काही स्थिर स्रोत नसतो, म्हणून कर्नेल पाठवताना एक निवडते। ती निवड क्लायंटच्या पत्त्याकडे होणाऱ्या राऊट शोधातून येते, आणि स्रोत त्या इंटरफेसचा पत्ता बनतो जो शोध निवडतो। एका इंटरफेसच्या मशीनवर निवड अदृश्य असते; व्यवस्थापन पत्ता, सार्वजनिक पत्ता आणि त्याच नेटवर्क कार्डवर दुय्यम पत्ता असलेल्या होस्टवर ती राऊट मेट्रिक आणि धोरणावर अवलंबून असते। धोरणाधारित राऊटिंग तफावत कमी करण्याऐवजी वाढवते, कारण नियम क्लायंट कधीच पोहोचला नसलेला अपस्ट्रीम दुवा निवडू शकतो। एका प्रदात्याकडून शिकलेला डीफॉल्ट राऊट आणि दुसऱ्याकडे निर्देश करणारा स्रोत नियम ते तयार करण्यासाठी पुरतो।

उत्तरे फिल्टर करणारे क्लायंट, आणि अचूक चौकार व स्रोत अपेक्षिणारे कनेक्शन ट्रॅकिंग, उपयुक्त संदेशाशिवाय उत्तर टाकून देतील। मग टनेल काहीच आले नसल्यासारखे वेळ संपते, आणि म्हणूनच हे क्लायंटच्या बाजूची फायरवॉल समस्या असे चुकीने समजले जाते। फक्त सर्व्हरवर घेतलेले कॅप्चर दोष स्पष्ट करण्याऐवजी त्याची पुष्टी करते, कारण उत्तर खरोखर जाते। दुसरे काहीही बदलण्यापूर्वी उत्तराच्या स्रोताची क्लायंटने डायल केलेल्या पत्त्याशी तुलना करा।

multihome पर्याय प्रत्यक्षात काय करतो

हा निर्देश कॉन्फिगरेशन फाइलमध्ये multihome आणि कमांड लाइनवर --multihome असे लिहिला जातो, आणि तो UDP सर्व्हरला क्लायंटचे पॅकेट ज्या पत्त्यावर पोहोचले त्या पत्त्यावरून उत्तर देण्यास भाग पाडतो। कर्नेल स्वीकारताना मूळ गंतव्य पत्ता पूरक डेटा म्हणून देतो, आणि OpenVPN ते मूल्य उत्तराचा स्रोत म्हणून वापरतो। अशा प्रकारे वाइल्डकार्ड पत्त्यावर ऐकणारा सर्व्हर, IPv4 साठी local 0.0.0.0 किंवा त्याचे IPv6 समतुल्य, प्रत्येक क्लायंट स्वतंत्र श्रोत्यापर्यंत पोहोचल्यासारखे वागतो। सार्वजनिक पत्त्यातून आलेल्या क्लायंटना सार्वजनिक पत्त्यावरून उत्तर मिळते, आणि अंतर्गत पत्त्यावरील क्लायंटना त्याच पत्त्यावरून मिळते। पॅकेटच्या मार्गावर दुसरे काहीही हलत नाही: राऊट, फिल्टर नियम आणि टनेल कॉन्फिगरेशन जसे होते तसेच राहतात।

हाच शेवटचा गुणधर्म पर्याय अन्यथा चालणाऱ्या सर्व्हरमध्ये जोडणे सुरक्षित करतो, आणि एकाच पत्त्याला परवानगी देणारे फिल्टर तो दुरुस्त करू शकत नाही याचे कारणही तेच। पॅकेटला अजूनही ज्या मार्गाने जाते त्या मार्गावर स्वीकारले पाहिजे, म्हणून स्रोत दुरुस्ती उत्तराचे उगमस्थान बदलते आणि त्यापेक्षा जास्त काही नाही। हे फक्त UDP साठी आहे: TCP श्रोत्याला हीच समस्या त्याच स्वरूपात नसते, कारण कनेक्शन उत्तराच्या स्रोत पत्त्याने नाही तर चौकाराने ओळखले जाते।

स्थिर स्थानिक पत्ता कधी चुकीचा डीफॉल्ट असतो

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

OpenVPN संदर्भ पर्यायाला UDP सर्व्हरपुरता मर्यादित ठेवतो, पॅकेट मार्गावरील अतिरिक्त प्रक्रिया नोंदवतो, आणि कोणते प्लॅटफॉर्म त्याला आधार देतात ते नोंदवतो। त्यावर आधारित नियोजन करण्यापूर्वी स्थापित आवृत्तीवर ते पुष्टी करा। जिथे आधार नाही, तिथे विशिष्ट पत्ता बांधणे किंवा परतीचा राऊट दुरुस्त करणे हा पर्याय आहे, आणि दोन्ही पहिल्या दृष्टीक्षेपात दिसण्यापेक्षा अरुंद बदल आहेत। वाइल्डकार्डवर ऐकण्याचे उत्तरांपलीकडेही परिणाम असतात: सर्व पत्त्यांवरील सर्व्हर होस्ट जोडलेल्या प्रत्येक नेटवर्कवरून पोहोचण्यायोग्य असतो, आणि ते कुणाच्या मनातील उघडकी नसेल।

उत्तराचा स्रोत बाहेरून सिद्ध करा

सर्व्हरच्या बाहेरून चाचणी करा, आणि काहीही कॅप्चर करण्यापूर्वी क्लायंटने वापरलेला अचूक पत्ता व वाहतूक नोंदवा। खालील तीन तपासण्या तीन वेगवेगळ्या प्रश्नांची उत्तरे देतात, आणि क्रम महत्त्वाचा आहे।

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

कॅप्चर उत्तरावरील स्रोत पत्ता दाखवते, आणि संपूर्ण लेख या वस्तुस्थितीवर उभा आहे। सॉकेट यादी सर्व्हरने प्रत्यक्षात काय बांधले ते दाखवते, कारण वाइल्डकार्ड श्रोता आणि विशिष्ट श्रोता कॉन्फिगरेशन फाइलमध्ये सारखे दिसतात आणि नेटवर्कवर वेगळे वागतात। राऊट शोध त्या प्रवाहासाठी कर्नेल निवडणारा स्रोत दाखवतो, आणि ते काहीही बदलण्यापूर्वी कॅप्चर स्पष्ट करते। तिन्ही IPv4 आणि IPv6 साठी स्वतंत्रपणे पुन्हा करा, कारण ते स्वतंत्र श्रोते आणि स्वतंत्र शोध आहेत, आणि एका कुटुंबासाठीची वाइल्डकार्ड नोंद दुसऱ्याबद्दल काहीही सांगत नाही।

राऊटिंग, शोध आणि फिल्टरिंग स्वतंत्र राहतात

उत्तराचा स्रोत जपणे बाहेर जाणारा राऊट बसवत नाही, गतिशील DNS अद्ययावत करत नाही, आणि एका पत्ता कुटुंबाला दुसरे स्वीकारायला भाग पाडत नाही। अनेक अपस्ट्रीम दुवे असलेल्या सर्व्हरवर प्रत्येक स्रोतासाठी परतीचा मार्ग जाणीवपूर्वक ठरवावा लागतो, अन्यथा उत्तरे क्लायंटच्या फिल्टरने कधीच परवानगी न दिलेल्या इंटरफेसवरून बाहेर पडतात। त्याचप्रमाणे, उपसर्ग बदलल्यानंतर नवीन पत्ता क्लायंटपर्यंत पोहोचला पाहिजे शोध आणि समर्थित पुनर्जोडणी प्रवाहातून, जुन्या नोंदीतून नाही।

सर्व्हर ओळख तपासण्या आणि प्रमाणपत्र पडताळणी जशा आहेत तशाच ठेवा, कारण बदललेला पत्ता न तपासलेला सहकारी स्वीकारण्याचे समर्थन करत नाही। उत्तर आता इच्छित स्रोतावरून जात असेल आणि टनेल तरीही अयशस्वी होत असेल, तर स्रोताची समस्या सुटली असे मानून पुढे जा। पुढे दिसणारी त्रुटी राऊटिंग, फिल्टरिंग किंवा प्रमाणीकरणाची असते, आणि श्रोता पुन्हा बदलल्याने तिथवर पोहोचणार नाही। क्लायंटने डायल केलेल्या पत्त्याच्या शेजारी तिकिटात उत्तराचा स्रोत लिहा, जेणेकरून पुढील व्यक्ती तीच वस्तुस्थिती एका आदेशाने तपासू शकेल।