Cisco ASA ते Azure VPN: ट्रॅफिक सिलेक्टर प्रीफिक्स जोड्या
ASA ते Azure VPN कनेक्शन करार म्हणून लिहा: कनेक्शन मॉडेल, अचूक प्रीफिक्स जोड्या, सिलेक्टर पडताळणी आणि नंतर रोलबॅक. रिलीजशी जुळणारे रनबुक.
टनेल वर येते, IKE निरोगी दिसते, पण त्यातून काहीही जात नाही. ASA ते Azure सिलेक्टर समस्येचा हा नेहमीचा आकार आहे, आणि म्हणूनच कोणतेही कन्सोल हाताळण्यापूर्वी मी करार लिहितो. करार चार गोष्टींचा आहे: प्रत्येक पीअर ओळखणारे ऑब्जेक्ट, कनेक्शन मॉडेल, अचूक प्रीफिक्स जोड्या आणि प्रत्येक जोडी सिद्ध करणारी पडताळणी. या चुका केल्या तर पुढील प्रत्येक कमांड अशा कॉन्फिगरेशनचे डीबग करेल जे तुम्ही बांधायला नको होते. हे रनबुक मी वापरतो तो क्रम आहे, कोणते ऑब्जेक्ट खरोखर चुकीचे आहे हे दाखवणाऱ्या कमांडसह.
कॉन्फिगर करण्यापूर्वी चार ऑब्जेक्ट लिहून ठेवा
ASA रिलीज आणि प्लॅटफॉर्म, सार्वजनिक एंडपॉइंट, Azure VPN गेटवेचा प्रकार आणि SKU, आणि तुमची बाजू दर्शवणारा स्थानिक नेटवर्क गेटवे यापासून सुरुवात करा. ही चार नावे पुढील सर्व गोष्टींची शब्दसंग्रह आहेत, आणि काही बिघडल्यावर प्रत्येकाचा वेगळा जबाबदार असतो.
त्यांपैकी दोन अजून गृहीतके असतील तर थांबा. स्थानिक नेटवर्क गेटवेवरील चुकीची प्रीफिक्स यादी ही ट्युनिंगची समस्या नाही.
एक कनेक्शन मॉडेल निवडा आणि टेम्पलेट मिसळणे थांबवा
crypto map रचना आणि tunnel interface रचना या वेगळ्या कॉन्फिगरेशन आहेत, आणि एकाचे टेम्पलेट पीअरचा पत्ता बदलून दुसऱ्यासाठी वैध होत नाही. काहीही पेस्ट करण्यापूर्वी तुम्ही कोणते बांधत आहात ते नोंदवा, कारण विसंगती नंतर कॉन्फिगरेशन त्रुटी म्हणून नाही तर सिलेक्टर समस्या म्हणून दिसते. Microsoft चे ASA आंतरकार्यक्षमता मार्गदर्शक दोन्ही नमुने समाविष्ट करते आणि प्रत्येक कोणते Azure गेटवे मॉडेल गृहीत धरते ते सांगते. तुमच्या नोंदींमध्ये मॉडेलचे नाव नसेल तर अजून रचना नाही.
धोरण-आधारित ट्रॅफिक सिलेक्टरसह मार्ग-आधारित Azure गेटवे हा विशिष्ट दस्तऐवजीकृत पर्याय आहे, डीफॉल्ट नाही. तुमची रचना त्यावर अवलंबून असेल तर रचनेने ते सांगितले पाहिजे, कारण डीफॉल्ट मार्ग-आधारित सिलेक्टर मॉडेल Azure बाजूला वेगळे वागते.
आवृत्ती मर्यादाही करारात असतात. एन्क्रिप्शन डोमेनच्या मर्यादेबद्दलचा जुना क्षेत्र अहवाल विशिष्ट रिलीजबद्दलचा माहितीबिंदू आहे, प्रत्येक ASA चा कायमस्वरूपी गुणधर्म नाही.
एकत्रित नाही, प्रीफिक्स जोड्या मोजा
मॅट्रिक्स लिहा. स्थानिक A आणि B ते Azure X आणि Y या चार जोड्या आहेत, आणि प्रत्येकाला व्याप्ती किंवा स्पष्ट वगळणी आवश्यक आहे. A आणि B एका एकत्रितात जोडल्यास त्यांच्यामधलेही समाविष्ट होते, आणि अशा प्रकारे रचना शांतपणे भोक वाढवते.
तुम्ही जतन केलेले नाही, तर पीअरने जे वाटाघाटी केले ते तपासा. ASA वरील स्थानिक आणि दूरस्थ नेटवर्क यादी हेतू आहे; CHILD SA निकाल आहेत.
जोडी नसल्यास दुरुस्ती सहसा access-list ओळ किंवा सिलेक्टर नोंद असते, नवीन टनेल नाही.
ऑब्जेक्टचे नाव घेणाऱ्या कमांडने पडताळा
ASA वर IKE सत्र, नंतर IPsec SA, नंतर सिलेक्टर जोड्या निश्चित करा. प्रत्येक कमांड वेगळ्या प्रश्नाचे उत्तर देते, आणि फक्त पहिली चालवणे म्हणजे «टनेल वर आहे» हे खोटे निष्कर्ष बनते. यादीत पहिला येणारा SA नाही, तर तुम्ही खरोखर कॉन्फिगर केलेल्या पीअरचे आउटपुट वाचा. Azure बाजूही त्याच तीन प्रश्नांची स्वतःच्या दृष्टिकोनातून उत्तर देते.
show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed
नंतर az network vpn-connection show --name <connection> --query connectionStatus ने Azure ला कनेक्शन स्थिती विचारा. डेटा मार्गात शून्य बाइटसह «कनेक्टेड» ही राउटिंग समस्या नाही, सिलेक्टर समस्या आहे.
प्रत्येक जोडीसाठी एक परवानगी असलेला प्रवाह तपासा, दुसऱ्या बाजूला दिसणारा स्रोत पत्ता पाहा, आणि नाकारला जावा अशी एक संसाधन तपासा. तो शेवटचा चाचणीच सीमा अजून आहे हे सिद्ध करते.
एन्क्रिप्शन व्याप्ती प्रवेश परवानगीपासून वेगळी ठेवा
रुंद सिलेक्टर म्हणजे परवानगी नाही. समर्थित मांडणी अनुप्रयोग धोरणापेक्षा रुंद असेल तर अरुंद सेवा firewall नियमांमध्ये ठेवा आणि एन्क्रिप्शन व्याप्ती जिथे असावी तिथे ठेवा.
Azure कार्यभार मार्ग आणि स्थानिक परतीचे मार्ग स्वतंत्रपणे तपासले जातात. BGP जाहिराती, स्थिर नेटवर्क व्याप्ती आणि वापरकर्ता-परिभाषित मार्ग यांनी एकच मार्ग वर्णन केला पाहिजे, आणि त्यांपैकी कोणीही पीअर वाहतूक वारंवार पकडू नये.
रोलबॅक आणि ते चालले याचा पुरावा
सिलेक्टर बदलण्यापूर्वी मागील चालू कॉन्फिगरेशन ठेवा आणि ते परत आणणारी एक कमांड जाणा. ASA वर याचा अर्थ जतन केलेली प्रत आणि त्याशी जुळणारा पुनर्संचयित मार्ग, तुम्ही काय संपादित केले याची आठवण नाही. बदल अजून काल्पनिक असतानाच पुनर्संचयित कमांड बदल तिकिटात लिहा. नंतर तेच तीन तपासण्या पुन्हा चालवा: IKE स्थिती, IPsec SA जोड्या, प्रत्येक जोडीसाठी एक परवानगी असलेला प्रवाह.
पुनर्संचयितीनंतरही जोडी अयशस्वी झाली तर बदल कारण नव्हता, आणि तुम्ही दुसरा व्यत्यय टाळला.