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

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