VPN पता स्थान को आवंटन से चुनें, अस्पष्टता से नहीं
बेंचमार्क, साझा और दस्तावेज़ीकरण श्रेणियों में से प्रत्येक का एक स्वामी और उद्देश्य है। रजिस्ट्री से VPN स्थान चुनें, फिर उस अतिव्याप्ति की योजना बनाएं जिसे आप हटा नहीं सकते।
असामान्य दिखने वाला उपसर्ग घर और दफ़्तर के पता संघर्ष से बच निकलने का रास्ता लगता है, और आम तौर पर होता नहीं। IPv4 विशेष-प्रयोजन रजिस्ट्री में हर ब्लॉक का एक स्वामी, एक उद्देश्य और उसके होने का एक कारण है, और किसी को इसलिए उधार लेना कि वह शांत दिखता है, टकराव को हटाने के बजाय उसे स्थानांतरित कर देता है। इसे एक क्रम के रूप में चलाएं: आवंटन पढ़ें, जो पहले से अतिव्यापी है उसकी सूची बनाएं, और उसके बाद ही तय करें कि आप पुनःसंख्या कर रहे हैं, अनुवाद कर रहे हैं या नया स्थान बना रहे हैं। क्रम मायने रखता है क्योंकि तीसरा चरण इस पर निर्भर है कि पहले दो ने क्या पाया।
श्रेणी उधार लेने से पहले आवंटन पढ़ें
IANA की विशेष-प्रयोजन रजिस्ट्री उन श्रेणियों को अलग करती है जो पुनः प्रयोग योग्य निजी स्थान हैं, उन श्रेणियों से जो एक विशिष्ट तकनीकी उद्देश्य पूरा करती हैं। निजी उपयोग, साझा पता स्थान, बेंचमार्क और दस्तावेज़ीकरण ब्लॉक स्प्रेडशीट में एक जैसे दिखते हैं और रूट होने के बाद पूरी तरह अलग व्यवहार करते हैं।
| Range | Category | What it means for a VPN plan |
|---|---|---|
| 172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8 | RFC 1918 private use | Reusable by any network, so remote sites may already use the same numbers |
| 100.64.0.0/10 | Shared address space | Intended for provider-side carrier-grade NAT arrangements, not a second private pool |
| 198.18.0.0/15 | Benchmarking | Reserved for test traffic measurement; not spare production space |
| 203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24 | Documentation (RFC 5737) | Illustration only; a guide that uses them is not assigning them to you |
| 169.254.0.0/16, 240.0.0.0/4 | Link-local, reserved | Never a routed site subnet, whatever the prefix length suggests |
दो उपसर्ग जो केवल दूसरे ऑक्टेट में भिन्न हैं, एक ही ब्लॉक नहीं हैं: 198.18.0.0/15 बेंचमार्क आरक्षण लेकर चलता है, जबकि 192.18.0.0/16 ऐसा कुछ नहीं लेकर चलता। केवल आरक्षित श्रेणी जैसा दिखने वाला अंक उसका अर्थ विरासत में नहीं पाता। यह भ्रम इतना आम है कि फ़ायरवॉल नियम तक पहुँचने से पहले दूसरी नज़र का हक़दार है।
उत्पाद कभी-कभी समन्वित ओवरले के भीतर जानबूझकर एक विशेष श्रेणी का उपयोग करते हैं, और यह उनका डिज़ाइन है जिसे दस्तावेज़ित करना चाहिए। इससे वही श्रेणी किसी असंबंधित LAN के लिए खाली स्थान नहीं बन जाती। सार्वजनिक स्थान भी छिपने की जगह नहीं है: किसी और के पते तक का निजी मार्ग उसके वैध गंतव्य के लिए भेजे गए ट्रैफ़िक को मोड़ देता है।
जो अतिव्याप्तियाँ आपके पास पहले से हैं उनकी सूची बनाएं
उपसर्ग चुनने से पहले हर उस नेटवर्क को सूचीबद्ध करें जो सुरंग से पहुँच योग्य होगा। साइटें, क्लाइंट पूल, क्लाउड VPC और भागीदार लिंक सभी गिने जाते हैं, और भागीदार लिंक वही है जिसे लोग पहले कनेक्शन प्रयास के विफल होने तक भूल जाते हैं।
ip -4 route show table all ip -6 route show ip -br addr ip route get 192.168.1.10
परिणामों को एक तालिका में हर श्रेणी के स्वामी के साथ बगल में रखें। जिस श्रेणी के लिए आप स्वामी का नाम नहीं बता सकते, वह ऐसी श्रेणी है जिसे आप बाद में पुनःसंख्या नहीं कर सकेंगे, और सूची ही «असामान्य» उपसर्गों पर बहस को ठोस अंकों के फ़ैसले में बदलती है। यह आपको यह भी बताती है कि जिस टकराव से आप बचना चाहते हैं वह वास्तविक है या काल्पनिक।
यदि किसी दूरस्थ कर्मचारी का घरेलू नेटवर्क दफ़्तर के LAN जैसा ही उपसर्ग उपयोग करता है, तो वह टकराव सूची में दिखता है और उसका स्पष्ट रूप से निपटान किया जा सकता है। यह इस बात का प्रमाण नहीं है कि बेंचमार्क ब्लॉक चतुर विकल्प होगा, और उसे ऐसे मानना ही अगली टक्कर पैदा करने का तरीका है।
उपसर्ग कॉपी करने के बजाय एक अनोखा ULA बनाएं
IPv6 पुनःउपयोग की समस्या को सुंदर अंक के बजाय एक भिन्न तंत्र से हल करता है। RFC 4193 स्थानीय रूप से आवंटित अनोखे स्थानीय पतों को छद्म-यादृच्छिक 40-bit वैश्विक पहचानकर्ता के साथ परिभाषित करता है, जो आपको ऐसी साइट /48 देता है जिसके किसी और से टकराने की संभावना बहुत कम है। संभावना अधिक है, पूर्ण नहीं, और ULA उपसर्ग फिर भी इंटरनेट पहुँच नहीं देता।
openssl rand -hex 5
दस हेक्साडेसिमल अंक चालीस बिट हैं। उनके आगे fd लगाएं और उन्हें /48 में समूहित करें: 3f9c1a7b02 का आउटपुट fd3f:9c1a:7b02::/48 बन जाता है। हर साइट के लिए एक बनाएं और दर्ज करें, हर परिनियोजन में वही सुविधाजनक fd00::/48 चिपकाने के बजाय।
फिर पुष्टि करें कि पूरा पथ वास्तव में IPv6 बोलता है। क्लाइंट, गेटवे, मार्ग, निजी DNS और सेवा नीति सभी को सहमत होना चाहिए, और सुरंग को उपसर्ग सौंपने से केवल IPv4 वाला अनुप्रयोग उसका उपयोग नहीं करने लगता।
उस अतिव्याप्ति की योजना बनाएं जिसे आप हटा नहीं सकते
कुछ अतिव्याप्तियाँ स्थायी होती हैं, आम तौर पर इसलिए कि भागीदार पुनःसंख्या नहीं करेगा और आप उसे बाध्य नहीं कर सकते। तब आप जानबूझकर एक समर्थित तंत्र चुनते हैं: अपनी ओर पुनःसंख्या, एक पृथक रूटिंग संदर्भ, या किसी सीमा पर स्पष्ट अनुवाद। जानबूझकर चुनने का अर्थ है लिखना कि आपने कौन-सा चुना और बाकी दो क्यों अस्वीकार किए गए। वही टिप्पणी है जिसे भविष्य की परिवर्तन समीक्षा वास्तव में पढ़ेगी।
अनुवाद को वापसी पथ सुरक्षित रखना चाहिए, यानी मूल और प्रस्तुत दोनों उपसर्ग दर्ज करें और उन्हें उन निजी DNS नामों से मिलाएं जो उनमें हल होते हैं। मैप किया गया उपनाम एक कनेक्शन को असंदिग्ध बना सकता है; यह मूल पतों को वैश्विक रूप से अनोखा नहीं बनाता और दूसरे मैपिंग के बिना दूसरे अतिव्यापी भागीदार तक नहीं टिकेगा।
आवंटन को उसके अपवाद के साथ लिखें
एक दस्तावेज़ के साथ समाप्त करें जो हर उपसर्ग, उसकी श्रेणी, उसका स्वामी और चयन का कारण सूचीबद्ध करे। अपवादों को उनके अनुवाद या पुनःसंख्या नियम और किसी द्वारा अनुमोदन की तिथि के साथ जोड़ें। इसे उन फ़ायरवॉल नियमों के पास रखें जो इसे लागू करते हैं, न कि ऐसी विकी में जिसे घटना के दौरान कोई नहीं खोलता। दस्तावेज़ ही डिलीवरेबल है, उसका सारांश नहीं।
यही अभिलेख अगले इंजीनियर को और अजीब दिखने वाला अंक खोजने से रोकता है, और इसी तरह यह समस्या हर कुछ वर्षों में नए नाम से फिर खोजी जाती है। यह परिवर्तन समीक्षा को उपसर्गों पर राय के बजाय अनुमोदन के लिए कुछ ठोस देता है। इसे एक बार, आवंटन के अंत में लिखें, जब तर्क अभी आपके सामने हो।