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 बदलानंतर प्रवाह पुन्हा चालवा, कारण नियमाचा मजकूर न बदलल्यासही नियमांचा क्रम संरचनेचा भाग असतो. उभा राहणारा बोगदा पत्ते टिकले हे सिद्ध करत नाही; फक्त कॅप्चर केलेले पॅकेट आणि समोरच्या बाजूचे डीकॅप्स्युलेशननंतरचे दृश्य सिद्ध करते.