SSH til ein ekstern ASA gjennom site-VPN: steg for steg

Du peikar ein SSH-klient mot den interne adressa til den eksterne ASA-en, og økta døyr ved tilkopling. Brannmuren svarar frå sin eigen stad, tunnelen viser seg, og likevel lyttar ingen på port 22. I dei fleste av desse tilfella når pakken aldri fram til administrasjonstilgangen, fordi vegen som blir testa aldri vart utforma som ein administrasjonsveg. Følg flyten nedanfor i rekkjefølgje, og feilen sluttar å flytte seg.

Vel adressa du faktisk administrerer

Tre design ser like ut og oppfører seg ulikt: å nå den offentlege VPN-adressa til ASA-en, å nå eit internt grensesnitt gjennom IPsec og å nå eit dedikert administrasjonsgrensesnitt. Skriv ned kjeldeadressa til administratoren, den nøyaktige måladressa og TCP 22 før du rører ei løyve. Alt seinare er avhengig av det paret.

Ein tunnel som ber to server-VLAN, ber kanskje ikkje brannmurgrensesnittet si adresse eller administrasjonssubnettet til administratoren i det heile. Sjekk lista over interessant trafikk for site-til-site-policyen og stadfest at den eigne adressa til ASA-en viser seg som mål, ikkje berre subnetta som går gjennom.

Fordi målet er brannmuren sjølv, er administrasjonstilgang skild frå reglar for vidaresend trafikk. Ein ACL som slepp klientar til serverar bak ASA-en, slår ikkje på SSH-administrasjon av eininga på eiga hand, og å rette vidaresendingsregelen flyttar ikkje denne feilen.

management-access er grensesnittsspesifikk

Kommandoen management-access ber ASA-en godta administrasjonstilkoplingar til eit namngjeve grensesnitt når dei kjem over VPN. Han opprettar ikkje ei rute, han legg ikkje til ei SSH-løyve, og han gjeld ikkje for alle grensesnitt samstundes. Viss målgrensesnittet ikkje er det namngjevne, blir tilkoplinga kasta før autentisering.

To unntak bit her. Grensesnitt berre for administrasjon er utanfor denne mekanismen, og administrasjonsrettleiinga for ASA 9.20 nemner at standard CiscoSSH-stakken ikkje støttar SSH mellom grensesnitt over VPN, medan ASA SSH-stakken gjer det. Stadfest den aktive stakken på den utrulla versjonen før du brukar tid på ruter.

Fire portar før påloggingsforespurnaden

Mellom klienten og brukarnamnforespurnaden står fire sjølvstendige portar: eit rute- og tunnelmatch for administrasjonsparet, ein grensesnitt-ACL som tillèt TCP 22 til ASA-adressa, ei ssh-løyve som dekkjer kjelda til administratoren, og AAA-autentisering for den brukaren. Kvar av dei kan sleppe pakken utan å fortelje klienten kva port som lukka seg.

Bruk packet-tracer for å sjå kva port som feilar før du endrar noko: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Sporinga namngjev ACL-en, NAT-trinnet og to-the-box-avgjerda, som vanlegvis er nok til å skilje eit ruteproblem frå eit tilgangsproblem.

Skriv den tronge løyva, ikkje den breie

Avgrens løyva til det godkjende administrative subnettet og grensesnittet som tek imot trafikken i tunnelen: ssh 10.10.5.0 255.255.255.0 inside. Kopla ho til ein autentiseringsmetode som aaa authentication ssh console LOCAL og ein namngjeven lokal konto, i staden for å opne kvar kjelde på det ytre grensesnittet.

Hald grensesnitt-ACL-en og ssh-løyva konsistente. Ei løyve for eit subnett som ACL-en blokkerer, feilar framleis, og ein ACL som tillèt subnettet utan ei samsvarande ssh-oppføring, feilar ved neste port. Begge utsegnene skildrar same vegen frå ulike lag, så gå gjennom dei saman i den køyrande konfigurasjonen.

Stadfest frå den namngjevne verten, og snevra inn igjen

Opne ei ny økt frå den namngjevne administrasjonsverten i staden for frå skrivebordet ditt, og stadfest på ASA-en kva kjeldeadresse og kva grensesnitt tilkoplinga brukte. Sjekk dei aktive øktene og SSH-delen av den køyrande konfigurasjonen medan økta er open, lukk ho deretter og fjern kvar mellombels løyve du la til for testing. Viss økta viser seg men fell rett etter pålogging, er det gjenverande problemet autorisasjon og ikkje tilgjenge. Noter grensesnittet og kjelda i endringsloggen, slik at neste person ikkje gjer diagnosen om att.

Hald konsollen eller ein annan uavhengig godkjend attopprettingsveg tilgjengeleg gjennom heile endringa. Når den private vegen verkar, stadfest at offentlege kjelder og urelaterte VPN-brukarar ikkje fekk same tilgang, fordi ein administrasjonsveg som verkar for alle, er eit anna problem enn det du starta med.