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

फराकिलो बाइपासपछि उपयोगी हुने टनेलले प्रतिबन्ध हटाइयो भन्छ, पूरा भयो भन्ने होइन। राख्न लायक नतिजा भनेको अर्को समीक्षामा देखाउन सकिने नामित प्रवर्तन बिन्दु हो।