ASA hairpin: इंटरनेट एग्ज़िट या साइट-टू-साइट VPN लेग?

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

दो लेग, एक इंटरफ़ेस

NAT नियम लिखने से पहले तय करें कि आप कौन सा लेग बना रहे हैं, क्योंकि नियम आपस में बदले नहीं जा सकते। लेग A क्लाइंट से इंटरनेट है: पूल का पता अंदर, अनुवादित सार्वजनिक पता बाहर, उसी इंटरफ़ेस से वापस। लेग B क्लाइंट से दूसरे IPsec पीयर के दूसरी ओर के निजी प्रीफ़िक्स तक है: पूल का पता सुरक्षित रहता है, फिर से एन्क्रिप्ट होता है और ऐसे पीयर तक पहुँचाया जाता है जिसे पूल को जवाब देना आना चाहिए।

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

same-security-traffic permit intra-interface

वह एक पंक्ति फ़ॉरवर्डिंग व्यवस्था की अनुमति देती है, जैसा कि ASA NAT संदर्भ एक ही इंटरफ़ेस के पथों के लिए बताता है। यह कोई क्लाइंट रूट नहीं जोड़ती, किसी संसाधन को अधिकृत नहीं करती, कोई पता अनुवादित नहीं करती और IPsec सिलेक्टर पर बातचीत नहीं करती, इसलिए इसके बाद और तीन या चार चीज़ें जोड़ने की अपेक्षा रखें और इसकी स्वीकृति को प्रगति मत पढ़ें।

लेग A: क्लाइंट को इंटरनेट चाहिए

इंटरनेट एग्ज़िट के लिए पैकेट के डिवाइस छोड़ने से पहले पूल के पते को निजी होना बंद करना होगा। सामान्य PAT डिज़ाइन में नियम पूल को आउटसाइड इंटरफ़ेस के पते में अनुवादित करता है, और वापसी स्थिति क्लाइंट की ओर का प्रवाह बहाल करती है:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

फिर पुष्टि करें कि क्लाइंट ने वास्तव में ASA से वह ट्रैफ़िक ढोने को कहा। स्प्लिट-टनल अपवाद सार्वजनिक गंतव्य को फ़ोन के अपने कनेक्शन से भेजता है, जो ASA तक कभी नहीं पहुँचता, और कभी न भेजे गए पैकेट को कोई NAT नियम ठीक नहीं करता। ग्रुप नीति की स्प्लिट-टनल सूची की तुलना उस गंतव्य से करें जिसे आप जाँच रहे हैं।

लेग का बाकी हिस्सा सामान्य है: आउटसाइड इंटरफ़ेस से उपयोगी डिफ़ॉल्ट या विशिष्ट रूट, प्रवाह की अनुमति देने वाली एक्सेस नीति, और आपके चुने रिज़ॉल्वर नीति के अनुसार संभाला गया DNS। यहाँ route-lookup नीचे के समान कारण से जोड़ें, क्योंकि प्रवेश और निर्गम इंटरफ़ेस एक जैसे हैं।

लेग B: क्लाइंट को निजी साइट चाहिए

यह लेग अधिक जगहों पर विफल होता है, इसलिए इसे क्रम में लिखें। पहले क्लाइंट रूट: गंतव्य प्रीफ़िक्स स्प्लिट-टनल सूची में होना चाहिए, नहीं तो क्लाइंट उसे टनल में नहीं रखेगा। दूसरे टनल सिलेक्टर: साइट-टू-साइट क्रिप्टो ACL को पूल पते से दूरस्थ प्रीफ़िक्स तक कवर करना चाहिए, केवल स्थानीय LAN से दूरस्थ प्रीफ़िक्स तक नहीं। तीसरे पहचान, ताकि पूल का पता रास्ते में इंटरनेट PAT में अनुवादित न हो जाए।

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

दूर वाला पक्ष वह हिस्सा है जिसे लोग जाँचना भूल जाते हैं। पीयर को पूल तक वापसी रूट और उसे शामिल करने वाला सिलेक्टर चाहिए, और उसकी अपनी नीति को वे स्रोत पते अनुमत करने चाहिए जो वह देखेगा. अगर साइट को इसके बजाय अनुवादित दृश्य से उपयोग किया जाता है, तो वह वैध डिज़ाइन है, पर तब दोनों पीयर, दोनों सिलेक्टर और दोनों रूटिंग टेबल को अनुवादित पतों पर सहमत होना होगा।

नियमों का क्रम भी जाँचें। पहचान नियम के ऊपर एक व्यापक PAT नियम निजी अदला-बदली का अनुवाद पहचान नियम के मूल्यांकन से पहले ही कर देगा, और लक्षण NAT त्रुटि नहीं बल्कि मेल खाते SA के बिना साइट टनल है।

वह परीक्षण जो बताता है कि आपने कौन सा लेग बनाया

कॉन्फ़िगरेशन पढ़कर उम्मीद करने के बजाय ASA के अपने पथ मूल्यांकन का उपयोग करें। packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed एक प्रवाह के लिए NAT निर्णय, रूट और ACL परिणाम दिखाता है; निजी गंतव्य के साथ इसे दोहराएँ। अगर NAT चरण निजी-से-निजी प्रवाह को फिर से लिखता है, तो आपने ऐसे पैकेट के लिए लेग A बनाया जिसे लेग B चाहिए था।

दो और कमांड अंतराल बंद करते हैं। show nat detail packet-tracer ने जो नियम क्रम अपनाया उसे छापता है, और show crypto ipsec sa दिखाता है कि जिस जोड़ी की आप अपेक्षा कर रहे हैं उसके लिए सिलेक्टर मौजूद है या नहीं। गायब SA सिलेक्टर या पीयर कॉन्फ़िगरेशन का मामला है, ऐसी चीज़ नहीं जिसे NAT नियम ठीक कर सके।

हर लेग को उस ट्रैफ़िक से सत्यापित करें जिसकी वह सेवा करता है

लेग A को क्लाइंट की सामान्य सार्वजनिक माँग से स्वीकार करें, और लेग B को ऐसे निजी संसाधन की माँग से जो वास्तव में मौजूद है। फिर हर एक को अस्वीकृत संसाधन के साथ दोहराएँ, क्योंकि “अनुमत” और “एक्सेस नीति द्वारा स्वीकृत” एक ही साक्ष्य नहीं हैं, और हब से उठने वाला ping क्लाइंट पथों में से किसी को भी नहीं परखता।

टिकट में दोनों परीक्षण रिकॉर्ड अलग रखें: स्रोत पता, गंतव्य, मेल खाया NAT नियम और परिणाम। जब अगली रिपोर्ट कहे “VPN टूट गया है”, तो वह जोड़ी एक मिनट में बता देगी कि कौन सा लेग पीछे गया, और जवाब आम तौर पर रूट या सिलेक्टर होता है, वह उसी-इंटरफ़ेस लाइन नहीं जिस पर सबसे पहले सबको संदेह होता है।