साइट 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 ट्रैफ़िक ले जाने वाली टनल फ़ायरवॉल की अपनी आवाज़ ले जाने वाली टनल नहीं है।