ASA स्थानान्तरणका लागि सन्दर्भका रूपमा आउने IOS कन्फिगरेसनले एउटा प्लेटफर्मको वाक्यरचनामा बेरिएको सम्झौता वर्णन गर्छ। पियर ठेगाना, पहिचान र सुरक्षित दायराहरू सम्झौता हुन्। key ring, प्रोफाइल र crypto map शृंखला IOS ले त्यो कसरी व्यक्त गर्छ भन्ने हो, जबकि ASA ले tunnel group र तिनका गुणहरूमार्फत त्यही मनसाय व्यक्त गर्छ। दोस्रो भाग प्रतिलिपि गर्दा कहिल्यै काम गर्दैन, र पहिलो मात्र गर्दा काम आधा रहन्छ।

तलका पाँच चरण क्रमैसँग पूरा गर्नुहोस्, र जहाँ दुई प्लेटफर्मले फरक शब्द नभई फरक कुरा वर्णन गर्छन् त्यहीँ रोक्नुहोस्।

चरण 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 key ring ले IKEv2 प्रोफाइललाई खुवाउँछ, र त्यो प्रोफाइल crypto map वा IPsec प्रोफाइलमार्फत जोडिन्छ। ASA मा tunnel group ले connection profile र त्यसका IPsec गुणहरू राख्छ, र crypto map ले त्यसैतर्फ सङ्केत गर्छ, जस्तै connection profile सम्बन्धी मार्गदर्शिका वर्णन गर्छ। ती फरक अधिग्रहण भएका फरक वस्तु-ग्राफ हुन्, त्यसैले लाइन-दर-लाइन म्यापिङले पार्स हुने तर जडान नहुने कन्फिगरेसन दिन्छ।

लक्ष्य वस्तुहरू स्रोत लाइनबाट नभई आवश्यकता पङ्क्तिबाट बनाउनुहोस्। पङ्क्तिहरू पूरा भए लक्ष्य कन्फिगरेसन एउटा डिजाइन निर्णय हो। नभए जति आदेश अनुवाद गरे पनि छुटेको मनसाय आउँदैन।

चरण 3: ठेगाना मात्र नभई पहिचान बोक्नुहोस्

पहिचान त्यो भाग हो जो चुपचाप बिग्रन्छ। ठेगानाले प्रमाणित गर्ने पियरको व्यवहार प्रमाणपत्र विषय वा FQDN ले प्रमाणित गर्नेभन्दा फरक हुन्छ, र दुई प्लेटफर्मले त्यो अपेक्षा फरक ठाउँमा लेख्छन्। परीक्षण गर्न सजिलो भन्दै साझा गोप्य राख्ने होइन, इच्छित पहिचान र विश्वास शृंखला जोगाउनुहोस्।

पूर्व-साझा गोप्यलाई तुलना टिप्पणी र टिकटबाट बाहिर राख्नुहोस्। यो कसको स्वामित्वमा छ र स्वीकृत माध्यमबाट कसरी सर्छ लेख्नुहोस्, र कागजातको उदाहरणको प्लेसहोल्डर ग्राहकको क्रेडेन्सियल होइन भन्ने सम्झनुहोस्।

चरण 4: कटओभरअघि सुरक्षामा सहमत हुनुहोस्

पुराना क्रिप्टोग्राफिक सेटिङ दिइएको पाठमा छन् भन्दैमा सार्नु हुँदैन। दुवै तैनाथ पियरले अहिले समर्थन गर्ने सुटको प्रतिच्छेदनमा सहमत हुनुहोस्, र परिवर्तन विन्डोअघि अर्को प्रशासकसँग पुष्टि गर्नुहोस्। त्यो प्रतिच्छेदन विद्यमान पियरले अपेक्षा गरेकोभन्दा फरक भए यो समन्वित परिवर्तन हो, स्थानीय सम्पादन होइन।

सहमत सेट लेख्नुहोस्। फोन कलको फरक सम्झना भएका दुई प्रशासकले नै कटओभरमा फेज-दुई बेमेल ल्याउँछन्।

चरण 5: वाक्यरचना होइन, सेवा प्रमाणित गर्नुहोस्

पहिले लक्ष्यका प्रभावकारी वस्तु जाँच्नुहोस्, त्यसपछि स्वीकृत सम्बन्ध, त्यसपछि वास्तविक अनुप्रयोग प्रवाह र त्यसको जवाफ। त्रुटिबिना आदेश टाइप गर्नुले वाक्यरचना मात्र प्रमाणित गर्छ। सुरुङ उठेर ट्राफिक नबोक्नु सामान्यतया सुरक्षित दायरा वा फिर्ता मार्ग अर्को पक्षसँग नमिल्नु हो, जो आदेशको होइन, आवश्यकता पङ्क्तिको समस्या हो। crypto map फेरि छुनुअघि दुवै पक्षका सुरक्षित दायरा तुलना गर्नुहोस्।

के प्रमाणित गर्नुभयो, कुन ठेगानासँग, कुन पक्षबाट — लेख्नुहोस्। त्यो अभिलेखले VPN चलिरहेको छ भन्ने अस्पष्ट दाबीलाई अर्को प्रशासकले स्वतन्त्र रूपमा जाँच्न सक्ने कुरामा बदल्छ।

के फर्काउने

आवश्यकता म्याट्रिक्स, लक्ष्य कन्फिगरेसनको सारांश र प्रमाणीकरण परिणाम पठाउनुहोस्। कुन स्रोत सेटिङ सारिएन र किन, स्पष्ट भन्नुहोस्। त्यो सूची अनुवादित कन्फिगरेसनभन्दा उपयोगी छ, किनकि अर्को असहमति त्यहीँबाट सुरु हुन्छ।

स्रोत पाठ पनि टिकटसँगै राख्नुहोस्। यसले के मागिएको थियो देखाउँछ, जबकि म्याट्रिक्सले के सहमति भयो देखाउँछ।

सम्बन्धित लेखहरू