शाखा टनेल सुरू आहे, वापरकर्ते दूरच्या TACACS+ सर्व्हरवर प्रमाणीकरण करत आहेत, आणि फायरवॉलचे स्वतःचे लॉगिन अजूनही वेळ संपून अयशस्वी होते. कारण टनेलमधील दोष नाही: LAN-to-LAN टनेल त्याच्या सिलेक्टरशी जुळणारी वाहतूक वाहून नेते, आणि ASA स्वतःबद्दल निर्माण करते ती व्यवस्थापन वाहतूक स्वतःच्या स्रोत पत्त्यासह वेगळा प्रवाह आहे. बहुतेक संघ हे बदल विंडो दरम्यान शोधतात, जेव्हा एकमेव प्रशासक खातेच अयशस्वी होत असते. ASA ने सुरू केलेल्या AAA सत्राला तुम्हाला रचावे लागणारा प्रवाह माना, आधीच चालू असलेल्या कनेक्टिव्हिटीचा दुष्परिणाम मानू नका.

ASA हाच क्लायंट आहे, आणि त्याच्या स्वतःच्या वाहतुकीला स्वतःचा मार्ग हवा

जेव्हा फायरवॉल TACACS+ सर्व्हरशी संपर्क साधतो, तेव्हा फायरवॉल इतर कोणत्याही क्लायंटसारखा असतो, फक्त कुणीही जाणूनबुजून त्यासाठी मार्ग संरचित केलेला नाही. त्याचे पॅकेट उपकरणावरील इंटरफेस पत्त्यावरून निघतात, ते पुढे पाठवले जाण्याऐवजी स्थानिक पातळीवर तयार होतात, आणि वापरकर्ता वाहतुकीप्रमाणेच त्यांना मार्गनिर्देशित, अनुवादित आणि धोरणाने संरक्षित करावे लागते. वापरकर्ता सबनेटचे संरक्षण करणारा साइट-ते-साइट टनेल त्या व्यवस्थापन स्रोताचे स्वयंचलितपणे संरक्षण करत नाही, कारण वाहतूक निवड पत्त्यांवर आधारित आहे, हेतूवर नाही.

सर्व्हरला दिसेल अशी तुम्ही अपेक्षा करता तो पत्ता लिहून ठेवा. जर तो एका ओळीत सांगता येत नसेल, तर तुमच्याकडे अजून रचना नाही.

aaa-server ओळीतील इंटरफेस हा सजावट नाही

ASA वर aaa-server होस्ट नोंद कंसात इंटरफेस जोडणी घेते, आणि Cisco चे AAA होस्ट कमांड संदर्भ तिला प्रमाणीकरण सर्व्हर जिथे आहे तो इंटरफेस असे वर्णन करते. हीच जोडणी विनंतीला इंटरफेसशी आणि तो इंटरफेस लागू करतो त्या धोरणाशी जोडते. इंटरनेटकडे तोंड असलेल्या कोणत्याही इंटरफेसनुसार ती निवडल्यास, किंवा शेवटच्या स्थलांतरापासून जे उरले ते तसेच ठेवल्यास, दूरचा सर्व्हर आणि टनेल कधीही बांधले न गेलेला स्रोत पत्ता तयार होतो.

inside हे तेव्हाच बरोबर उत्तर ठरते जेव्हा नामनिर्देशित इंटरफेसकडे तुमची रचना स्रोत म्हणून वापरणार असलेला पत्ता असतो. शाखेच्या उपकरणावर हे बऱ्याचदा असते; अनेक खाजगी विभाग असलेल्या उपकरणावर नसू शकते.

जोडणी बदलणे म्हणजे नोंद पुन्हा तयार करणे

तोच कमांड संदर्भ अशी संपादन मर्यादा नोंदवतो जी संक्रमणाच्या वेळी लोकांना अडकवते: विद्यमान होस्टवरील इंटरफेस बदलण्यासाठी होस्ट नोंद काढून पुन्हा तयार करावी लागते. संपादित दिसणारे संरचना अंमलात आली नसेल, आणि पुढची लॉगिन कोशिश अजूनही जुन्या पत्त्यावरूनच बाहेर पडेल. हे जागेवरच दुरुस्ती म्हणून नाही, तर मूळ नोंदीची प्रत समोर ठेवून काढून-जोडण्याचे काम म्हणून नियोजित करा.

अनेक सर्व्हर परिभाषित असल्यास, एक बदला आणि बाकीच्यांना हात लावण्यापूर्वी त्याची चाचणी करा, जेणेकरून एक चूक सर्व प्रशासकीय मार्ग एकत्र बंद करणार नाही.

सिलेक्टर, अनुवाद आणि परतीचा मार्ग एकत्र तपासा

विनंती पोहोचण्यासाठी तीन गोष्टी जुळल्या पाहिजेत. टनेलचे वाहतूक सिलेक्टर, किंवा तुम्ही टनेल-इंटरफेस संरक्षण वापरत असल्यास ते, ASA चा स्वतःचा स्रोत आणि सर्व्हरचा पत्ता समाविष्ट करतात का पाहा; वापरकर्ता सबनेटसाठी बनवलेली सिलेक्टर यादी सामान्यतः तसे करणार नाही. मार्गावरील कोणताही NAT नियम त्या स्रोताचा सुसंगत अनुवाद करतो का पाहा, कारण सर्व्हर स्वतःला दिसणारा पत्ता समाविष्ट असलेल्या नेटवर्क उपकरणाच्या ओळखीला अधिकृत करतो. आणि परतीचा मार्ग असणे आवश्यक आहे, ज्याचा अर्थ धोरण-आधारित टनेलमध्ये विरुद्ध दिशेने जुळणारा सिलेक्टर दूरच्या टोकाकडे आहे.

सर्व्हरच्या बाजूला उपकरणाची ओळख, सामायिक रहस्य आणि प्रशासकीय धोरण स्वतंत्रपणे पुष्टी करा. TACACS+ प्रमाणीकरण, अधिकृतता आणि लेखाजोखा स्वतंत्र क्रिया म्हणून ठेवते, म्हणून पूर्ण झालेल्या देवघेवीनंतर येणारा नकार हे धोरणाचे उत्तर आहे, वाहतूक अपयश नाही. त्याला नेटवर्क समस्या म्हणून वाचल्यास तुम्ही चुकीच्या ठिकाणी शोधाल.

डीबग करताना रहस्य पॅकेट कॅप्चर, तिकिटे आणि प्रतिलेखांपासून दूर ठेवा, आणि लक्षात ठेवा की सर्व्हर जो स्रोत पत्ता नोंदवतो तोच तुमच्या रचनेला स्पष्ट करावा लागणारा पत्ता आहे.

स्वतःला बाहेर कुलूप न लावता बदल करा

दूरचे प्रशासकीय प्रमाणीकरण बदलताना कन्सोल किंवा स्वतंत्र व्यवस्थापन मार्ग वापरा, आणि नवा मार्ग खरे लॉगिन वाहून नेईपर्यंत मंजूर स्थानिक पर्याय ठेवा. नंतर अरुंदपणे पडताळा: एक सर्व्हर, एक उपकरण, दोन्ही टोकांना निरीक्षण केलेल्या स्रोत पत्त्यासह एक यशस्वी प्रमाणीकरण.

प्रवाह त्याच्या स्वतःच्या पानावर नोंदवा: उगम इंटरफेस आणि पत्ता, दूरचा सर्व्हर, संरक्षित मार्ग, आणि अधिकृतता धोरणाचा मालक असलेली व्यक्ती. मग नंतरचा इंटरफेस किंवा टनेल बदल दोन प्रवाहांपैकी कोणाला प्रभावित करतो याचा अंदाज न लावता मूल्यांकन करता येईल.

संबंधित लेख