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 परिवर्तनपछि प्रवाह फेरि चलाउनुहोस्, किनकि नियमको पाठ नबदले पनि नियमहरूको क्रम कन्फिगरेसनको भाग हो। उठ्ने सुरुङ ठेगाना बाँचेको प्रमाण होइन; क्याप्चर गरिएको प्याकेट र विपक्षीको डिक्याप्सुलेसनपछिको दृष्टि मात्र प्रमाण हो।