VPN द्वारा डिक्रिप्ट करने के बाद कौन-सा ASA नियम ट्रैफ़िक देखता है

पहली धारणा जिसे छोड़ना चाहिए वह यह है कि क्रिप्टो ACL एक एक्सेस नीति है। ऐसा नहीं है। Cisco ASA पर वह सूची एक संकीर्ण प्रश्न का उत्तर देती है: कौन-से पैकेट सुरक्षा के योग्य हैं, और वह उत्तर इस बात पर कुछ नहीं कहता कि डिक्रिप्ट किया गया पैकेट फ़ायरवॉल के पीछे के सर्वर तक पहुँच सकता है या नहीं। एक्सेस का निर्णय बाद में होता है — इंटरफ़ेस नीति, ग्रुप-पॉलिसी फ़िल्टर, या दोनों से, इस पर निर्भर करते हुए कि टनल कैसे बनी।

क्रिप्टो ACL किसी दूसरे प्रश्न का उत्तर देता है

क्रिप्टो ACL एक मिलान सूची है। यह टनल को बताती है कि दो पीयर के बीच क्या एन्क्रिप्ट करना है; जो पैकेट इससे मेल नहीं खाता वह बस सुरक्षित नहीं होता। इसे चौड़ा करने से सुरक्षा का दायरा बदलता है और कुछ नहीं।

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

बायपास सेटिंग वास्तव में क्या छोड़ देती है

sysopt connection permit-vpn संरक्षित ट्रैफ़िक को इंटरफ़ेस ACL जाँच छोड़ने देता है जो अन्यथा इनबाउंड ओर लागू होती। यह VPN परिनियोजन के लिए सुविधा है, और यह वैश्विक है। यह ग्रुप पॉलिसी को नहीं छूता और प्रति-उपयोगकर्ता प्राधिकरण फ़िल्टर को भी नहीं छूता।

धारणा के बजाय वास्तविक मान पढ़ें: show running-config all sysopt सेटिंग तब भी छापता है जब इसे कभी स्पष्ट रूप से कॉन्फ़िगर नहीं किया गया, और बहुत भ्रम वहीं से शुरू होता है।

चूँकि सेटिंग वैश्विक है, इसे एक विफल सबनेट पर त्वरित प्रयोग के रूप में जाँचना बुरा सौदा है। उस फ़ायरवॉल की हर दूसरी टनल परिणाम साझा करती है। इसे रोलबैक योजना वाले जानबूझकर बदलाव के लिए रखें।

डिक्रिप्ट दिशा में फ़िल्टर पढ़ें

LAN-to-LAN vpn-filter टनल के दृष्टिकोण से लिखा जाता है, इंटरफ़ेस के नहीं। दूरस्थ नेटवर्क स्रोत की स्थिति में जाता है और स्थानीय नेटवर्क गंतव्य की स्थिति में, क्योंकि डिक्रिप्ट के बाद पैकेट ऐसा ही दिखता है। फिर वही फ़िल्टर एन्क्रिप्शन से पहले विपरीत दिशा में फिर से मूल्यांकित होता है, पते की भूमिकाएँ उलटी होकर।

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

पुष्टि करें कि वास्तव में कौन-सा फ़िल्टर जुड़ा है: show running-config group-policy और show vpn-sessiondb detail l2l मिलकर बताते हैं कि सत्र को क्या विरासत में मिला। जिस ACL का कोई नीति संदर्भ नहीं देती, उसे संपादित करने से कुछ नहीं बदलता।

एक ACL ऑब्जेक्ट का दो कामों के लिए पुनः उपयोग न करें

इंटरफ़ेस का access-group और vpn-filter एक ही प्रकार के ऑब्जेक्ट जैसे लगते हैं और अलग-अलग बिंदुओं पर अलग पता-दिशा के साथ मूल्यांकित होते हैं। एक सूची दोनों को सौंपने से ऐसा बदलाव आमंत्रित होता है जो टनल ठीक करता है और भौतिक इंटरफ़ेस को चुपचाप ढीला करता है।

इन्हें अलग रखें, उनके काम के अनुसार नाम दें, और दिशा का अंतर नामों में दिखने दें।

नए कनेक्शन से, दोनों दिशाओं में सत्यापित करें

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

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

विस्तृत बायपास के बाद उपयोगी होने वाली टनल बताती है कि प्रतिबंध हटा दिया गया, यह नहीं कि उसे पूरा किया गया। जो परिणाम रखने योग्य है वह एक नामित प्रवर्तन बिंदु है जिसे आप अगली समीक्षा में दिखा सकते हैं।