साइट VPN के माध्यम से दूर के ASA तक SSH: कदम दर कदम

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

वह पता चुनें जिसे आप वास्तव में प्रशासित कर रहे हैं

तीन डिज़ाइन एक जैसे दिखते हैं और अलग व्यवहार करते हैं: ASA के सार्वजनिक VPN-मुखी पते तक पहुँचना, IPsec के ज़रिये आंतरिक इंटरफ़ेस तक पहुँचना, और समर्पित प्रबंधन इंटरफ़ेस तक पहुँचना। किसी भी अनुमति को छूने से पहले प्रशासक का स्रोत पता, सटीक गंतव्य पता और TCP 22 लिख लें। आगे का सब कुछ उसी जोड़ी पर निर्भर है।

दो सर्वर VLAN ले जाने वाली सुरंग फ़ायरवॉल के इंटरफ़ेस पते या प्रशासक के प्रबंधन सबनेट को बिल्कुल भी न ले जाए। साइट-से-साइट नीति के लिए रोचक ट्रैफ़िक की सूची जाँचें और पुष्टि करें कि ASA का अपना पता गंतव्य के रूप में दिखता है, केवल उससे गुज़रने वाले सबनेट नहीं।

चूँकि गंतव्य स्वयं फ़ायरवॉल है, प्रबंधन प्रवेश अग्रेषित ट्रैफ़िक के नियमों से अलग है। जो ACL क्लाइंट को ASA के पीछे के सर्वर तक पहुँचने देता है वह उपकरण का 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 उपयोगकर्ताओं को वही पहुँच नहीं मिली, क्योंकि सबके लिए काम करने वाला प्रबंधन पथ उस समस्या से अलग समस्या है जिससे आपने शुरू किया था।