दो साइटें, एक सबनेट: हर एक के लिए अलियास दृश्य बनाएँ

दो ग्राहक साइटें दोनों 192.168.50.0/24 चलाती हैं, और एक दूरस्थ इंजीनियर को हर एक में उसी पते पर मौजूद प्रिंटर तक पहुँचना है। कोई भी रूटिंग तरकीब इस अस्पष्टता को अकेले हल नहीं करती। हर साइट को अलग पता-दृश्य चाहिए, और गेटवे को कुछ भी अग्रेषित करने से पहले उसी दृश्य से साइट चुननी होगी।

योजना के चार भाग हैं: अलियास प्रीफ़िक्स, दोनों अनुवाद दिशाएँ, ओवरले नीति और नाम। हर भाग को बाकी से मेल खाना चाहिए।

हर साइट के लिए एक अलियास प्रीफ़िक्स चुनें

हर साइट को एक पूरा अलियास प्रीफ़िक्स दें जो परिवेश में किसी और का न हो। दो साइटों की योजना साइट A के 192.168.50.0/24 को 172.21.10.0/24 पर और साइट B के समान LAN को 172.21.20.0/24 पर मैप कर सकती है। उम्मीदवारों को हर भाग लेने वाले नेटवर्क के विरुद्ध जाँचें, जिसमें क्लाउड VPC और अन्य VPN पूल शामिल हैं। निजी पता-स्थान हर संगठन साझा करता है, इसलिए कोई रेंज RFC 1918 होना यह नहीं बताता कि वह यहाँ मुक्त है।

दूरस्थ उपयोगकर्ताओं को मूल सबनेट नहीं, अलियास प्रकाशित करें। मूल रेंज स्थानीय तथ्य ही रहती है।

दोनों दिशाओं में अनुवाद करें

दोनों दिशाओं में अनुवाद करें। गंतव्य मैपिंग अलियास पते को मालिक साइट पर मूल पते में फिर से लिखती है। स्रोत मैपिंग दूरस्थ कॉलर को ऐसे अलियास में फिर से लिखती है जिसे अन्य साइटें अलग पहचान सकें।

स्थिर एक-से-एक मैपिंग नियतात्मक है, और इससे कार्यान्वयन स्टेटलेस नहीं हो जाता। उलटा अनुवाद कनेक्शन स्थिति पर निर्भर हो सकता है, और फ़ेलओवर या असममित पथ उस योजना को तोड़ सकते हैं जो इसे अनदेखा करती है। प्लेटफ़ॉर्म का दस्तावेज़ तय करता है कि इनमें से कौन-सा लागू होता है।

नीति, सेलेक्टर और रूट किस ठीक चरण में लागू होते हैं, यह पॉलिसी-आधारित IPsec, रूट-आधारित टनल और अन्य उत्पादों के बीच अलग होता है। जो आप चलाते हैं उसके लिए डिज़ाइन करें।

योजना को ओवरले से गुज़ारें

हब में, हर अलियास प्रीफ़िक्स को उसकी मालिक साइट-पथ को सौंपें और केवल वही ट्रांज़िट अनुमत करें जो कार्य को चाहिए। मेश में, हर संबंधित पीयर को वही प्रीफ़िक्स और नीति-ज्ञान चाहिए। टनल जोड़ना अस्पष्ट पता-निर्धारण को अपने आप ठीक नहीं करता।

पूरे सबनेट का प्रकाशन एक सेवा के प्रकाशन से व्यापक है। अगर केवल कुछ मशीनें या पोर्ट चाहिए, तो एक्सेस नियमों को मैपिंग से संकरा रखें।

हेडर अनुवाद एप्लिकेशन पेलोड को फिर से नहीं लिखता। रीडायरेक्ट, कॉन्फ़िगरेशन फ़ाइलों में एम्बेड किए गए पते और स्रोत-आधारित अनुमतियाँ सब अब भी मूल पता ले जा सकती हैं। केवल पिंग नहीं, एप्लिकेशन पथ का परीक्षण करें। काम करने वाला ICMP उत्तर साबित करता है कि मैपिंग मौजूद है और इस बारे में कुछ नहीं कहता कि एप्लिकेशन अलियास स्वीकार करता है या नहीं।

हर कॉलर जो नाम देखता है उन्हें ठीक करें

रखरखाव नामों को कॉलर के दृश्य से मेल खाते उत्तर दें। अगर दूरस्थ इंजीनियर होस्टनाम हल करता है, तो उसे उस साइट का अलियास पता लौटाना चाहिए, साझा मूल रेंज नहीं।

पहली रखरखाव विंडो से पहले हर साइट के लिए DNS दृश्य जाँचें। जो नाम मूल सबनेट में हल होता है, वह कॉलर को उसी अस्पष्टता में वापस भेजता है जिसे योजना को हटाना था।

हर साइट के लिए रिकॉर्ड करें और सत्यापित करें

वास्तविक कॉलर से हर साइट अलग-अलग स्वीकार करें और पुष्टि करें कि कौन-सी मशीन उत्तर दी। मूल पता, अलियास, मालिक गेटवे और अनुमत सेवा एक साथ रिकॉर्ड करें।

जब तीसरी साइट उसी डिफ़ॉल्ट LAN के साथ आती है, तब यही सूची अंतर बनाए रखती है। पॉलिसी-आधारित IPsec NAT मार्गदर्शिका एक ठोस अनुवाद मॉडल का दस्तावेज़ीकरण करती है; यह हर प्लेटफ़ॉर्म के लिए अनुबंध नहीं है।