कसैले सोध्छ कि शाखाको VPN सबनेटमा ASA मा «सुरक्षा स्तर 0 वा 100» छ कि छैन, र प्रश्नमा पहिले नै गल्ती छ। सुरक्षा स्तर स्थानीय इन्टरफेसको गुण हो र इन्टरफेस कन्फिगरेसनमा 0 देखि 100 सम्म दिइन्छ। सुरुङबाट आउने टाढाको सबनेटले कुनै स्तर पाउँदैन, crypto map जसरी लेखिएको भए पनि। त्यसैले प्रश्नको कुनै संख्यात्मक उत्तर छैन।

व्यावहारिक अर्को प्रश्न राम्रो छ: कुन नीतिले शाखालाई सर्भरसम्म जान दिन्छ र कुनले उसलाई फायरवालबाटै टाढा राख्छ। ती दुई उत्तर हुन्, र तलको प्रक्रियाले तिनलाई अलग गर्छ।

सुरक्षा स्तरहरू इन्टरफेसका हुन्

show running-config interface चलाउनुहोस् र तपाईंले हरेक भौतिक इन्टरफेस वा VLAN इन्टरफेसको तल security-level देख्नुहुनेछ, सुरुङ समूह वा crypto map को तल होइन। उच्चबाट निचलोतर्फको पूर्वनिर्धारित अनुमति ती इन्टरफेसबीच मूल्याङ्कन गरिन्छ, त्यसैले संख्याले आफ्नो पथमा निरीक्षण र निहित ACL को व्यवहार बदल्छ।

डिक्रिप्ट गरिएको VPN प्रवाहका लागि प्रवेश अझै outside इन्टरफेस हो जहाँ सुरुङ अन्त्य हुन्छ, र निकास सर्भरतर्फको inside इन्टरफेस हो। केही पनि छुनुअघि दुवै लेख्नुहोस्। त्यो एउटा कदमले धेरैजसो अन्योल हटाउँछ, किनकि यसले अमूर्त विश्वासको प्रश्नलाई इन्टरफेस जोडीमा बदल्छ।

ACL बाइपासको एउटा नाम भएको सीमा छ

sysopt connection permit-vpn त्यो सेटिङ हो जुन मानिसहरू आधा सम्झन्छन् जब तिनीहरू भन्छन् कि VPN ट्राफिकले ACL लाई बेवास्ता गर्छ। यसले VPN ट्राफिकका रूपमा योग्य ट्राफिकका लागि इन्टरफेस ACL छोड्छ, र 9.x प्यारामिटर गाइडले यसलाई विश्वव्यापी अपवाद घोषणा गर्नुको सट्टा इन्टरफेस र दिशाअनुसार सीमित गर्छ।

स्मृतिबाट तर्क गर्नुअघि के कन्फिगर छ जाँच्नुहोस्:

  • show running-config all sysopt वास्तविक मान हेर्न, पूर्वनिर्धारित नभएका लाइन मात्र होइन।
  • show running-config access-group कुन ACL कुन इन्टरफेस र दिशामा लागू छ हेर्न।
  • show vpn-sessiondb detail l2l सत्रले वास्तवमै कुन सुरुङ समूह र फिल्टर प्रयोग गर्छ पुष्टि गर्न।

VPN पहुँच कडा बनाउन त्यो सेटिङ बन्द गर्नु ठूलो प्रभावको परिवर्तन हो। यसले हरेक योग्य VPN प्रवाहलाई फेरि बाह्य ACL को अधीनमा राख्छ, जसले सामान्यतया चलिरहेका सुरुङहरूलाई तपाईंलाई सोधिएको शाखासँग सम्बन्ध नभएको तरिकाले तोड्छ।

सत्रसँग जोडिएको फिल्टर पढ्नुहोस्

प्रत्येक सुरुङको वास्तविक नियन्त्रण VPN फिल्टर हो: समूह नीति वा प्रयोगकर्ता नामले सन्दर्भ गर्ने ACL, डिक्रिप्शनपछि र इन्क्रिप्शनअघि लागू हुन्छ। प्रयोगकर्ता-स्तरको फिल्टरले समूह-स्तरको मान बदल्छ, त्यसैले एउटै सुरुङ समूहका दुई जनाको प्रभावकारी पहुँच फरक हुन सक्छ।

प्राथमिकता गृहण नगरी पुष्टि गर्नुहोस्। show running-config group-policy <name> समूहको मान देखाउँछ, र show running-config username <name> प्रति-प्रयोगकर्ता मान छ कि छैन देखाउँछ। दुवै भए प्रयोगकर्ताको मान जित्छ। त्यसपछि त्यो ACL का प्रविष्टिहरू तपाईंलाई महत्त्वपूर्ण प्रवाहसँग, फिल्टरले मूल्याङ्कन गर्ने दिशामा तुलना गर्नुहोस्।

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

एउटा अनुमति र एउटा अस्वीकृति प्रमाणित गर्नुहोस्

प्रयोगकर्ताले रिपोर्ट गर्ने प्रतीक्षा नगरी निर्णय हेर्ने सबैभन्दा छिटो तरिका Packet-tracer हो। यसलाई डिक्रिप्ट पक्षको प्रवाह दिनुहोस् र यसले पार गर्ने ACL, NAT र निरीक्षण चरणहरूको नाम बताउन दिनुहोस्।

  1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
  2. नतिजाको लाइन पढ्नुहोस्: यसले प्याकेटलाई अनुमति दिने वा खसाल्ने ACL को नाम बताउँछ।
  3. inside इन्टरफेसमा प्रशासनिक गन्तव्यसँग दोहोर्याउनुहोस् र अस्वीकृतिको पुष्टि गर्नुहोस्।
  4. कुनै पनि परिवर्तनपछि अझै एकचोटि दोहोर्याउनुहोस्, ताकि अघिल्लो र पछिल्लो दुवै अवस्था अभिलेख गरियोस्।

त्यसपछि वास्तविक ट्राफिकसँग प्रमाणित गर्नुहोस्: शाखाबाट एउटा सफल अनुप्रयोग अनुरोध र ASA तर्फ एउटा असफल SSH प्रयास। Packet-tracer पथको नमुना बनाउँछ; जीवित प्रवाहले नमुना मिलेको प्रमाणित गर्छ।

यसलाई चलाउने परिवर्तन फर्काउनुहोस्

यदि समाधान ACL बाइपास बन्द गर्नु वा फिल्टर फराकिलो बनाउनु थियो भने अघिल्लो कन्फिगरेसन राख्नुहोस्। परिवर्तनअघि सुरक्षित प्रभावित वस्तुहरूको show run क्याप्चर तिनलाई पुनर्स्थापित गर्न पर्याप्त छ; ASA कन्फिगरेसन लाइन-केन्द्रित छ, त्यसैले फर्काउनु भनेको पुराना लाइनहरू फेरि प्रविष्ट गर्नु हो, फाइल पुनर्स्थापित गर्नु होइन।

इन्टरफेस जोडी, प्रभावकारी फिल्टर, packet-tracer बाट ACL को नाम र तपाईंले बदलेका ठ्याक्कै आदेशहरू अभिलेख गर्नुहोस्। त्यो अभिलेखले अर्को समीक्षालाई विश्वास स्तरबारे अर्को बहसको सट्टा पाँच मिनेटको जाँच बनाउँछ।

सम्बन्धित लेखहरू