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

Du peker en SSH-klient mot den interne adressen til den eksterne ASA-en, og økten dør ved tilkobling. Brannmuren svarer fra sitt eget nettsted, tunnelen vises, og likevel lytter ingenting på port 22. I de fleste av disse tilfellene når pakken aldri frem til administrasjonstilgangen, fordi banen som testes aldri ble designet som en administrasjonsbane. Følg flyten nedenfor i rekkefølge, og feilen slutter å flytte seg.

Velg adressen du faktisk administrerer

Tre design ser like ut og oppfører seg forskjellig: å nå ASA-ens offentlige VPN-adresse, å nå et internt grensesnitt gjennom IPsec og å nå et dedikert administrasjonsgrensesnitt. Skriv ned administratorens kildeadresse, den nøyaktige destinasjonsadressen og TCP 22 før du rører en tillatelse. Alt senere avhenger av det paret.

En tunnel som bærer to server-VLAN-er, bærer kanskje ikke brannmurens grensesnittadresse eller administratorens administrasjonssubnett i det hele tatt. Sjekk listen over interessant trafikk for site-til-site-policyen og bekreft at ASA-ens egen adresse vises som destinasjon, ikke bare subnettene som passerer gjennom.

Fordi destinasjonen er brannmuren selv, er administrasjonstilgang atskilt fra regler for videresendt trafikk. En ACL som slipper klienter til servere bak ASA-en, aktiverer ikke SSH-administrasjon av enheten på egen hånd, og å rette videresendingsregelen flytter ikke denne feilen.

management-access er grensesnittspesifikk

Kommandoen management-access ber ASA-en godta administrasjonstilkoblinger til et navngitt grensesnitt når de kommer over VPN. Den oppretter ikke en rute, den legger ikke til en SSH-tillatelse, og den gjelder ikke for alle grensesnitt samtidig. Hvis destinasjonsgrensesnittet ikke er det navngitte, forkastes tilkoblingen før autentisering.

To unntak biter her. Grensesnitt kun for administrasjon er utenfor denne mekanismen, og administrasjonsveiledningen for ASA 9.20 bemerker at standard CiscoSSH-stakk ikke støtter SSH mellom grensesnitt over VPN, mens ASA SSH-stakken gjør det. Bekreft den aktive stakken på den utrullede versjonen før du bruker tid på ruter.

Fire porter før påloggingsforespørselen

Mellom klienten og brukernavnforespørselen står fire uavhengige porter: et rute- og tunnelmatch for administrasjonsparet, en grensesnitt-ACL som tillater TCP 22 til ASA-adressen, en ssh-tillatelse som dekker administratorens kilde, og AAA-autentisering for den brukeren. Hver av dem kan droppe pakken uten å fortelle klienten hvilken port som lukket seg.

Bruk packet-tracer for å se hvilken port som feiler før du endrer noe: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Sporingen navngir ACL-en, NAT-trinnet og to-the-box-beslutningen, som vanligvis er nok til å skille et ruteproblem fra et tilgangsproblem.

Skriv den smale tillatelsen, ikke den brede

Begrens tillatelsen til det godkjente administrative subnettet og grensesnittet som mottar tunnelens trafikk: ssh 10.10.5.0 255.255.255.0 inside. Koble den til en autentiseringsmetode som aaa authentication ssh console LOCAL og en navngitt lokal konto, i stedet for å åpne hver kilde på det ytre grensesnittet.

Hold grensesnitt-ACL-en og ssh-tillatelsen konsistente. En tillatelse for et subnett som ACL-en blokkerer, feiler fortsatt, og en ACL som tillater subnettet uten en samsvarende ssh-oppføring, feiler ved neste port. Begge utsagnene beskriver samme bane fra ulike lag, så gjennomgå dem sammen i den kjørende konfigurasjonen.

Verifiser fra den navngitte verten, og snevre inn igjen

Åpne en ny økt fra den navngitte administrasjonsverten i stedet for fra skrivebordet ditt, og bekreft på ASA-en hvilken kildeadresse og hvilket grensesnitt tilkoblingen brukte. Sjekk de aktive øktene og SSH-delen av den kjørende konfigurasjonen mens økten er oppe, lukk den deretter og fjern enhver midlertidig tillatelse du la til for testing. Hvis økten vises, men faller rett etter pålogging, er det gjenværende problemet autorisasjon og ikke tilgjengelighet. Noter grensesnittet og kilden i endringsloggen, slik at neste person ikke gjentar diagnosen.

Hold konsollen eller en annen uavhengig godkjent gjenopprettingsbane tilgjengelig gjennom hele endringen. Når den private banen virker, bekreft at offentlige kilder og urelaterte VPN-brukere ikke fikk samme tilgang, fordi en administrasjonsbane som virker for alle, er et annet problem enn det du startet med.