தள VPN வழியாக தொலை ASA-க்கு SSH: படிப்படியாக

நீங்கள் SSH கிளையண்டை தொலை ASA-வின் உள் முகவரிக்கு இயக்குகிறீர்கள், இணைக்கும்போதே அமர்வு இறந்துவிடுகிறது. ஃபயர்வால் தனது சொந்த தளத்திலிருந்து பதிலளிக்கிறது, சுரங்கம் தெரிகிறது, இருந்தும் போர்ட் 22 இல் எதுவும் கேட்கவில்லை. இந்த நிகழ்வுகளில் பெரும்பாலானவற்றில் பாக்கெட் ஒருபோதும் நிர்வாக அனுமதியை அடையாது, ஏனெனில் சோதிக்கப்படும் பாதை ஒருபோதும் நிர்வாகப் பாதையாக வடிவமைக்கப்படவில்லை. கீழே உள்ள ஓட்டத்தை வரிசையாகப் பின்பற்றுங்கள், தோல்வி இடம் மாறுவது நிற்கும்.

நீங்கள் உண்மையில் நிர்வகிக்கும் முகவரியைத் தேர்ந்தெடுக்கவும்

மூன்று வடிவமைப்புகள் ஒரே மாதிரி தெரிந்தாலும் வெவ்வேறாக செயல்படுகின்றன: ASA-வின் பொது VPN நோக்கிய முகவரியை அடைவது, IPsec வழியாக உள் இடைமுகத்தை அடைவது, மற்றும் தனித்துவமான நிர்வாக இடைமுகத்தை அடைவது. எந்த அனுமதியையும் தொடுவதற்கு முன் நிர்வாகியின் மூல முகவரி, சரியான இலக்கு முகவரி மற்றும் TCP 22 ஆகியவற்றை எழுதுங்கள். அதன் பிறகு அனைத்தும் அந்த இணையைப் பொறுத்தது.

இரண்டு சேவையக VLAN களைக் கொண்டு செல்லும் சுரங்கம் ஃபயர்வாலின் இடைமுக முகவரியையோ நிர்வாகியின் நிர்வாக துணை வலையமைப்பையோ அறவே கொண்டு செல்லாமல் இருக்கலாம். தளத்திற்கு-தளம் கொள்கைக்கான சுவாரஸ்யமான டிராஃபிக் பட்டியலைச் சரிபார்த்து, ASA-வின் சொந்த முகவரி இலக்காகத் தெரிகிறதா என்பதை உறுதிப்படுத்துங்கள், அதன் வழியாகச் செல்லும் துணை வலையமைப்புகள் மட்டுமல்ல.

இலக்கு ஃபயர்வால் தானே என்பதால், நிர்வாக அனுமதி அனுப்பப்படும் டிராஃபிக்கின் விதிகளிலிருந்து தனியானது. வாடிக்கையாளர்களை ASA-வின் பின்னால் உள்ள சேவையகங்களை அடைய அனுமதிக்கும் ACL சாதனத்தின் SSH நிர்வாகத்தைத் தானாக இயக்காது, அனுப்புதல் விதியைச் சரிசெய்வதால் இந்தத் தோல்வி நகராது.

management-access இடைமுகத்திற்கு உரியது

management-access கட்டளை VPN வழியாக வரும் நிர்வாக இணைப்புகளை பெயரிடப்பட்ட இடைமுகத்தில் ஏற்குமாறு ASA-க்குக் கூறுகிறது. அது பாதையை உருவாக்காது, 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 பயனர்களும் அதே அணுகலைப் பெறவில்லை என்பதை உறுதிப்படுத்துங்கள், ஏனெனில் அனைவருக்கும் செயல்படும் நிர்வாகப் பாதை நீங்கள் தொடங்கிய சிக்கலிலிருந்து வேறுபட்ட சிக்கல்.