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 अपडेट नहीं करता, और एक पता परिवार को दूसरे को स्वीकार करने पर मजबूर नहीं करता। कई अपस्ट्रीम लिंक वाले सर्वर पर हर स्रोत के लिए वापसी रास्ते पर जानबूझकर सहमति बनानी होती है, वरना उत्तर ऐसे इंटरफ़ेस से निकलते हैं जिसे क्लाइंट के फ़िल्टर ने कभी अनुमति नहीं दी थी। इसी तरह, उपसर्ग बदलने के बाद नया पता क्लाइंट तक पहुँचना चाहिए खोज और समर्थित पुनःकनेक्शन प्रवाह से, पुराने रिकॉर्ड से नहीं।

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