साइट VPN मार्फत टाढाको ASA मा SSH: पाइला पाइलामा

तपाईं SSH क्लाइन्टलाई टाढाको ASA को आन्तरिक ठेगानामा पठाउनुहुन्छ र जडान हुँदा नै सत्र मर्छ। फायरवाल आफ्नै साइटबाट जवाफ दिन्छ, सुरुङ देखिन्छ, तैपनि पोर्ट 22 मा केही सुनिँदैन। यस्ता अधिकांश अवस्थामा प्याकेट कहिल्यै व्यवस्थापन प्रवेशसम्म पुग्दैन, किनकि जाँचिएको मार्ग कहिल्यै व्यवस्थापन मार्गका रूपमा डिजाइन गरिएको थिएन। तलको प्रवाह क्रममा पछ्याउनुहोस् र खराबी ठाउँ सर्न छाड्छ।

तपाईंले वास्तवमै व्यवस्थापन गर्नुभएको ठेगाना छान्नुहोस्

तीन डिजाइन उस्तै देखिन्छन् र फरक व्यवहार गर्छन्: ASA को सार्वजनिक VPN तर्फको ठेगानामा पुग्ने, IPsec मार्फत आन्तरिक इन्टरफेसमा पुग्ने, र समर्पित व्यवस्थापन इन्टरफेसमा पुग्ने। कुनै पनि अनुमति छुनुअघि प्रशासकको स्रोत ठेगाना, ठ्याक्कै गन्तव्य ठेगाना र TCP 22 लेख्नुहोस्। त्यसपछिको सबै कुरा त्यही जोडीमा निर्भर छ।

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

गन्तव्य फायरवाल आफैं भएकाले, व्यवस्थापन प्रवेश अगाडि पठाइएको ट्राफिकका नियमबाट अलग छ। क्लाइन्टहरूलाई ASA पछाडिका सर्भरसम्म पुग्न दिने ACL ले उपकरणको SSH व्यवस्थापन स्वतन्त्र रूपमा सक्रिय गर्दैन, र फरवार्ड नियम सुधार्नाले यो खराबी सर्दैन।

management-access इन्टरफेस-विशेष छ

management-access आदेशले ASA लाई VPN बाट आउने व्यवस्थापन जडान नाम दिइएको इन्टरफेसमा स्वीकार्न भन्छ। यसले मार्ग बनाउँदैन, SSH अनुमति थप्दैन, र एकैचोटि हरेक इन्टरफेसमा लागू हुँदैन। यदि गन्तव्य इन्टरफेस नाम दिइएको होइन भने, प्रमाणीकरणअघि नै जडान फालिन्छ।

यहाँ दुई अपवादले टोक्छन्। व्यवस्थापनका लागि मात्र इन्टरफेसहरू यो संयन्त्रबाहिर छन्, र ASA 9.20 व्यवस्थापन मार्गदर्शिका ले पूर्वनिर्धारित CiscoSSH स्ट्याकले VPN मार्फत इन्टरफेस-पार SSH समर्थन नगर्ने तर ASA SSH स्ट्याकले गर्ने उल्लेख गर्छ। मार्गमा समय खर्चनुअघि तैनाथ संस्करणमा सक्रिय स्ट्याक पुष्टि गर्नुहोस्।

लगइन प्रम्प्टअघि चार ढोका

क्लाइन्ट र प्रयोगकर्तानाम प्रम्प्टबीच चार स्वतन्त्र ढोका छन्: व्यवस्थापन जोडीका लागि मार्ग र सुरुङको मेल, ASA ठेगानामा TCP 22 लाई अनुमति दिने इन्टरफेस ACL, प्रशासकको स्रोत ढाक्ने ssh अनुमति, र त्यो प्रयोगकर्ताका लागि AAA प्रमाणीकरण। जुनसुकै ढोका बन्द भयो भनी क्लाइन्टलाई नभनी तीमध्ये कुनैले प्याकेट खसाल्न सक्छ।

केही बदल्नुअघि कुन ढोका असफल हुन्छ देख्न packet-tracer प्रयोग गर्नुहोस्: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed। ट्रेसले ACL, NAT चरण र to-the-box निर्णय नाम दिन्छ, जुन सामान्यतया राउटिङ समस्यालाई प्रवेश समस्याबाट छुट्याउन पर्याप्त हुन्छ।

साँघुरो अनुमति लेख्नुहोस्, फराकिलो होइन

अनुमतिलाई स्वीकृत प्रशासनिक सबनेट र सुरुङको ट्राफिक लिने इन्टरफेसमा सीमित गर्नुहोस्: ssh 10.10.5.0 255.255.255.0 inside। बाहिरी इन्टरफेसमा हरेक स्रोत खोल्नुको सट्टा यसलाई aaa authentication ssh console LOCAL जस्तो प्रमाणीकरण विधि र नाम दिइएको स्थानीय खातासँग जोड्नुहोस्।

इन्टरफेस ACL र ssh अनुमति सुसंगत राख्नुहोस्। ACL ले रोक्ने सबनेटका लागि अनुमति तैपनि असफल हुन्छ, र मिल्ने ssh प्रविष्टि बिना सबनेटलाई अनुमति दिने ACL अर्को ढोकामा असफल हुन्छ। दुवै भनाइले एउटै मार्गलाई फरक तहबाट वर्णन गर्छन्, त्यसैले चलिरहेको कन्फिगरेसनमा तिनीहरूलाई सँगै समीक्षा गर्नुहोस्।

नाम दिइएको होस्टबाट प्रमाणित गर्नुहोस्, अनि फेरि साँघुरो पार्नुहोस्

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

पूरै परिवर्तनभरि कन्सोल वा स्वतन्त्र रूपमा स्वीकृत अर्को पुनःप्राप्ति मार्ग उपलब्ध राख्नुहोस्। निजी मार्ग चलेपछि सार्वजनिक स्रोत र असम्बन्धित VPN प्रयोगकर्ताले त्यही पहुँच नपाएको पुष्टि गर्नुहोस्, किनकि सबैका लागि चल्ने व्यवस्थापन मार्ग तपाईंले सुरु गरेको समस्याभन्दा फरक समस्या हो।