సైట్ 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 వినియోగదారులు అదే ప్రవేశాన్ని పొందలేదని నిర్ధారించండి, ఎందుకంటే అందరికీ పనిచేసే నిర్వహణ మార్గం మీరు ప్రారంభించిన సమస్యకు భిన్నమైన సమస్య.