तुमचे /64 विभाजित करणे IPv6 ला VPN क्लायंट्सपर्यंत राउट करत नाही

क्लायंट जागतिक IPv6 पत्ता दाखवतो, हँडशेक पूर्ण झाला आहे, आणि इंटरनेटवरून काहीही परत येत नाही। पूल सेटिंग बरोबर दिसते कारण ती खरोखर बरोबर आहे; पत्ता वैध आहे आणि बोगदा तो वाहून नेतो। जे अयशस्वी होते ते म्हणजे वितरण, आणि वितरण VPN सर्व्हरच्या वर घेतलेल्या निर्णयावर अवलंबून आहे ज्यावर कोणतेही क्लायंट-साइड कॉन्फिगरेशन परिणाम करू शकत नाही।

गैरसमज: तुमच्या /64 चा एक भाग आधीच पोहोचण्यायोग्य आहे

कथा आकर्षक आहे: सर्व्हरकडे सार्वजनिक /64 आहे, तो अर्धा कापा, दुसरा अर्धा VPN पूलला द्या, आणि ते क्लायंट आता इंटरनेटवर आहेत। प्रीफिक्स विभाजित केल्याने टकरींशिवाय पत्ते वाटले जातात। पण त्यामुळे upstream नेटवर्क त्या पत्त्यांपैकी एकासाठी पॅकेट कुठे जायला हवे हे कसे ठरवते ते बदलत नाही।

IPv6 कडे आधार घेण्यासाठी कोणताही डीफॉल्ट भाषांतर स्तर नाही, म्हणून परतीचा मार्ग राउटिंग म्हणून किंवा लिंक-स्तरीय वितरण म्हणून असणे आवश्यक आहे। क्लायंटच्या बोगदा पत्त्याला उद्देशून पाठवलेले पॅकेट upstream राउटरकडे पोहोचते, आणि तो राउटर स्वतःच्या तक्त्यातून फॉरवर्डिंगचा निर्णय घेतो। जर तक्ता भौतिक लिंककडे निर्देश करत असेल, तर पॅकेट तिथे जाते, तुमचा VPN सर्व्हर काय मानतो याच्याशी संबंध नाही।

हाच संपूर्ण पराभव आहे: पुढची दिशा काम करते कारण तुमचा सर्व्हर ते पाठवतो, आणि परतीची दिशा एका हॉपच्या अंतरावर मरते कारण upstream ला कधीच कळले नाही की क्लायंट अस्तित्वात आहे।

लिंकवरील वितरणाला खरोखर काय आवश्यक आहे

जेव्हा upstream संपूर्ण /64 भौतिक लिंकवर असल्याचे मानतो, तेव्हा तो प्रत्येक गंतव्य पत्ता शेजारी शोधाद्वारे सोडवतो। तो त्या लिंकवर विनंती पाठवतो आणि पत्त्याच्या मालकाने उत्तर द्यावे अशी अपेक्षा करतो। बोगद्यामागे बसलेला VPN क्लायंट त्या लिंकवर नाही आणि उत्तर देऊ शकत नाही, म्हणून विनंती उत्तराशिवाय राहते आणि पॅकेट टाकून दिले जाते।

/65 कापून वेगळे करणे ती अपेक्षा बदलत नाही। upstream अजूनही श्रेणीकडे लिंकवर असल्यासारखे पाहतो, कारण त्याचे मत बदलणारी एकमेव गोष्ट म्हणजे क्लायंटच्या वतीने उत्तर देणारा मार्ग किंवा प्रॉक्सी। तुम्ही VPN कॉन्फिगरेशन संपादित केल्यामुळे दोन्हीपैकी काहीही दिसत नाही। हेच अंतर स्पष्ट करते की पूल स्वतःच्या क्लायंटमध्ये अगदी व्यवस्थित काम करू शकतो आणि तरीही इतर कुठूनही अप्राप्य का राहतो।

प्रॉक्सी शेजारी शोध ही अशी यंत्रणा आहे जी दोन जगांना जोडू शकते। गेटवे त्याच्याकडील विशिष्ट क्लायंट पत्त्यांसाठी विनंत्यांना उत्तर देतो आणि रहदारी बोगद्यात पाठवतो। हे काम करते, आणि ते नेमक्या त्या पत्त्यांपुरते मर्यादित असले पाहिजे, पूलाचे अनुसरण करणाऱ्या जीवनचक्रासह, कारण तुम्ही यापुढे सेवा देत नसलेल्या पत्त्याच्या वतीने उत्तर देणे दुसऱ्याची रहदारी काळ्या भोकात टाकते। काही upstream अशा प्रॉक्सी उत्तरांना स्वीकारणार नाहीत ज्यांची त्यांनी अपेक्षा केली नव्हती, म्हणून या रचनेला पुरवठादाराची संमतीही आवश्यक आहे।

राउटेड वितरणाला काय आवश्यक आहे

अधिक स्वच्छ रचना म्हणजे असे वाटप जे upstream खरोखर तुमच्या गेटवेकडे राउट करतो। ते प्रत्यायोजित प्रीफिक्स किंवा लहान ब्लॉकसाठी स्थिर मार्ग असू शकते, आणि दोन्ही बाबतीत आवश्यकता एकच आहे: upstream च्या तक्त्याने क्लायंट श्रेणीसाठी तुमच्या सर्व्हरकडे निर्देश करणे आवश्यक आहे। मग परतीची रहदारी गेटवेकडे येते आणि गेटवे ती बोगद्यात पाठवते।

राउटेड वितरण शेजारी शोधाचा प्रश्न पूर्णपणे दूर करते, म्हणून काहीतरी हुशार बांधण्यापूर्वी पुरवठादाराकडे ते मागणे योग्य आहे। मार्ग लिखित स्वरूपात मागा, आणि पुढील हॉप हा upstream खरोखर पोहोचू शकणारा पत्ता आहे याची खात्री करा।

दोन्ही रचनांना अजूनही गेटवेवर IPv6 फॉरवर्डिंग सक्षम आणि दोन्ही दिशांना फॉरवर्ड होणाऱ्या प्रवाहाला परवानगी देणारे फायरवॉल नियम आवश्यक आहेत। उर्वरित मार्गासाठी वितरण ही पूर्वअट आहे, पर्याय नाही। फॉरवर्डिंग बंद असलेला कार्यरत मार्ग गहाळ मार्गाइतकीच शांतता निर्माण करतो, म्हणून काहीही पुन्हा रचण्यापूर्वी दोन्ही तपासा।

योग्य करायचे दोन स्वतंत्र मार्ग

पूल प्रीफिक्स आणि क्लायंटचा स्वतःचा डीफॉल्ट मार्ग वेगवेगळी सेटिंग्ज आहेत, आणि त्यांचा गोंधळ केल्यास बोगदा तुटल्यासारखे दिसणारे अर्धवट कनेक्टिव्हिटी निर्माण होते। पूल सर्व्हरला कोणते पत्ते द्यायचे ते सांगतो। क्लायंटचे मार्ग क्लायंट कोणत्या गंतव्यांकडे रहदारी बोगद्यात पाठवतो हे ठरवतात।

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

वरील प्रीफिक्स ही दस्तऐवजीकरणाची जागा आहे, आणि रीडायरेक्ट फक्त IPv6 वर लागू होतो, जे IPv6 वितरण अजून दुरुस्त होत असताना दुहेरी-स्टॅक तैनाती अनेकदा इच्छित असते। IPv4 रीडायरेक्ट IPv6 कव्हरेज स्थापित करत नाही, आणि कोणतीही सेटिंग दुसऱ्याचा अर्थ देत नाही।

तुम्ही लागू करता त्या कोणत्याही धोरणाखाली IPv6 अवलंबून असलेली नियंत्रण रहदारी कार्यरत ठेवा। Packet Too Big संदेश हे फक्त TCP आणि UDP ला परवानगी देणाऱ्या फायरवॉलचे पारंपरिक बळी आहेत, आणि ते टाकून दिल्यास अशी कनेक्शन तयार होतात जी स्थापित होतात आणि नंतर मोठ्या स्थानांतरणांमध्ये अडकतात।

राउटर जाहिराती हा तिसरा हलणारा भाग आहे। गेटवेने अपलिंकवर जाहिरात करायला सुरुवात केल्यास, क्लायंट आणि शेजारी लिंकवरील प्रीफिक्सबद्दल काय मानतात ते बदलू शकते, ज्यामुळे तुम्ही नुकतीच दस्तऐवजीकृत केलेली रचना शांतपणे रद्द होऊ शकते।

रचना नोंदवा जेणेकरून पुनर्बांधणी ती पुनरुत्पादित करेल

तीन वस्तू वेगवेगळ्या लिहा: क्लायंट वाटप, क्लायंटचा गंतव्य मार्ग, आणि वाटपासाठी upstream ची वितरण पद्धत। तिन्ही असणारा वाचक तैनाती पुन्हा बांधू शकतो; फक्त पूल सेटिंग असणारा वाचक मूळ बग पुनरुत्पादित करेल।

नंतर परतीची दिशा स्पष्टपणे तपासा, बाहेरून परत यायलाच हव्या अशा पॅकेटसह। openvpn(8) पुस्तिका server-ipv6 आणि redirect पर्यायांना समाविष्ट करते, आणि तुमच्या पुरवठादाराची राउटिंग पुष्टी पुस्तिका करू शकत नसलेला अर्धा भाग समाविष्ट करते।