ASA स्थलांतरासाठी संदर्भ म्हणून येणारे IOS संरचना एका प्लॅटफॉर्मच्या वाक्यरचनेत गुंडाळलेल्या कराराचे वर्णन करते। पीअर पत्ते, ओळख आणि संरक्षित श्रेणी हाच करार आहे। की रिंग, प्रोफाइल आणि क्रिप्टो नकाशांची साखळी ही IOS तो कसा व्यक्त करतो हे आहे, तर ASA तीच इच्छा टनेल गट आणि त्यांच्या गुणधर्मांद्वारे व्यक्त करते। दुसरा भाग कॉपी करणे कधीच चालत नाही, आणि फक्त पहिला कॉपी केल्यास काम अर्धे राहते।

खालील पाच पायऱ्या क्रमाने पूर्ण करा आणि जिथे दोन्ही प्लॅटफॉर्म वेगळे शब्द नव्हे तर वेगळ्या गोष्टी वर्णन करतात तिथे थांबा।

पायरी 1: कराराला वाक्यरचनेपासून वेगळे करा

दोन्ही प्रशासक सहमत असलेल्या आवश्यकतांच्या स्वरूपात हस्तांतरण लिहा। चार ओळी जवळपास सर्व काही व्यापतात: पीअर कुठे आहे आणि कोणती बाजू सुरू करते, प्रत्येक बाजू आपली ओळख कशी सिद्ध करते, कोणते संरक्षण स्वीकार्य आहे आणि कोणत्या अनुप्रयोगांना टनेलमधून टिकावे लागते। या ओळींपैकी कोणतीही आदेशाचा उल्लेख करत नाही।

मूळ मजकूर सूचना म्हणून नाही तर पुरावा म्हणून ठेवा। एका प्लॅटफॉर्मवर असलेली आणि दुसऱ्यावर नसलेली ओळ वाक्यरचनेचा फरक आहे, जोपर्यंत तीच आवश्यकता दुसऱ्या मार्गाने पूर्ण होऊ शकते का हे तपासत नाही।

RequirementWhat must be agreed
Peer deliveryOuter endpoint, address family, NAT view, initiating side
AuthenticationIKE version, expected identities, credential method and delivery
Data protectionPermitted suites, protected ranges, intentional translation
ApplicationRoutes, return routes, resources beyond the tunnel

पायरी 2: प्रत्येक प्लॅटफॉर्मवरील ऑब्जेक्टना नावे द्या

IOS XE मध्ये IKEv2 की रिंग IKEv2 प्रोफाइलला पोषण देते आणि ते प्रोफाइल क्रिप्टो नकाशा किंवा IPsec प्रोफाइलद्वारे जोडले जाते। ASA मध्ये टनेल गट कनेक्शन प्रोफाइल आणि त्याचे IPsec गुणधर्म ठेवतो आणि क्रिप्टो नकाशा त्याकडे निर्देश करतो, जसे वर्णन करते कनेक्शन प्रोफाइल मार्गदर्शक। हे वेगवेगळ्या वारसाहक्काचे वेगवेगळे ऑब्जेक्ट आलेख आहेत, म्हणून ओळ-दर-ओळ जुळणी अशी संरचना देते जी पार्स होते पण जोडली जात नाही।

लक्ष्य ऑब्जेक्ट्स स्रोत ओळींऐवजी आवश्यकता ओळींमधून तयार करा। ओळी पूर्ण असल्यास, लक्ष्य संरचना हा एक रचना निर्णय आहे। नसल्यास, कोणतेही आदेश भाषांतर गहाळ हेतू पुरवणार नाही।

पायरी 3: केवळ पत्ते नाही तर ओळखही न्या

ओळख हा तो भाग आहे जो शांतपणे तुटतो। पत्त्याने प्रमाणित होणारा पीअर प्रमाणपत्राच्या विषयाने किंवा FQDN ने प्रमाणित होणाऱ्यापेक्षा वेगळा वागतो आणि दोन्ही प्लॅटफॉर्म ती अपेक्षा वेगवेगळ्या ठिकाणी नोंदवतात। चाचणी सोपी आहे म्हणून सामायिक गुपित बदलण्याऐवजी इच्छित ओळख आणि विश्वासाची साखळी जपून ठेवा।

पूर्व-सामायिक गुपित तुलना नोट्स आणि तिकिटांपासून दूर ठेवा। ते कोणाच्या मालकीचे आहे आणि मंजूर मार्गाने कसे जाते ते नोंदवा, आणि दस्तऐवजीकरणाच्या उदाहरणातील प्लेसहोल्डर ग्राहकाचे क्रेडेन्शियल नाही हे लक्षात ठेवा।

पायरी 4: स्विचओव्हरपूर्वी संरक्षणावर सहमती द्या

जुन्या क्रिप्टोग्राफिक सेटिंग्ज केवळ दिलेल्या मजकुरात आहेत म्हणून हस्तांतरित करू नका। दोन्ही तैनात पीअर सध्या समर्थन देत असलेल्या संचांचे छेदन ठरवा आणि बदलाच्या खिडकीपूर्वी ते दुसऱ्या प्रशासकाशी पुष्टी करा। ते छेदन सध्याच्या पीअरच्या अपेक्षेपेक्षा वेगळे असल्यास, तो स्थानिक संपादन नसून समन्वित बदल आहे।

सहमत संच लिहून ठेवा। फोन कॉलबद्दल वेगळ्या आठवणी असलेले दोन प्रशासक हेच कारण आहे की स्विचओव्हर दुसऱ्या टप्प्यात विसंगती निर्माण करते।

पायरी 5: वाक्यरचना नाही, सेवा सत्यापित करा

प्रथम लक्ष्याचे प्रभावी ऑब्जेक्ट्स तपासा, नंतर स्वीकारलेली सहयोगी रचना, नंतर प्रत्यक्ष अनुप्रयोग प्रवाह आणि त्याचे उत्तर। त्रुटीशिवाय आदेश देणे केवळ वाक्यरचना सिद्ध करते। वर येणारा पण रहदारी न वाहणारा टनेल सहसा याचा अर्थ संरक्षित श्रेणी किंवा परतीचा मार्ग दुसऱ्या बाजूशी जुळत नाही, ही आदेशाची नाही तर आवश्यकता ओळीची समस्या आहे। क्रिप्टो नकाशाला पुन्हा स्पर्श करण्यापूर्वी दोन्ही बाजूंच्या संरक्षित श्रेणींची तुलना करा।

काय तपासले, कोणत्या पत्त्यांसह, कोणत्या बाजूने ते नोंदवा। ती नोंद VPN सुरू आहे या अस्पष्ट दाव्याचे दुसरा प्रशासक स्वतंत्रपणे तपासू शकणाऱ्या गोष्टीत रूपांतर करते।

काय परत द्यायचे

आवश्यकता मॅट्रिक्स, लक्ष्य संरचनेचा सारांश आणि सत्यापनाचे निकाल पाठवा। कोणती स्रोत सेटिंग्ज हस्तांतरित केली नाहीत आणि का, ते स्पष्टपणे सांगा। ती यादी भाषांतरित संरचनेपेक्षा उपयुक्त आहे, कारण पुढील मतभेद तिथूनच सुरू होईल।

स्रोत मजकूरही तिकिटासोबत ठेवा। तो काय मागितले गेले हे नोंदवतो, तर मॅट्रिक्स कशावर सहमती झाली ते।

संबंधित लेख