साइट 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 वापरकर्त्यांना तोच प्रवेश मिळाला नाही याची खात्री करा, कारण सर्वांसाठी चालणारा व्यवस्थापन मार्ग तुम्ही सुरू केलेल्या समस्येपेक्षा वेगळी समस्या आहे।