साइट VPN काम करते, पण ASA लॉग येत नाहीत: स्रोत पत्ता तपासा

आतील होस्ट दूरच्या संग्राहकापर्यंत पोहोचतात आणि त्यांच्या syslog ओळी दिसतात। त्याच सत्रांबद्दलचे ASA चे स्वतःचे संदेश कधीही येत नाहीत। संग्राहकात किंवा टनेलमध्ये काहीही चुकीचे नाही, आणि हाच गोंधळाचा भाग आहे। फायरवॉल आपले लॉग अशा स्रोतातून पाठवत आहे ज्याचे रक्षण करण्यासाठी टनेल कधीही बांधले गेले नव्हते।

काय येते आणि काय येत नाही

डॅशबोर्डवर सारखे दिसणारे दोन प्रवाह वेगळे करून सुरुवात करा। फॉरवर्ड केलेला ट्रॅफिक ASA मधून जातो: एक LAN होस्ट संग्राहकाकडे पाठवतो, ASA तो टनेल धोरणाशी जुळवतो, त्याला एन्क्रिप्ट करतो, आणि संग्राहक होस्टचा पत्ता पाहतो। तयार केलेला ट्रॅफिक ASA वरच सुरू होतो: उपकरण syslog पॅकेट तयार करते, आउटगोइंग इंटरफेस आणि स्रोत निवडते, आणि त्यानंतरच कोणतेही टनेल धोरण जुळते का असे विचारते। पहिला प्रवाह टनेल काम करत असल्याचे सिद्ध करतो, आणि दुसऱ्याबद्दल काहीही सांगत नाही।

उपकरणावर बफर केलेली घटनाही दूरस्थ वितरणाचा पुरावा नाही, कारण लॉग स्थानिक पातळीवर असू शकतो आणि कधीही पाठवला गेला नसेल। टनेलला दोष देण्यापूर्वी संग्राहकाचे प्राप्ती काउंटर तपासा, कारण रिकामे काउंटर वाढणाऱ्या काउंटरपेक्षा वेगळा निष्कर्ष आहे।

तयार केलेला संदेश फॉरवर्ड केलेला ट्रॅफिक नाही

जेव्हा ASA स्वतः पॅकेट तयार करते, तेव्हा ते LAN होस्टचे प्रॉक्सी करत नाही। स्रोत आउटगोइंग इंटरफेसकडून किंवा स्पष्ट स्रोत सेटिंगकडून येतो, आणि पॅकेट उपकरण पाठवते त्या इतर सर्वांप्रमाणेच त्याच रूट शोध आणि धोरण तपासण्यांमध्ये प्रवेश करते। याचा अर्थ VPN सिलेक्टरमध्ये ASA प्रत्यक्षात वापरत असलेला पत्ता असावा, आणि तो बहुतेक वेळा त्याचा बाह्य इंटरफेस असतो, आंतरिक सबनेट नाही।

धोरण 10.20.0.0/24 चे रक्षण करत असेल आणि ASA स्रोत म्हणून आपला बाह्य पत्ता वापरत असेल, तर लॉग पॅकेट एकतर पोहोचू शकत नाही अशा संग्राहकाकडे स्पष्ट मजकुरात निघते, किंवा टाकून दिले जाते। संग्राहकाच्या बाजूने दोन्ही निकाल सारखेच दिसतात। तेच तर्क व्यवस्थापन ट्रॅफिकलाही लागू होतात, म्हणून management-access हा वेगळा रचना निर्णय आहे।

ASA नेटवर्कवर कोणता स्रोत ठेवते

स्रोत गृहीतकाने नाही, प्रयोगाने शोधा। चाचणी संदेशादरम्यान आउटगोइंग इंटरफेसवर कॅप्चर प्रत्यक्ष स्रोत आणि गंतव्य दाखवते, आणि ते कॉन्फिगरेशनचे तीन विभाग वाचण्यापेक्षा कमी वेळ घेते। त्या पत्त्याची टनेलच्या स्थानिक सिलेक्टरशी तुलना करा।

काही आवृत्त्या लॉगिंग स्रोत इंटरफेसवर पिन करू देतात, आणि तुमच्या आवृत्तीचा कमांड संदर्भ हा तो पर्याय आहे का आणि तो काय बदलतो याबाबत अधिकार आहे। दुसऱ्या Cisco प्लॅटफॉर्मचा source-interface कमांड ASA वर आपोआप वैध नसतो।

तुम्ही स्रोत बदलत असाल, तर जाणीवपूर्वक बदला आणि नोंद करा, कारण संग्राहकाचे ACL आणि syslog वर बांधलेला कोणताही सहसंबंध त्यावर अवलंबून आहे।

सिलेक्टरला लॉग प्रवाहाशी जुळवा

स्रोत माहीत झाल्यावर तीन गोष्टी क्रमाने तपासा: कोणता ट्रॅफिक महत्त्वाचा आहे हे ठरवणारा क्रिप्टो ACL किंवा धोरण-आधारित सिलेक्टर, पॅकेट कुठे जाते हे ठरवणारा मार्ग, आणि एन्क्रिप्शनपूर्वी स्रोत पुन्हा लिहू शकणारा कोणताही NAT नियम। मार्गाशी जुळणारा पण सिलेक्टरशी न जुळणारा पॅकेट टनेलमधून जात नाही, आणि NAT ने पुन्हा लिहिलेला पॅकेट दोन्हींशी जुळणार नाही।

संग्राहकाच्या बाजूला स्वतःच्या गरजा आहेत: ASA च्या स्रोताला परवानगी देणारा ACL, परतीचा मार्ग, आणि तुम्ही कॉन्फिगर केलेल्या पोर्टवर ऐकणारी सेवा। वाहतूक इथेही महत्त्वाची आहे, कारण अंशतः अवरोधित मार्गावर TCP आणि TLS लॉगिंग UDP पेक्षा वेगळे वागते। एका वेळी एक घटक बदला, अन्यथा पुढील कॅप्चर कोणता बदल महत्त्वाचा होता ते सांगणार नाही।

संग्राहकावर पडताळा, नंतर स्रोत नोंदवा

संदेश येत असल्याची खात्री करा, नंतर ASA ने वापरलेला स्रोत पत्ता, तो वाहून नेणारा सिलेक्टर आणि तुम्ही चाचणी केलेली तीव्रता लिहा।

ती नोंद पुढील संग्राहक ACL बदल किंवा सिलेक्टर संपादन पुन्हा शोधण्याऐवजी दोन मिनिटांची तपासणी करते। दोन प्रवाहांपैकी कोणता कधीही पडताळला गेला हेही ती नोंदवते, आणि बहुतेक धावपुस्तिका हा भाग वगळतात। संदेश तरीही येत नसेल, तर तीव्रतेची मर्यादा तात्पुरती कमी करा आणि एकाच गंतव्याविरुद्ध चाचणी करा।

Cisco चे ASA लॉगिंगविषयी सामान्य प्रश्न बाह्य स्रोत असलेल्या प्रकरणाची नोंद करतात ज्यासाठी संबंधित संरक्षित ट्रॅफिक व्याख्या आवश्यक आहे, आणि त्यांच्या आंतरिक स्रोताच्या उदाहरणात आतल्या बाजूला लॉगिंग होस्ट आणि आतल्या बाजूला management-access दोन्ही समाविष्ट आहेत। नोंदवलेले संयोजन आणि सॉफ्टवेअर संदर्भ एकत्र घ्या, कॉपी केलेली एक ओळ प्रत्येक कॉन्फिगरेशनला बसते असे गृहीत धरू नका।

LAN ट्रॅफिक वाहणारे टनेल फायरवॉलचा स्वतःचा आवाज वाहणारे टनेल नाही।