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 पहुँचबारे केही भन्दैन। यसलाई आन्तरिक पहुँच मान्नुहोस्, र इन्टरनेट बाहिर जाने कुरा आफ्नै नीति भएको अलग विषय राख्नुहोस्।