SSH urruneko ASA batera gunearen VPN bidez: urrats urrats

SSH bezero bat urruneko ASAren barne-helbidera zuzentzen duzu eta saioa hiltzen da konektatzean. Suhormak bere guneetik erantzuten du, tunela agertzen da, eta, hala ere, ezer ez dabil entzuten 22 portuan. Kasu gehienetan paketeak ez du inoiz kudeaketa-onarpena lortzen, probatzen ari den bideak ez zelako inoiz kudeaketa-bide gisa diseinatu. Jarraitu beheko fluxua ordenan eta hutsak mugitzeari utziko dio.

Aukeratu benetan administratzen ari zaren helbidea

Hiru diseinuk antzeko itxura dute eta desberdin jokatzen dute: ASAren VPN-ra begira dagoen helbide publikora iristea, barne-interfaze batera IPsec bidez iristea eta kudeaketa-interfaze dedikatu batera iristea. Idatzi administratzailearen jatorrizko helbidea, helmuga-helbide zehatza eta TCP 22 baimen bat ukitu aurretik. Geroagoko guztia bikote horren mende dago.

Bi zerbitzari VLAN daramatzan tunel batek agian ez du suhormaren interfaze-helbidea edo administratzailearen kudeaketa-azpisarea bat ere eramango. Egiaztatu gunearen eta guneren arteko politikaren trafiko interesgarriaren zerrenda eta baieztatu ASAren beraren helbidea helmuga gisa agertzen dela, ez bakarrik hortik igarotzen diren azpisareak.

Helmuga suhorma bera denez, kudeaketa-onarpena birbidalitako trafikoaren arauetatik bereizia dago. Bezeroei ASAren atzeko zerbitzarietara iristen uzten dien ACL batek ez du bere kabuz gaitzen gailuaren SSH kudeaketa, eta birbidaltze-araua konpontzeak ez du huts hau mugituko.

management-access interfazearen araberakoa da

management-access komandoak ASAri esaten dio VPN bidez iristen direnean izendatutako interfaze baterako kudeaketa-konexioak onar ditzala. Ez du ibilbiderik sortzen, ez du SSH baimenik gehitzen, eta ez da interfaze guztietan aldi berean aplikatzen. Helmugako interfazea izendatutakoa ez bada, konexioa baztertzen da autentifikazioa baino lehen.

Bi bazterketa daude hemen. Kudeaketarako soilik diren interfazeak mekanismo honetatik kanpo daude, eta ASA 9.20 kudeaketa-gidak ohartarazten du CiscoSSH pila lehenetsiak ez duela VPN bidezko interfazeen arteko SSH onartzen, ASA SSH pilak bai ordea. Egiaztatu inplementatutako bertsioan pila aktiboa ibilbideetan denbora eman aurretik.

Lau ate saioa hasteko eskaeraren aurretik

Bezeroaren eta erabiltzaile-izenaren eskaeraren artean lau ate independente daude: kudeaketa-bikotearen ibilbide eta tunel bat-etortzea, ASAren helbidera TCP 22 baimendatzen duen interfaze-ACL bat, administratzailearen jatorria estaltzen duen ssh baimen bat eta erabiltzaile horrentzako AAA autentifikazioa. Bakoitzak paketea bota dezake bezeroari zein ate itxi zen esan gabe.

Erabili packet-tracer zein atek huts egiten duen ikusteko ezer aldatu aurretik: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Trazak ACLa, NAT etapa eta to-the-box erabakia izendatzen ditu, eta hori normalean nahikoa izaten da bideratze-arazoa onarpen-arazotik bereizteko.

Idatzi baimen estua, ez zabala

Mugatu baimena onartutako administrazio-azpisarera eta tunelaren trafikoa jasotzen duen interfazera: ssh 10.10.5.0 255.255.255.0 inside. Lotu ezazu aaa authentication ssh console LOCAL bezalako autentifikazio-metodo batekin eta izendatutako tokiko kontu batekin, kanpoko interfazean jatorri guztiak ireki ordez.

Eduki itzazu interfaze-ACLa eta ssh baimena koherente. ACLak blokeatzen duen azpisare baterako baimenak huts egiten du oraindik ere, eta azpisarea ssh sarrerarik gabe baimendatzen duen ACLak hurrengo atean huts egiten du. Bi adierazpenek bide bera deskribatzen dute geruza ezberdinetatik, beraz, berrikusi itzazu elkarrekin exekuzio-konfigurazioan.

Egiaztatu izendatutako ostalaritik, eta gero estutu berriro

Ireki saio berri bat izendatutako kudeaketa-ostalaritik zure mahaigainetik baino, eta baieztatu ASAn konexioak zein jatorri-helbide eta zein interfaze erabili zituen. Egiaztatu saio aktiboak eta exekuzio-konfigurazioaren SSH atala saioa irekita dagoen bitartean, gero itxi eta kendu probetarako gehitutako aldi baterako baimen oro. Saioa agertzen bada baina saioa hasi eta berehala erortzen bada, gainerako arazoa baimenena da, ez irisgarritasuna. Erregistratu interfazea eta jatorria aldaketa-erregistroan, hurrengo pertsonak diagnostikoa errepika ez dezan.

Eduki kontsola edo modu independentean onartutako beste berreskuratze-bide bat eskuragarri aldaketa osoan zehar. Bide pribatuak funtzionatzen duenean, baieztatu iturri publikoek eta erlaziorik gabeko VPN erabiltzaileek ez dutela sarbide bera lortu, denontzat funtzionatzen duen kudeaketa-bidea hasi zinen arazoaren bestelakoa baita.