क्या एक 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 या पैकेट कैप्चर चक्र बंद कर देता है।

हर नतीजे के साथ देखी गई पहचान, पूल का पता और चुनी गई नीति लिखें। दौर तब पूरा होता है जब हर मामला ठीक एक रिकॉर्ड से मेल खाता है, और किसी भी मामले को पास होने के लिए अस्थायी अपवाद की ज़रूरत नहीं पड़ती।