SSH naar een externe ASA via de site-VPN: stap voor stap

Je richt een SSH-client op het interne adres van de externe ASA en de sessie sterft bij het verbinden. De firewall antwoordt vanaf zijn eigen site, de tunnel verschijnt en toch luistert er niets op poort 22. In de meeste van deze gevallen bereikt het pakket nooit de beheerstoelating, omdat het pad dat wordt getest nooit als beheerpad is ontworpen. Volg de onderstaande stroom in volgorde en de storing houdt op met verschuiven.

Kies het adres dat je werkelijk beheert

Drie ontwerpen lijken op elkaar en gedragen zich anders: het openbare, naar de VPN gerichte adres van de ASA bereiken, een interne interface via IPsec bereiken en een speciale beheerinterface bereiken. Noteer het bronadres van de beheerder, het exacte bestemmingsadres en TCP 22 voordat je een machtiging aanraakt. Alles daarna hangt van dat paar af.

Een tunnel die twee server-VLAN's draagt, draagt misschien helemaal niet het interfaceadres van de firewall of het beheersubnet van de beheerder. Controleer de lijst met interessant verkeer voor het site-naar-sitebeleid en bevestig dat het eigen adres van de ASA als bestemming verschijnt, niet alleen de subnetten die erdoorheen gaan.

Omdat de bestemming de firewall zelf is, staat beheerstoelating los van regels voor doorgestuurd verkeer. Een ACL die clients naar servers achter de ASA laat komen, schakelt niet zelfstandig SSH-beheer van het apparaat in, en het repareren van de doorstuurregel verplaatst deze storing niet.

management-access is interface-specifiek

Het commando management-access vertelt de ASA om beheerverbindingen naar een genoemde interface te accepteren wanneer ze via VPN binnenkomen. Het maakt geen route, het voegt geen SSH-machtiging toe en het geldt niet voor elke interface tegelijk. Als de bestemmingsinterface niet de genoemde is, wordt de verbinding vóór authenticatie weggegooid.

Twee uitsluitingen bijten hier. Interfaces die alleen voor beheer zijn, vallen buiten dit mechanisme, en de beheergids voor ASA 9.20 merkt op dat de standaard CiscoSSH-stack SSH tussen interfaces via VPN niet ondersteunt, terwijl de ASA SSH-stack dat wel doet. Bevestig de actieve stack op de uitgerolde versie voordat je tijd aan routes besteedt.

Vier poorten vóór de inlogprompt

Tussen de client en de gebruikersnaamprompt staan vier onafhankelijke poorten: een route- en tunnelovereenkomst voor het beheerpaar, een interface-ACL die TCP 22 naar het ASA-adres toestaat, een ssh-machtiging die de bron van de beheerder dekt, en AAA-authenticatie voor die gebruiker. Elk daarvan kan het pakket laten vallen zonder de client te vertellen welke poort is gesloten.

Gebruik packet-tracer om te zien welke poort faalt voordat je iets wijzigt: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. De trace noemt de ACL, de NAT-fase en de to-the-box-beslissing, wat meestal genoeg is om een routeringsprobleem van een toelatingsprobleem te scheiden.

Schrijf de smalle machtiging, niet de brede

Beperk de machtiging tot het goedgekeurde administratieve subnet en de interface die het tunnelverkeer ontvangt: ssh 10.10.5.0 255.255.255.0 inside. Koppel deze aan een authenticatiemethode zoals aaa authentication ssh console LOCAL en een benoemd lokaal account, in plaats van elke bron op de buiteninterface te openen.

Houd de interface-ACL en de ssh-machtiging consistent. Een machtiging voor een subnet dat de ACL blokkeert, faalt nog steeds, en een ACL die het subnet toestaat zonder overeenkomende ssh-regel faalt bij de volgende poort. Beide uitspraken beschrijven hetzelfde pad vanuit verschillende lagen, dus bekijk ze samen in de actieve configuratie.

Verifieer vanaf de genoemde host en vernauw daarna opnieuw

Open een nieuwe sessie vanaf de genoemde beheerhost in plaats van vanaf je bureau, en bevestig op de ASA welk bronadres en welke interface de verbinding gebruikte. Controleer de actieve sessies en het SSH-gedeelte van de actieve configuratie terwijl de sessie open is, sluit deze daarna en verwijder elke tijdelijke machtiging die je voor het testen hebt toegevoegd. Als de sessie verschijnt maar direct na het inloggen wegvalt, is het resterende probleem autorisatie en niet bereikbaarheid. Noteer de interface en de bron in het wijzigingslog zodat de volgende persoon de diagnose niet herhaalt.

Houd de console of een ander onafhankelijk goedgekeurd herstelpad beschikbaar gedurende de hele wijziging. Zodra het privépad werkt, bevestig dat openbare bronnen en niet-verwante VPN-gebruikers niet dezelfde toegang hebben gekregen, want een beheerpad dat voor iedereen werkt is een ander probleem dan het probleem waarmee je begon.