ASA का TACACS+ अनुरोधहरू तपाईंको शाखा VPN टनेल किन छोड्छन्

शाखा टनेल चालु छ, प्रयोगकर्ताहरू टाढाको TACACS+ सर्भरमा प्रमाणीकरण गर्दै छन्, तर फायरवालको आफ्नै लगइन अझै समय सकिएर असफल हुन्छ। कारण टनेलमा दोष होइन: LAN-to-LAN टनेलले यसका सिलेक्टरसँग मिल्ने ट्राफिक मात्र बोक्छ, र ASA ले आफ्नै बारेमा उत्पन्न गर्ने व्यवस्थापन ट्राफिक आफ्नै स्रोत ठेगाना भएको छुट्टै प्रवाह हो। अधिकांश टोलीहरूले यो परिवर्तन विन्डोको क्रममा पत्ता लगाउँछन्, जब एकमात्र प्रशासक खाता नै असफल हुँदै हुन्छ। ASA ले सुरु गर्ने AAA सत्रलाई तपाईंले डिजाइन गर्नुपर्ने प्रवाह मान्नुहोस्, पहिले नै काम गरिरहेको जडानको साइड इफेक्ट मान्नुहोस्।

ASA नै क्लाइन्ट हो, र यसको आफ्नै ट्राफिकलाई आफ्नै मार्ग चाहिन्छ

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

सर्भरले देख्ने भनी तपाईंले अपेक्षा गर्नुभएको ठेगाना लेख्नुहोस्। यदि एक हरफमा भन्न सक्नुहुन्न भने, तपाईंसँग अझै डिजाइन छैन।

aaa-server हरफको इन्टरफेस सजावट होइन

ASA मा aaa-server होस्ट प्रविष्टिले कोष्ठकमा इन्टरफेस सम्बन्ध लिन्छ, र Cisco को AAA होस्ट कमाण्ड सन्दर्भ ले यसलाई प्रमाणीकरण सर्भर रहेको इन्टरफेसका रूपमा वर्णन गर्छ। यही सम्बन्धले अनुरोधलाई इन्टरफेससँग र त्यस इन्टरफेसले लागू गर्ने नीतिसँग जोड्छ। इन्टरनेटतर्फ फर्किएको जुनसुकै इन्टरफेसका आधारमा छान्ने, वा अघिल्लो स्थानान्तरणबाट बाँकी रहेको जस्ताको तस्तै राख्ने हो भने, टाढाको सर्भर र टनेल कहिल्यै नबनाइएको स्रोत ठेगाना बन्छ।

inside तब मात्र सही उत्तर हुन्छ जब नाम दिइएको इन्टरफेसमा तपाईंको डिजाइनले स्रोतका रूपमा प्रयोग गर्न खोजेको ठेगाना हुन्छ। शाखाको यन्त्रमा यो प्रायः हुन्छ; धेरै निजी खण्ड भएको यन्त्रमा नहुन सक्छ।

सम्बन्ध बदल्नु भनेको प्रविष्टि पुनः सिर्जना गर्नु हो

त्यही कमाण्ड सन्दर्भले स्थानान्तरणका बेला मानिसलाई फसाउने सम्पादन बाधा लेखेको छ: विद्यमान होस्टमा इन्टरफेस बदल्न होस्ट प्रविष्टि हटाएर पुनः सिर्जना गर्नुपर्छ। सम्पादित देखिने कन्फिगरेसन कार्यान्वयन नभएको हुन सक्छ, र अर्को लगइन प्रयास अझै पुरानो ठेगानाबाटै जान्छ। यसलाई ठाउँमै सुधारका रूपमा होइन, मूल प्रविष्टिको प्रतिलिपि अगाडि राखेर हटाउने-थप्ने कामका रूपमा योजना बनाउनुहोस्।

धेरै सर्भर परिभाषित भएमा एउटा बदलेर बाँकी छुनुअघि त्यसको परीक्षण गर्नुहोस्, ताकि एउटा गल्तीले सबै प्रशासनिक मार्ग एकैचोटि बन्द नगरोस्।

सिलेक्टर, अनुवाद र फर्किने मार्ग सँगै जाँच्नुहोस्

अनुरोध पुग्न तीनवटा कुरा मिल्नुपर्छ। टनेलका ट्राफिक सिलेक्टर, वा तपाईंले टनेल-इन्टरफेस सुरक्षा चलाउनुहुन्छ भने त्यो, मा ASA को आफ्नै स्रोत र सर्भरको ठेगाना समावेश हुनुपर्छ; प्रयोगकर्ता सबनेटका लागि बनाइएको सिलेक्टर सूचीले सामान्यतया त्यो गर्दैन। मार्गमा हुने जुनसुकै NAT नियमले त्यो स्रोतलाई निरन्तर रूपमा अनुवाद गर्नुपर्छ, किनभने सर्भरले आफूले देख्ने ठेगाना समावेश भएको सञ्जाल यन्त्रको पहिचान अधिकृत गर्छ। र फर्किने मार्ग हुनैपर्छ, जसको अर्थ नीति-आधारित टनेलमा विपरीत दिशामा मिल्ने सिलेक्टर टाढाको छेउमा छ।

सर्भरतर्फ यन्त्रको पहिचान, साझा गोप्य र प्रशासनिक नीति छुट्टाछुट्टै पुष्टि गर्नुहोस्। TACACS+ ले प्रमाणीकरण, अधिकार र लेखाकर्मलाई छुट्टै कार्यका रूपमा राख्छ, त्यसैले पूरा भइसकेको आदानप्रदानपछि आउने अस्वीकृति नीतिको उत्तर हो, यातायात असफलता होइन। यसलाई सञ्जाल समस्या भनेर पढ्नुले तपाईंलाई गलत ठाउँमा खोज्न पठाउँछ।

डिबग गर्दा गोप्यलाई प्याकेट क्याप्चर, टिकट र ट्रान्स्क्रिप्टबाट बाहिर राख्नुहोस्, र सर्भरले लग गर्ने स्रोत ठेगाना नै तपाईंको डिजाइनले व्याख्या गर्नुपर्ने ठेगाना हो भन्ने सम्झनुहोस्।

आफूलाई बाहिर लक नगरी परिवर्तन गर्नुहोस्

टाढाको प्रशासनिक प्रमाणीकरण बदल्दा कन्सोल वा स्वतन्त्र व्यवस्थापन मार्ग प्रयोग गर्नुहोस्, र नयाँ मार्गले वास्तविक लगइन बोक्नेसम्म स्वीकृत स्थानीय विकल्प राख्नुहोस्। त्यसपछि साँघुरो रूपमा प्रमाणित गर्नुहोस्: एउटा सर्भर, एउटा यन्त्र, दुवै छेउमा देखिएको स्रोत ठेगानासहित एउटा सफल प्रमाणीकरण।

प्रवाहलाई यसको आफ्नै पृष्ठमा अभिलेख गर्नुहोस्: उद्गम इन्टरफेस र ठेगाना, टाढाको सर्भर, सुरक्षित मार्ग, र अधिकार नीतिको मालिक व्यक्ति। त्यसपछि पछिको इन्टरफेस वा टनेल परिवर्तनले दुई प्रवाहमध्ये कुनलाई असर गर्छ भनी अनुमान नगरी मूल्याङ्कन गर्न सकिन्छ।