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

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