IPv6 शाखा उपसर्ग: सर्वर पर iroute-ipv6 या route-ipv6?

लगभग एक ही नाम वाली दो निर्देशिकाएँ हर काम करने वाले उदाहरण में आती हैं, और एक को दूसरे के बिना कॉपी करना ऐसा टनल बनाता है जो सही दिखता है और शाखा उपसर्ग को चुपचाप गिरा देता है। ये एक ही सीमा के दो अलग किनारों पर अलग काम करती हैं: एक सर्वर के कर्नेल को सिखाती है कि उपसर्ग कहाँ रहता है, और दूसरी OpenVPN को सिखाती है कि कौन सा प्रमाणित क्लाइंट उसे ले जाता है। दोनों सही हों तो उपसर्ग बहता है; एक सही हो तो पैकेट के पास मार्ग है पर मालिक नहीं।

दो निर्देशिकाएँ, दो अलग काम

route-ipv6 एक सामान्य मार्ग संस्थापन है: सर्वर एक कर्नेल मार्ग जोड़ता है जो उपसर्ग को अपने टनल इंटरफ़ेस की ओर इंगित करता है। iroute-ipv6 किसी विशेष क्लाइंट के संदर्भ से जुड़ी है और आंतरिक स्वामित्व घोषित करती है, ताकि डेमन जान ले कि उस उपसर्ग का ट्रैफ़िक किसी खास क्लाइंट को भेजा जाना चाहिए, न कि उस पीयर को जिसे कर्नेल मार्ग संयोग से नाम देता है।

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

पारंपरिक userspace सेटअप में दोनों ज़रूरी हैं और एक-दूसरे को पूरा करती हैं। अकेला कर्नेल मार्ग डेमन को पीयर चुनने में असमर्थ छोड़ देता है। अकेला iroute कर्नेल को टनल तक रास्ते के बिना छोड़ देता है। यहीं से प्रति-क्लाइंट फ़ाइलों की अधिकतर उलझन आती है: फ़ाइल मार्ग तालिका की प्रविष्टि नहीं है, और मार्ग प्रविष्टि स्वामित्व की घोषणा नहीं है।

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

कौन कहाँ जाता है

मार्ग सर्वर की प्रबंधित कॉन्फ़िगरेशन में जाता है, जहाँ वह उसी सर्वर प्रक्रिया पर लागू होता है। iroute क्लाइंट-विशिष्ट फ़ाइल में जाता है, जो शाखा डिवाइस की प्रमाणित पहचान के नाम पर है।

ऐसा फ़ाइल नाम जो वास्तविक पहचान से मेल नहीं खाता, कभी पढ़ा नहीं जाता, और लक्षण बिल्कुल गुम iroute जैसा होता है। जिस पहचान को सर्वर ने प्रमाणित किया उसे जाँचें, फिर फ़ाइल नाम को अक्षर-दर-अक्षर जाँचें।

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

पूल और शाखा उपसर्ग को अलग रखें, क्योंकि इनका ओवरलैप ऐसी पहेली बनाता है जिसे कोई निर्देश हल नहीं कर सकता।

दूसरे क्लाइंट को क्या चाहिए

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

इसे स्वयं शाखा को न भेजें, क्योंकि उस डिवाइस के पास उपसर्ग पहले से जुड़े नेटवर्क के रूप में है।

इसे सबको भेजना परिणामों वाला चुनाव है: तब हर क्लाइंट मानता है कि शाखा टनल से पहुँच योग्य है, उन क्लाइंट्स सहित जिन्हें आपने कभी यह पहुँच देना नहीं चाहा था। घोषणा व्यवहार में पहुँच का निर्णय है, भले ही निर्देश प्लंबिंग के काम जैसा लगे। सर्वर विकल्प संदर्भ iroute-ipv6 को क्लाइंट-विशिष्ट स्वामित्व के रूप में दस्तावेज़ करता है, और यही वह अंतर है जिसे रखना सार्थक है।

शाखा डिवाइस पर वापसी का रास्ता

स्वामित्व तभी मदद करता है जब शाखा पैकेट फ़ॉरवर्ड करे और उसका LAN जवाब देना जाने। शाखा डिवाइस पर IPv6 फ़ॉरवर्डिंग सक्षम करें, और पुष्टि करें कि उसके LAN के होस्ट VPN पूल का ट्रैफ़िक वापस शाखा की ओर भेजते हैं, न कि ऐसे डिफ़ॉल्ट मार्ग की ओर जो पूल को नहीं जानता।

वह वापसी का रास्ता IPv6 में उस गुम मार्ग समस्या का समकक्ष है जिससे लोग IPv4 में मिलते हैं।

इसे LAN के होस्ट से VPN पूल के पते की क्वेरी के साथ जाँचें, स्वयं शाखा से नहीं। राउटर पर की गई क्वेरी आपके उपयोगकर्ताओं के सवाल से अलग सवाल का जवाब देती है, और दोनों इतनी बार अलग होते हैं कि अतिरिक्त कमांड सार्थक हो।

जब जोड़ी अब भी पर्याप्त न हो

कुछ परिनियोजन इस रास्ते का बिल्कुल उपयोग नहीं करते। कर्नेल का डेटा पथ और उत्पाद-प्रबंधित सर्वर अपनी समर्थित मार्ग हैंडलिंग रखते हैं, और userspace का उदाहरण सीधे स्थानांतरित न हो सके।

दूसरे के लिए लिखी गाइड से निर्देश कॉपी करने से पहले पुष्टि करें कि आपका बिल्ड कौन सा डेटा पथ उपयोग करता है।

और अंत में, पतों का दायरा याद रखें: अद्वितीय स्थानीय उपसर्ग जैसे fd00:7a::/64 डिज़ाइन से निजी है और सार्वजनिक IPv6 पहुँच के बारे में कुछ नहीं कहता। इसे आंतरिक पहुँच मानें, और इंटरनेट से बाहर जाने को अपनी नीति वाला अलग मामला रखें।