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 पोहोचक्षमतेबद्दल काहीच सांगत नाही। त्याला अंतर्गत प्रवेश माना, आणि इंटरनेटबाहेर जाणे स्वतःच्या धोरणासह वेगळा विषय ठेवा।