दोन साइट, एक सबनेट: प्रत्येकासाठी अॅलियास दृश्य तयार करा

दोन ग्राहक साइट दोन्ही 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 मार्गदर्शक एक ठोस भाषांतर मॉडेल नोंदवते; ते प्रत्येक प्लॅटफॉर्मसाठी करार नाही।