दो साइट वाले WireGuard हब के लिए IPv6 योजना: प्रीफ़िक्स, पीयर, रूट
दो LAN के लिए एक निजी IPv6 हब पर काम करें: प्रीफ़िक्स चुनें, टनल पते सुरक्षित रखें, फिर AllowedIPs को बताने दें कि कौन सा पीयर किस सबनेट का मालिक है।
दो LAN, एक WireGuard हब और एक IPv6 पता योजना जिसे तीन अलग सवालों का जवाब देना है: कौन सा प्रीफ़िक्स, कौन सा पता किस राउटर का है, और कौन सा पीयर किस सबनेट का मालिक है। इनमें से एक भी गलत हुआ तो ऐसा टनल बनता है जो हैंडशेक करता है और कुछ भी रूट नहीं करता। नीचे की योजना उसी क्रम में एक निजी दो-साइट डिज़ाइन पर काम करती है। यह जानबूझकर IPv6 इंटरनेट एक्सेस नहीं देती।
तय करें कि प्रीफ़िक्स किस लिए है
जब लक्ष्य साइटों के बीच निजी पहुँच हो तो fd00::/8 से एक अद्वितीय-स्थानीय प्रीफ़िक्स स्वाभाविक विकल्प है। हर जगह को कौन सा ISP सेवा देता है, इससे अलग रहकर यह स्थिर रहता है और वैश्विक रूटिंग तालिका में घोषित नहीं होता, इसलिए यह आपकी आंतरिक नंबरिंग को इंटरनेट पर लीक नहीं कर सकता।
यही गुण सीमा है। ULA कोई सार्वजनिक वापसी मार्ग नहीं देता, क्योंकि कोई अपस्ट्रीम इसे आपके गेटवे तक रूट करना नहीं जानता। अगर आवश्यकता में IPv6 इंटरनेट इग्रेस शामिल है, तो आपको चाहिए ऐसे प्रदाता से आवंटन जो इसे आप तक रूट करता है, और यह अपने प्रीफ़िक्स आकार वाला अलग डिज़ाइन निर्णय है।
यह न मानें कि हर परिनियोजन को /48 चाहिए। RFC 6177 एक अनिवार्य अंत-साइट आकार से दूर चला गया, और सही आकार उन नेटवर्कों की संख्या पर निर्भर करता है जिन्हें आप चलाएँगे। ULA को RFC 4193 प्रक्रिया से बनाएँ, न कि ऐसा प्रीफ़िक्स गढ़ें जिसे कोई दूसरा संगठन भी इस्तेमाल कर सके। किसी भी डिवाइस के कॉन्फ़िगर होने से पहले परिणाम को पता योजना में लिखें, क्योंकि जिस प्रीफ़िक्स को किसी ने दर्ज नहीं किया वह ऐसा प्रीफ़िक्स है जिसे कोई फिर इस्तेमाल करेगा।
प्रीफ़िक्स को भूमिकाओं में बाँटें
नीचे का उदाहरण fd7c:2e91:4a00::/48 इस्तेमाल करता है, और तालिका साइट के बजाय इस आधार पर व्यवस्थित है कि हर ब्लॉक कहाँ लिखा जाता है। मानों को नमूना मानें और कुछ भी परिनियोजित करने से पहले अपने बनाएँ।
| Where it is written | What appears there | Block used | What it establishes |
|---|---|---|---|
| Hub wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::1/128 | The hub's own tunnel identity |
| Hub wg0.conf, Site A peer | Two ranges in one AllowedIPs line | ::2/128 and :10::/64 | That A owns its tunnel address and its LAN |
| Hub wg0.conf, Site B peer | Two ranges in one AllowedIPs line | ::3/128 and :20::/64 | That B owns its tunnel address and its LAN |
| Site A wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::2/128 | A's identity as the hub sees it |
| Site B wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::3/128 | B's identity as the hub sees it |
LAN ब्लॉक /64 हैं क्योंकि सामान्य SLAAC 64-बिट इंटरफ़ेस पहचानकर्ता की अपेक्षा करता है। LAN को छोटे ब्लॉक में बाँटना अधिकांश होस्ट पर यह मान्यता तोड़ देता है, और निजी योजना में पते की बचत के लिए परिचालन लागत उचित नहीं है। दोनों LAN ब्लॉक /48 के मध्य से आते हैं, जिससे निचली श्रेणी बाद की साइटों के लिए खाली रहती है।
टनल पते एक प्रशासनिक भंडार हैं, लिंक पर कोई नेटवर्क नहीं। हर इंटरफ़ेस को उससे एक /128 मिलता है, इसलिए कोई होस्ट टनल पर साझा सबनेट नहीं मानता और जहाँ ज़रूरत नहीं वहाँ पड़ोसी खोज नहीं चलती। भूमिकाओं को अलग रखें और उन्हें संगठन की पता योजना में दर्ज करें ताकि बाद की साइट कोई ब्लॉक फिर से इस्तेमाल न करे।
हर राउटर को एक टनल पता दें
हर राउटर के लिए एक /128 आवंटित करें और काम कर रहे हब की मौजूदा कुंजियाँ और एंडपॉइंट रखें। नीचे के तीन मान केवल होस्ट भाग में भिन्न हैं।
Hub: Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128यह /128 उस इंटरफ़ेस को आवंटित एकमात्र पता बताता है। यह नहीं बताता कि पीयर कितने गंतव्यों को रूट कर सकता है, क्योंकि पहुँच इंटरफ़ेस प्रीफ़िक्स में नहीं, AllowedIPs में व्यक्त होती है।
हर साइट राउटर को अपने LAN ब्लॉक में एक पता और उसे वितरित करने का तरीका भी चाहिए, आमतौर पर SLAAC के लिए राउटर घोषणाएँ। WireGuard आपकी ओर से वे घोषणाएँ नहीं भेजता और दोनों LAN को जोड़ता नहीं। साइट राउटर दोनों दिशाओं में राउटर है।
सबनेट का स्वामित्व AllowedIPs में रखें
साइट A के लिए हब की पीयर प्रविष्टि A के टनल पते और A के LAN की मालिक है, और यही जोड़ी पूरा स्वामित्व वक्तव्य है। उस पीयर अनुभाग में और कुछ भी साइट का वर्णन करने की ज़रूरत नहीं।
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64साइट B की पीयर प्रविष्टि मेल खाती जोड़ी की मालिक है, और यहाँ समरूपता संक्षिप्तता से अधिक महत्वपूर्ण है। दोनों पंक्तियाँ साथ पढ़ें और स्वामित्व का विभाजन एक नज़र में दिखता है।
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64ये दो अलग पीयर अनुभाग हैं, एक पीयर के लिए प्रतिस्पर्धा करती दो सूचियाँ नहीं। WireGuard AllowedIPs का उपयोग दोनों दिशाओं में करता है: यह बाहर जाने वाले गंतव्य के लिए पीयर चुनता है, और ऐसे आने वाले पैकेट को अस्वीकार करता है जिसका स्रोत उस पीयर को आवंटित श्रेणी से मेल नहीं खाता जिसने उसे डिक्रिप्ट किया। दोनों पीयर को पूरा /48 देना उस दूसरी जाँच को बंद कर देता और धुँधला कर देता कि कौन सी साइट किस ब्लॉक की मालिक है। यही अंतर गलत स्रोत पते को चुपचाप स्वीकार होने के बजाय दिखाई देने योग्य बनाता है।
हर साइट को केवल वे गंतव्य चाहिए जो उसके हब पीयर के माध्यम से पहुँच योग्य हों: साइट A हब का पता, साइट B का टनल पता और B का LAN सूचीबद्ध करता है, और साइट B उल्टा समुच्चय सूचीबद्ध करता है। सूचियाँ जानबूझकर असममित हैं, क्योंकि हर राउटर टोपोलॉजी का अलग पक्ष देखता है। दोनों को पता योजना से लिखें, दूसरी साइट के कॉन्फ़िगरेशन से नहीं, क्योंकि इसी तरह पुरानी श्रेणी पुनः-क्रमांकन से बच जाती है।
wg-quick के साथ ये श्रेणियाँ रूट भी बनाती हैं। systemd-networkd या मैन्युअल सेटअप के साथ समतुल्य रूट स्वयं जोड़ें; अन्यथा टनल ऐसे पैकेट ले जाता है जिन्हें कर्नेल कभी उसमें नहीं भेजता।
फ़ॉरवर्डिंग पूरी करें और दोनों दिशाएँ परखें
हब पर और दोनों साइट राउटरों पर IPv6 फ़ॉरवर्डिंग सक्षम करें, और फ़ॉरवर्ड नीति में ज़रूरी अंतर-साइट सेवाओं की अनुमति दें। ICMPv6 Packet Too Big संदेशों को उपयोगी रखें, क्योंकि उन्हें छोड़ देने से पथ MTU खोज टूटती है और बड़े स्थानांतरणों में ऐसी रुकावटें बनती हैं जो अनुप्रयोग दोष जैसी दिखती हैं। फ़ायरवॉल अनुमति के बिना फ़ॉरवर्ड करने वाला हब पैकेट को रूटिंग और टनल के बीच छोड़ देता है। यह विफलता मोड जानने योग्य है, क्योंकि टनल चालू रहता है और केवल कुछ प्रवाह मरते हैं।
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1साइट A के होस्ट से साइट B के होस्ट तक और फिर उल्टी दिशा में परखें। हब के टनल पते पर ping केवल पहली छलांग परखता है और LAN रूट गलत होने पर भी सफल होगा। होस्ट-से-होस्ट प्रवाह ही योजना को सिद्ध करता है।
बाहरी WireGuard कनेक्शन IPv4 पर चल सकता है जबकि आंतरिक ट्रैफ़िक IPv6 हो, और यह स्वतंत्रता माइग्रेशन के दौरान उपयोगी है। अगर बाद में वैश्विक IPv6 इग्रेस जोड़ा जाए, तो प्रदाता आवंटन, स्रोत पता चयन और वापसी रूटिंग को नए डिज़ाइन चरण के रूप में फिर देखें; ऊपर की निजी योजना साइट-से-साइट ट्रैफ़िक के लिए मान्य रहती है।