SSH vers une ASA distante via le VPN de site : étape par étape

Vous pointez un client SSH vers l’adresse interne de l’ASA distante et la session meurt à la connexion. Le pare-feu répond depuis son propre site, le tunnel apparaît, et pourtant rien n’écoute sur le port 22. Dans la plupart de ces cas, le paquet n’atteint jamais l’admission de gestion, car le chemin testé n’a jamais été conçu comme un chemin de gestion. Suivez le flux ci-dessous dans l’ordre et la panne cesse de se déplacer.

Choisissez l’adresse que vous administrez réellement

Trois conceptions se ressemblent et se comportent différemment : atteindre l’adresse publique de l’ASA tournée vers le VPN, atteindre une interface interne via IPsec et atteindre une interface de gestion dédiée. Notez l’adresse source de l’administrateur, l’adresse de destination exacte et TCP 22 avant de toucher à une autorisation. Tout ce qui suit dépend de cette paire.

Un tunnel qui transporte deux VLAN de serveurs peut très bien ne pas transporter l’adresse de l’interface du pare-feu ni le sous-réseau de gestion de l’administrateur. Vérifiez la liste du trafic intéressant de la politique site à site et confirmez que l’adresse propre de l’ASA apparaît comme destination, et pas seulement les sous-réseaux qui le traversent.

Comme la destination est le pare-feu lui-même, l’admission de gestion est distincte des règles du trafic transféré. Une ACL qui laisse les clients atteindre les serveurs derrière l’ASA n’active pas à elle seule l’administration SSH de l’appareil, et corriger la règle de transfert ne déplacera pas cette panne.

management-access est propre à l’interface

La commande management-access demande à l’ASA d’accepter les connexions de gestion vers une interface nommée lorsqu’elles arrivent par le VPN. Elle ne crée pas de route, elle n’ajoute pas d’autorisation SSH et elle ne s’applique pas à toutes les interfaces à la fois. Si l’interface de destination n’est pas celle qui est nommée, la connexion est rejetée avant l’authentification.

Deux exclusions mordent ici. Les interfaces réservées à la gestion échappent à ce mécanisme, et le guide de gestion ASA 9.20 indique que la pile CiscoSSH par défaut ne prend pas en charge SSH entre interfaces via le VPN, alors que la pile ASA SSH le fait. Confirmez la pile active sur la version déployée avant de consacrer du temps aux routes.

Quatre portes avant l’invite de connexion

Entre le client et l’invite de nom d’utilisateur se tiennent quatre portes indépendantes : une correspondance de route et de tunnel pour la paire de gestion, une ACL d’interface qui autorise TCP 22 vers l’adresse de l’ASA, une autorisation ssh couvrant la source de l’administrateur et une authentification AAA pour cet utilisateur. Chacune peut rejeter le paquet sans dire au client quelle porte s’est fermée.

Utilisez packet-tracer pour voir quelle porte échoue avant de changer quoi que ce soit : packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. La trace nomme l’ACL, l’étape NAT et la décision to-the-box, ce qui suffit généralement à séparer un problème de routage d’un problème d’admission.

Écrivez l’autorisation étroite, pas la large

Limitez l’autorisation au sous-réseau administratif approuvé et à l’interface qui reçoit le trafic du tunnel : ssh 10.10.5.0 255.255.255.0 inside. Associez-la à une méthode d’authentification comme aaa authentication ssh console LOCAL et à un compte local nommé, plutôt que d’ouvrir toutes les sources sur l’interface externe.

Gardez l’ACL d’interface et l’autorisation ssh cohérentes. Une autorisation pour un sous-réseau que l’ACL bloque échoue quand même, et une ACL qui autorise le sous-réseau sans entrée ssh correspondante échoue à la porte suivante. Les deux énoncés décrivent le même chemin depuis des couches différentes, examinez-les donc ensemble dans la configuration en cours.

Vérifiez depuis l’hôte nommé, puis resserrez encore

Ouvrez une nouvelle session depuis l’hôte de gestion nommé plutôt que depuis votre bureau, et confirmez sur l’ASA quelle adresse source et quelle interface la connexion a utilisées. Consultez les sessions actives et la section SSH de la configuration en cours pendant que la session est ouverte, puis fermez-la et retirez toute autorisation temporaire ajoutée pour les tests. Si la session apparaît mais tombe juste après la connexion, le problème restant est l’autorisation et non l’accessibilité. Notez l’interface et la source dans le journal des changements pour que la personne suivante ne répète pas le diagnostic.

Gardez la console ou un autre chemin de récupération approuvé indépendamment disponible pendant toute la modification. Une fois le chemin privé opérationnel, confirmez que les sources publiques et les utilisateurs VPN sans rapport n’ont pas obtenu le même accès, car un chemin de gestion qui fonctionne pour tout le monde est un problème différent de celui avec lequel vous avez commencé.