LAN होस्ट OpenVPN क्लाइंट के पते के लिए ARP क्यों भेजता है

LAN होस्ट और VPN क्लाइंट के बीच पहुँच की समस्याएँ अक्सर पते की योजना पर ही लौट आती हैं। उस होस्ट को 10.0.100.0/22 पर एक इंटरफ़ेस दें और वह 10.0.100.0 से 10.0.103.255 तक हर पते को सीधे जुड़ा मानेगा, जिसमें 10.0.101.0/24 पर चुपचाप रखा गया क्लाइंट पूल भी शामिल है। उत्तर कभी किसी राउटर के पास नहीं जाता, क्योंकि होस्ट के दृष्टिकोण से कोई राउटर शामिल नहीं है। पैकेट किसी पड़ोसी को संबोधित है और तार पर माँगा जाता है।

यह तंत्र रिपोर्टों के पूरे परिवार के पीछे है: टनल चालू है, सर्वर के पास रूट है, और LAN होस्ट फिर भी क्लाइंट तक नहीं पहुँच पाता।

वह /22 जो /24 को निगल जाता है

प्रीफ़िक्स को रेंज के रूप में पढ़ें, स्ट्रिंग के रूप में नहीं। एक /22 में 1024 पते होते हैं, और 10.0.100.0/22 10.0.100.0 से 10.0.103.255 तक फैला है, इसलिए 10.0.101.0/24 पर पूल पूरी तरह इसके भीतर है। यह गलती समीक्षा से बच जाती है क्योंकि पूल के पहले ऑक्टेट LAN के पहले ऑक्टेट से अलग दिखते हैं, और सिर्फ़ तीसरा ऑक्टेट इस समाहित होने को उजागर करता है। दोनों रेंजों को अंकों में लिखें, इससे पहले कि आप उन्हें अलग घोषित करें।

यही समाहित होना उलटी दिशा में भी दिख सकता है। कोई पूल जो खाली दिखता है क्योंकि अभी कोई इसका उपयोग नहीं करता, फिर भी किसी साइट राउटर द्वारा घोषित प्रीफ़िक्स के भीतर आ सकता है, और पते की योजना ही एकमात्र दस्तावेज़ है जो यह दिखाता है।

सीधा कनेक्शन का अर्थ ARP है, राउटिंग नहीं

/22 इंटरफ़ेस वाला होस्ट जब 10.0.101.25 पर भेजता है, तो कर्नेल गंतव्य की तुलना इंटरफ़ेस के प्रीफ़िक्स से करता है और मेल पाता है। पैकेट रूट किए गए पैकेट के बजाय पड़ोसी की खोज बन जाता है, और ईथरनेट पर पड़ोसी की खोज उस पते के लिए ARP अनुरोध है। अगर पता किसी रूटेड गेटवे के पीछे के VPN क्लाइंट का है, तो LAN पर कोई होस्ट उसका स्वामी नहीं है, इसलिए अनुरोध अनुत्तरित रह जाता है और पैकेट गिरा दिए जाते हैं। टनल दोषी नहीं है, और क्लाइंट ट्रैफ़िक कभी नहीं देखता।

इसलिए विफलता असममित और कभी-कभी रुक-रुककर दिखती है। VPN होस्ट अक्सर LAN तक पहुँच जाता है क्योंकि उसके अपने रूट सही दिशा में इशारा करते हैं, जबकि LAN होस्ट उत्तर नहीं दे सकता, और पुरानी ARP प्रविष्टि कैश करने वाली कोई भी चीज़ लक्षण को टिमटिमाती रहती है।

TUN, TAP और हर एक क्या ले जाता है

TUN डिवाइस IP पैकेट ले जाता है, और TAP डिवाइस ईथरनेट फ़्रेम ले जाता है। रूटेड TUN लिंक को IP पहुँच देने के लिए ARP ले जाने की ज़रूरत नहीं है, और ठीक इसीलिए ऊपर वाला अनुत्तरित अनुरोध अपेक्षित है, खराब नहीं। TAP जानबूझकर बनाए गए ब्रिज के साथ प्रसारण डोमेन बढ़ा सकता है और ARP को काम करा सकता है, लेकिन यह बदल देता है कि क्लाइंट क्या देख सकता है, ऐसे एंडपॉइंट माँगता है जो वही फ़्रेमिंग समर्थित करें, और यह नेटवर्क मॉडल का पुनर्डिज़ाइन है, अतिव्यापी प्रीफ़िक्स की मरम्मत नहीं। पते की योजना की गलती का इलाज करने के लिए रूटेड परिनियोजन को TAP पर ले जाना छोटी समस्या को बड़ी से बदल देता है।

निष्कर्ष निकालने से पहले दर्ज करें कि ARP अनुरोध कहाँ दिखा और किस सिस्टम ने भेजा। प्रेषक आपको बताता है कि वह गंतव्य के बारे में क्या सोचता है, यह नहीं कि टनल क्या करता है।

ऐसा पूल डिज़ाइन करें जो अतिव्यापी न हो सके

हर जुड़े प्रीफ़िक्स और हर घोषित साइट प्रीफ़िक्स के बाहर पूल चुनें, फिर वे रूट जोड़ें जो उसे दोनों दिशाओं में पहुँचने योग्य बनाते हैं। योजना के अप्रयुक्त हिस्से में 10.8.0.0/24 जैसी रेंज पर विचार करना आसान है, और जिस LAN को उस तक पहुँचना है उसे VPN सर्वर की ओर इशारा करता स्टैटिक रूट मिलता है। आवंटन, घोषित रूट, अनुमत स्रोत पते और फ़ायरवॉल नियम एक साथ बदलें, क्योंकि वे चार सेटिंग नहीं बल्कि एक डिज़ाइन बताते हैं।

सर्वर पर Source NAT पूल को LAN से रूट करने योग्य पते के पीछे छिपा सकता है, और यह वैध माइग्रेशन उपकरण है। यह स्रोत को भी फिर से लिखता है, इसलिए LAN कनेक्शनों को अलग-अलग क्लाइंट्स से जोड़ने और प्रति-क्लाइंट नियम लागू करने की क्षमता खो देता है।

स्वीकृति के लिए असली क्लाइंट का वास्तव में आवंटित पता और LAN होस्ट से एक असली एप्लिकेशन अनुरोध उपयोग करें, फिर पुष्टि करें कि उत्तर तार की बजाय नियोजित गेटवे का अनुसरण करता है।