Cisco ASA से Azure VPN: ट्रैफ़िक चयनकर्ता प्रीफ़िक्स जोड़े

टनल ऊपर आ जाती है, IKE स्वस्थ दिखता है, और उससे होकर कुछ नहीं गुज़रता। ASA से Azure चयनकर्ता समस्या का यही सामान्य स्वरूप है, और इसीलिए मैं दोनों में से किसी भी कंसोल को छूने से पहले अनुबंध लिखता हूँ। अनुबंध चार चीज़ें हैं: हर सहकर्मी की पहचान करने वाली वस्तुएँ, कनेक्शन मॉडल, सटीक प्रीफ़िक्स जोड़े और वह सत्यापन जो हर जोड़े को सिद्ध करता है। इनमें गलती हुई तो हर आगामी कमांड ऐसी कॉन्फ़िगरेशन को डीबग करेगा जो आपको नहीं बनानी चाहिए थी। यह रनबुक वही क्रम है जो मैं उपयोग करता हूँ, उन कमांडों के साथ जो दिखाते हैं कि कौन-सी वस्तु वास्तव में गलत है।

कॉन्फ़िगर करने से पहले चार वस्तुएँ लिखें

ASA रिलीज़ और प्लेटफ़ॉर्म, सार्वजनिक एंडपॉइंट, Azure VPN गेटवे का प्रकार और SKU, और आपका पक्ष दर्शाने वाला स्थानीय नेटवर्क गेटवे से शुरू करें। ये चार नाम आगे की हर चीज़ की शब्दावली हैं, और कुछ टूटने पर हर एक का मालिक अलग होता है।

अगर इनमें से दो अभी अनुमान हैं, तो रुकें। स्थानीय नेटवर्क गेटवे पर गलत प्रीफ़िक्स सूची कोई ट्यूनिंग समस्या नहीं है।

एक कनेक्शन मॉडल चुनें और टेम्पलेट मिलाना बंद करें

क्रिप्टो-मैप डिज़ाइन और टनल-इंटरफ़ेस डिज़ाइन अलग कॉन्फ़िगरेशन हैं, और एक का टेम्पलेट सहकर्मी का पता बदलकर दूसरे के लिए मान्य नहीं हो जाता। कुछ भी चिपकाने से पहले दर्ज करें कि कौन-सा बना रहे हैं, क्योंकि असंगति बाद में कॉन्फ़िगरेशन त्रुटि के बजाय चयनकर्ता समस्या के रूप में सामने आती है। 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 से कनेक्शन की स्थिति पूछें। डेटा पथ में शून्य बाइट के साथ Connected चयनकर्ता समस्या है, रूटिंग समस्या नहीं।

हर जोड़े के लिए एक अनुमत प्रवाह जाँचें, दूसरी ओर दिखने वाला स्रोत पता देखें, और एक ऐसा संसाधन आज़माएँ जिसे अस्वीकार होना चाहिए। वही अंतिम परीक्षण एकमात्र है जो सिद्ध करता है कि सीमा अभी भी मौजूद है।

एन्क्रिप्शन दायरे को पहुँच अनुमति से अलग रखें

चौड़ा चयनकर्ता अनुमति नहीं है। अगर समर्थित लेआउट एप्लिकेशन नीति से चौड़ा है, तो संकीर्ण सेवाओं को फ़ायरवॉल नियमों में रखें और एन्क्रिप्शन दायरा वहीं रहने दें जहाँ उसे होना चाहिए।

Azure वर्कलोड मार्ग और स्थानीय वापसी मार्ग अलग-अलग समीक्षा किए जाते हैं। BGP घोषणाएँ, स्थिर नेटवर्क दायरा और उपयोगकर्ता-परिभाषित मार्ग सभी को एक ही पथ बताना चाहिए, और इनमें से कोई भी सहकर्मी ट्रांसपोर्ट को पुनरावर्ती रूप से नहीं पकड़ सकता।

रोलबैक और इसका प्रमाण कि उसने काम किया

चयनकर्ता बदलने से पहले पिछली चालू कॉन्फ़िगरेशन रखें, और वह एक कमांड जानें जो उसे वापस लाता है। ASA पर इसका अर्थ है सहेजी गई प्रति और उससे मेल खाता पुनर्स्थापन पथ, न कि आपने क्या संपादित किया इसकी याद। बदलाव के अभी काल्पनिक रहते हुए चेंज टिकट में पुनर्स्थापन कमांड लिखें। फिर वही तीन जाँचें दोबारा चलाएँ: IKE स्थिति, IPsec SA जोड़े, हर जोड़े के लिए एक अनुमत प्रवाह।

अगर पुनर्स्थापन के बाद भी कोई जोड़ा विफल रहता है, तो बदलाव कारण नहीं था, और आपने अभी-अभी खुद को दूसरी रुकावट से बचा लिया।