एकच 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 किंवा पॅकेट कॅप्चर वर्तुळ बंद करते।

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