साइट 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 ट्राफिक बोक्ने टनेल फायरवालको आफ्नै आवाज बोक्ने टनेल होइन।