दुई साइट, एउटा सबनेट: प्रत्येकका लागि अलियास दृश्य बनाउनुहोस्

दुई ग्राहक साइट दुवैले 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 मार्गदर्शिका ले एउटा ठोस अनुवाद मोडेल अभिलेख गर्छ; त्यो हरेक प्लेटफर्मका लागि सम्झौता होइन।