एउटै WAN इन्टरफेसले साइट-टु-साइट र रिमोट VPN दुवै सेवा दिन सक्छ?
एउटै बाह्य ठेगानाले शाखा टनेल र घुम्ने प्रयोगकर्ताको पूल दुवै बोक्न सक्छ, तर पियर मिलान, प्रमाणीकरण, पूल र फर्किने मार्ग अलग रहे मात्र।
एउटै सार्वजनिक ठेगानाले एकै समयमा शाखा टनेल र घुम्ने प्रयोगकर्ताको पूल सेवा दिन सक्छ। तर एउटै साझा प्रवेश नियम सेवा दिन सक्दैन। शाखाको पियर र घुम्ने प्रयोगकर्ता फरक छन् — तिनीहरू आफूलाई को भन्छन्, त्यो प्रमाण कसरी जाँचिन्छ, कुन ठेगाना पाउँछन्, र कुन प्रिफिक्सले तिनलाई जवाफ दिन सक्छ भन्नेमा। बाह्य ठेगानालाई पहिचान नभई ढुवानीको विवरणका रूपमा लिन थालेपछि डिजाइन निकै सरल हुन्छ।
छिटो विवेक परीक्षण: राउटर छुनुअघि दुवै प्रवेश अभिलेख लेख्न प्रयास गर्नुहोस्। यदि एउटै मिलान सर्तले दुवै ढाक्नुपर्छ भने नीति पहिले नै अस्पष्ट छ, र पहिलो लक्षण राउटिङ वा फायरवालको खराबीजस्तो देखिन्छ, जबकि वास्तवमा त्यो पहिचानको खराबी हो।
कुनै पनि कन्फिगरेसनअघि दुई अभिलेख
शाखाको अभिलेख छोटो र स्थिर छ। यसले पियरको ठेगाना वा प्रमाणपत्रको नाम, पहिले नै साझा गरिएको कुञ्जी वा प्रमाणपत्रको ट्रस्टपोइन्ट, दुवैतर्फका सुरक्षित सबनेट, टनेल इन्टरफेस, र शाखातर्फको ट्राफिक त्यो टनेलमा पठाउने स्थिर मार्ग सूचीबद्ध गर्छ। प्रत्येक क्षेत्र एउटा ज्ञात पियर र प्रिफिक्सको निश्चित समूहसँग सम्बन्धित छ।
घुम्ने अभिलेख बढी फराकिलो र बढी व्यक्तिगत छ। यसले क्लाइन्ट प्रोटोकल र पोर्ट, प्रयोगकर्ता वा यन्त्रले कसरी प्रमाणीकरण गर्छ, जोडिँदा दिइने ठेगाना पूल, त्यो पूलले पुग्न सक्ने स्रोत, स्प्लिट टनेल प्रिफिक्स, क्लाइन्टतर्फ पठाइने DNS सर्भर, र कुनै दोस्रो कारक सूचीबद्ध गर्छ। प्रत्येक क्षेत्र एउटा गेटवेको बारेमा नभई अज्ञात संख्याका प्रयोगकर्ताको प्रश्नको जवाफ दिन्छ।
विवरणको यही भिन्नता दुई भूमिका अलग हुनुको पूरा कारण हो। शाखा प्रोफाइलले एउटा कुञ्जीमा सुरक्षित रूपमा भरोसा गर्न सक्छ, किनकि कुञ्जी एउटै ठाउँको एउटै यन्त्रको हो। सबैका लागि एउटै समूह कुञ्जीमा भरोसा गर्ने घुम्ने प्रोफाइलले प्रयोगकर्ता-पिच्छे जवाफदेही भत्काउँछ, र यो सामान्यतया पछि, तैनाथीको बेला नभई घटना समीक्षाको बेला थाहा हुन्छ।
पियर मिलान र प्रमाणीकरण कहाँ अलग हुन्छन्
IOS XE मा IKEv2 प्रोफाइलले वार्ता गर्न नसकिने प्यारामिटर र पियर छान्न प्रयोग हुने सर्त बोक्छ। यसको अर्थ शाखा पक्ष र घुम्ने पक्ष दुवैलाई आ-आफ्नै प्रोफाइल चाहिन्छ, तिनीहरू एउटै इन्टरफेसमा टुंगिए पनि र एउटै क्रिप्टो PKI साझा गरे पनि। Cisco ले प्रोफाइल, प्रमाणीकरण र मिलानका भूमिका आफ्नो IOS XE 17 का लागि IKEv2 कन्फिगरेसन मार्गदर्शनमा।
शाखा प्रोफाइल सामान्यतया साँघुरो पहिचानसँग मिल्छ: टाढाको ठेगाना, FQDN, वा प्रमाणपत्रको विषय। match identity remote address 198.51.100.10 255.255.255.255 जस्तो कुराले एउटा पियर पिन गर्छ, र प्रत्येक साइटका लागि राखिएको कुञ्जीसहित authentication remote pre-share पर्याप्त छ। पियर सूचीले अनुमति दिएजति मिलान विशिष्ट राख्नुहोस्, किनकि छनोट क्रममा माथि रहेको ओभरल्याप हुने वाइल्डकार्डले शाखाको ट्राफिक गलत प्रोफाइलमा तान्न सक्छ।
घुम्ने प्रोफाइलले ठेगाना पिन गर्न सक्दैन, त्यसैले यो समूह, key-id वा प्रमाणपत्रको कुनै क्षेत्रसँग मिल्छ, अनि साँचो प्रयोगकर्ता जाँच AAA लाई वा प्रोफाइलसँग जोडिएको अधिकार नीतिलाई सुम्पन्छ। यो बाँडफाँट महत्त्वपूर्ण छ: पियर प्रमाणीकरणले क्लाइन्टलाई टनेल बनाउन अनुमति छ कि भन्ने जवाफ दिन्छ, र प्रयोगकर्ता-पिच्छे अधिकारले उसले कुन पूल र कुन स्रोत पाउँछ भन्ने जवाफ दिन्छ। शाखाको कुञ्जीलाई सार्वभौमिक लगइन बनाउँदा दोस्रो जवाफ फालिन्छ।
फर्वार्डिङ र अनुवादलाई पनि त्यही बाँडफाँट चाहिन्छ
प्रवेँश र पहुँच फरक समस्या हुन्। सफल IKE र IPsec आदानप्रदानले दुवै पक्ष कुञ्जीमा सहमत छन् भनी प्रमाणित गर्छ; यसले क्लाइन्टले पाएको पूलसम्म मार्ग बनाउँदैन। त्यसैले रिमोट-पहुँच पूललाई फर्किने बाटो चाहिन्छ: टनेल इन्टरफेसतर्फ देखाउने स्थिर मार्ग वा पूलको सारांश भित्र्याउने राउटिङ प्रोटोकल। शाखाका प्रिफिक्स सामान्यतया साइटको बाँकी भागलाई सेवा दिने त्यही राउटिङ प्रक्रियाबाट आउँछन्।
अनुवाद त्यो ठाउँ हो जहाँ दुई भूमिका सबैभन्दा धेरै ठोकिन्छन्। आफ्ना निजी ठेगाना राख्नुपर्ने साइट-टु-साइट ट्राफिकलाई ती दुई प्रिफिक्समा सीमित NAT छुट चाहिन्छ, दुवै दिशामा। घुम्ने क्लाइन्टलाई सामान्यतया टनेलभित्रको ट्राफिकका लागि पनि छुट चाहिन्छ, तर तिनको इन्टरनेटतर्फको ट्राफिक या त स्प्लिट टनेलबाट टनेल छल्छ या NAT पछि हबमा निस्कन्छ। टनेलबाट आउने सबैलाई छुट दिनु सधैंको गल्ती हो, किनकि यसले साँच्चै आवश्यक ट्राफिकबाट पनि अनुवाद खोस्छ।
छुटका नियम प्रवेशका नियमजत्तिकै साँघुरो राख्नुहोस्। पूलको सारांश र शाखाको प्रिफिक्स ओभरल्याप भए, कुनै प्याकेट नहालिएअघि नै फर्किने बाटो अस्पष्ट हुन्छ, र लक्षण सफा टनेल विफलता नभई एउटा साइट कहिलेकाहीँ सबनेट गुमाउने रूपमा देखिन्छ।
क्रस भएको नीति उदाङ्ग पार्ने स्वीकृति केसहरू
चार केस बनाउनुहोस् र क्रममा चलाउनुहोस्। शाखाको होस्ट शाखा-मात्र स्रोतसम्म पुग्छ। घुम्ने क्लाइन्ट आफ्नो पूलको ठेगानाबाट त्यही स्रोतसम्म पुग्छ। घुम्ने क्लाइन्टले छुनै नहुने शाखा-प्रिफिक्स प्रयास गर्छ। शाखाको पियरले रिमोट-पहुँच पूलबाट ठेगाना लिन खोज्छ। अन्तिम दुईले मात्र साझा प्रोफाइल समात्छन्, किनकि सामान्य निगरानीमा ती चुपचाप असफल हुन्छन्।
त्यसपछि कन्फिगरेसन नभई डेटा प्लेन पुष्टि गर्नुहोस्। show crypto ikev2 sa र show crypto ipsec sa ले कुन प्रोफाइल र कुन सिलेक्टरले प्रत्येक प्रवाह बोके भन्छन्, जबकि show ip nat translations र टनेल काउन्टरले फर्किने बाटो र छुट साँच्चै मिले कि भनी देखाउँछन्। टनेल इन्टरफेसमा tracer वा प्याकेट क्याप्चरले चक्र बन्द गर्छ।
प्रत्येक नतिजाको छेउमा देखिएको पहिचान, पूलको ठेगाना र छानिएको नीति लेख्नुहोस्। प्रत्येक केस ठ्याक्कै एउटा अभिलेखसँग मिले र कुनै पनि केसलाई उत्तीर्ण हुन अस्थायी छुट नचाहिएपछि दौड पूरा हुन्छ।