VPN ट्रैफ़िक के लिए ASA identity NAT बनाम IOS NAT अपवाद

एक शाखा एक ही Cisco गेटवे पर इंटरनेट PAT और साइट-टू-साइट VPN रखती है, और NAT जोड़ते ही VPN काम करना बंद कर देता है। टनल के अंदर के पते अब उससे मेल नहीं खाते जिसे crypto ACL सुरक्षित रखता है, या सामने वाला पक्ष ऐसे अनुवादित पते देखता है जिनके लिए उसके पास कोई रूट नहीं है। Cisco इसे दो जगहों पर हल करता है: ASA ऐसा NAT नियम चुनता है जो पते को उसी पर मैप करता है, जबकि IOS एक ACL deny के ज़रिए फ़्लो को अनुवाद नियम से बाहर रखता है। दोनों मूल पते बनाए रखते हैं, और कोई भी NAT प्रोसेसिंग को बायपास नहीं करता।

नियम चुनने से पहले फ़्लो दर्ज करें

आप जिस फ़्लो को सुरक्षित करना चाहते हैं उसे लिखकर शुरू करें: स्थानीय LAN स्रोत, दूरस्थ गंतव्य और वह सटीक पता जोड़ी जिसे IPsec नीति सुरक्षित रखती है। नियम संपादित करने से पहले ऐसा करें, क्योंकि यह ट्यूपल बताता है कि किस क्लासिफ़ायर या NAT नियम को मेल खाना चाहिए था।

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

ASA identity NAT एक नियम है, बायपास नहीं

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

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

नियम के इंटरफ़ेस और उसकी route-lookup सेटिंग फ़ॉरवर्डिंग डिज़ाइन से मेल खानी चाहिए। जो नियम पते को सही मैप करता है पर गलत इंटरफ़ेस जोड़ी पर लागू होता है वह आपके फ़्लो के लिए नहीं चुना जाएगा। Route-lookup तय करता है कि अनुवादित पैकेट रूट होगा या मूल गंतव्य प्रयोग होगा, और यही तय करता है कि वापसी ट्रैफ़िक टनल से लौटेगा या नहीं।

ASA तक प्रबंधन पहुँच एक अलग मामला है। यदि आप प्रबंधन ट्रैफ़िक के लिए identity NAT उपयोग करते हैं तो रिलीज़-विशिष्ट route-lookup शर्त लागू होती है, और VPN उदाहरण से कॉपी किया गया व्यापक अपवाद SSH ठीक नहीं करेगा।

IOS NAT ACL में deny का अर्थ है यहाँ चुना नहीं गया

IOS पर इंटरनेट NAT स्रोत सूची से चलता है, और वह ACL फ़िल्टर नहीं, क्लासिफ़ायर है। Permit पंक्ति अनुवाद के लिए ट्रैफ़िक चुनती है; deny पंक्ति का अर्थ है पैकेट यहाँ नहीं चुना गया। वह deny इंटरफ़ेस ACL के deny की तरह पैकेट गिराने का आदेश नहीं है।

यहाँ चुना नहीं गया, कहीं भी अनुवाद न होने से भी संकरा है। दूसरा NAT नियम, दूसरा इंटरफ़ेस या route-map अब भी फ़्लो का अनुवाद कर सकते हैं, इसलिए पूरी NAT तालिका पढ़नी होगी। पैकेट को अब भी रूट, मेल खाता crypto ACL और वास्तविक एक्सेस-कंट्रोल सीमाओं पर अनुमति चाहिए।

न्यूनतम IOS व्यवस्था deny को उसी सूची में permit के ऊपर रखती है और overload नियम को उसी सूची की ओर इंगित करती है। तब crypto ACL उसी जोड़ी को सुरक्षित रखता है जिसे deny अनुवाद से बाहर रखता है।

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

दोनों मॉडलों के लिए एक परखने योग्य प्रश्न

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

ASA पर nat detail और अनुवाद तालिका दिखाएँ; IOS पर ip nat translations और संबंधित ACL काउंटर दिखाएँ। जो नियम कभी नहीं बढ़ता वह कभी चुना ही नहीं गया, और यह crypto कॉन्फ़िगरेशन नहीं बल्कि क्रम, इंटरफ़ेस या दिशा की ओर संकेत करता है।

कॉन्फ़िगरेशन आमतौर पर कहाँ गड़बड़ाता है

सामान्य विफलताएँ यांत्रिक हैं। deny permit के नीचे बैठता है और कभी मेल नहीं खाता। क्लासिफ़ायर गलत दिशा में लागू होता है, इसलिए वापसी फ़्लो अनुवादित हो जाता है। identity नियम सही पते पर गलत इंटरफ़ेस जोड़ी कवर करता है। crypto ACL ऐसी सबनेट सुरक्षित रखता है जो अब NAT नियम के प्रस्तुत के साथ मेल नहीं खाती।

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