SSH a una ASA remota a través del VPN del lloc: pas a pas

Apunteu un client SSH a l’adreça interna de l’ASA remota i la sessió mor en connectar. El tallafoc respon des del seu propi lloc, el túnel apareix i, tot i així, no hi ha res que escolti al port 22. En la majoria d’aquests casos el paquet no arriba mai a l’admissió de gestió, perquè el camí que es prova mai no es va dissenyar com a camí de gestió. Seguiu el flux de sota en ordre i la fallada deixa de moure’s.

Trieu l’adreça que realment administreu

Tres dissenys semblen iguals i es comporten de manera diferent: arribar a l’adreça pública de l’ASA orientada al VPN, arribar a una interfície interna mitjançant IPsec i arribar a una interfície de gestió dedicada. Anoteu l’adreça d’origen de l’administrador, l’adreça exacta de destinació i TCP 22 abans de tocar cap permís. Tot el que ve després depèn d’aquesta parella.

Un túnel que transporta dues VLAN de servidors pot no transportar gens l’adreça de la interfície del tallafoc ni la subxarxa de gestió de l’administrador. Reviseu la llista de trànsit interessant de la política de lloc a lloc i confirmeu que l’adreça pròpia de l’ASA apareix com a destinació, no només les subxarxes que hi passen.

Com que la destinació és el mateix tallafoc, l’admissió de gestió és independent de les regles per al trànsit reenviat. Una ACL que permet als clients arribar als servidors darrere de l’ASA no habilita per si sola l’administració SSH de l’aparell, i arreglar la regla de reenviament no mourà aquesta fallada.

management-access és específica de la interfície

L’ordre management-access diu a l’ASA que accepti connexions de gestió en una interfície concreta quan arriben pel VPN. No crea cap ruta, no afegeix cap permís SSH i no s’aplica a totes les interfícies alhora. Si la interfície de destinació no és la indicada, la connexió es descarta abans de l’autenticació.

Aquí hi ha dues exclusions. Les interfícies només de gestió queden fora d’aquest mecanisme, i la guia de gestió d’ASA 9.20 assenyala que la pila CiscoSSH per defecte no admet SSH entre interfícies pel VPN, mentre que la pila ASA SSH sí que ho fa. Confirmeu la pila activa a la versió desplegada abans de dedicar temps a les rutes.

Quatre portes abans de l’indicador d’inici de sessió

Entre el client i l’indicador de nom d’usuari hi ha quatre portes independents: una coincidència de ruta i túnel per a la parella de gestió, una ACL d’interfície que permet TCP 22 cap a l’adreça de l’ASA, un permís ssh que cobreix l’origen de l’administrador i una autenticació AAA per a aquest usuari. Cadascuna pot descartar el paquet sense dir al client quina porta s’ha tancat.

Feu servir packet-tracer per veure quina porta falla abans de canviar res: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. El traçat nomena l’ACL, l’etapa NAT i la decisió to-the-box, cosa que normalment n’hi ha prou per separar un problema d’encaminament d’un problema d’admissió.

Escriviu el permís estret, no el permís ampli

Limiteu el permís a la subxarxa administrativa aprovada i a la interfície que rep el trànsit del túnel: ssh 10.10.5.0 255.255.255.0 inside. Aparelleu-lo amb un mètode d’autenticació com aaa authentication ssh console LOCAL i un compte local amb nom, en lloc d’obrir tots els orígens a la interfície externa.

Manteniu l’ACL d’interfície i el permís ssh coherents. Un permís per a una subxarxa que l’ACL bloqueja encara falla, i una ACL que permet la subxarxa sense una entrada ssh corresponent falla a la porta següent. Totes dues declaracions descriuen el mateix camí des de capes diferents, així que reviseu-les juntes a la configuració en execució.

Verifiqueu des de l’amfitrió indicat i torneu a estrènyer

Obriu una sessió nova des de l’amfitrió de gestió indicat en lloc de la vostra taula, i confirmeu a l’ASA quina adreça d’origen i quina interfície ha fet servir la connexió. Reviseu les sessions actives i la secció SSH de la configuració en execució mentre la sessió està oberta, després tanqueu-la i traieu qualsevol permís temporal que hàgiu afegit per a les proves. Si la sessió apareix però cau just després d’iniciar-la, el problema restant és d’autorització i no d’abast. Registreu la interfície i l’origen al registre de canvis perquè la propera persona no repeteixi el diagnòstic.

Mantingueu la consola o un altre camí de recuperació aprovat de manera independent disponible durant tot el canvi. Quan el camí privat funcioni, confirmeu que les fonts públiques i els usuaris de VPN no relacionats no han obtingut el mateix accés, perquè un camí de gestió que funciona per a tothom és un problema diferent del que vau començar.