Un sous-réseau VPN hérite-t-il du niveau de sécurité de l’interface ASA ?

Quelqu’un demande si le sous-réseau VPN de l’agence est en « niveau de sécurité 0 ou 100 » sur l’ASA, et la question contient déjà l’erreur. Le niveau de sécurité est une propriété d’une interface locale, attribué de 0 à 100 dans la configuration de l’interface. Un sous-réseau distant qui arrive par un tunnel n’en acquiert aucun, quelle que soit la façon dont la crypto map est écrite. C’est pourquoi la question n’a pas de réponse numérique.

La question pratique qui suit est meilleure : quelle politique admet l’agence vers le serveur, et laquelle la tient à l’écart du pare-feu lui-même. Ce sont deux réponses, et la procédure ci-dessous les sépare.

Les niveaux de sécurité appartiennent aux interfaces

Exécutez show running-config interface et vous verrez security-level sous chaque interface physique ou interface VLAN, pas sous le groupe de tunnels ni la crypto map. L’autorisation par défaut du plus haut vers le plus bas est évaluée entre ces interfaces, et c’est pourquoi le chiffre change le comportement de l’inspection et de l’ACL implicite sur le chemin auquel il appartient.

Pour un flux VPN déchiffré, l’entrée reste l’interface outside où le tunnel se termine, et la sortie est l’interface inside vers le serveur. Notez les deux avant de toucher à quoi que ce soit. Cette seule étape élimine l’essentiel de la confusion, car elle transforme une question de confiance abstraite en paire d’interfaces.

Le contournement d’ACL a une frontière nommée

sysopt connection permit-vpn est le réglage dont les gens se souviennent à moitié quand ils disent que le trafic VPN ignore les ACL. Il contourne bien l’ACL de l’interface pour le trafic qui est qualifié de trafic VPN, et le guide des paramètres 9.x le limite par interface et par direction au lieu de déclarer une exception globale.

Vérifiez ce qui est configuré avant de raisonner de mémoire :

• show running-config all sysopt pour voir la valeur effective, pas seulement les lignes non par défaut.
• show running-config access-group pour voir quelle ACL est appliquée à quelle interface et dans quelle direction.
• show vpn-sessiondb detail l2l pour confirmer quel groupe de tunnels et quel filtre la session utilise réellement.

Désactiver ce réglage pour durcir l’accès VPN est un changement à fort impact. Il resoumet chaque flux VPN qualifié à l’ACL extérieure, ce qui casse généralement des tunnels qui fonctionnaient d’une manière sans rapport avec l’agence dont on vous a parlé.

Lisez le filtre attaché à la session

Le vrai contrôle par tunnel est le filtre VPN : une ACL référencée par une politique de groupe ou par un nom d’utilisateur, appliquée après le déchiffrement et avant le chiffrement. Un filtre au niveau utilisateur remplace la valeur au niveau du groupe, de sorte que deux personnes du même groupe de tunnels peuvent avoir un accès effectif différent.

Confirmez la priorité au lieu de la supposer. show running-config group-policy <name> affiche la valeur du groupe, et show running-config username <name> indique si une valeur par utilisateur existe. Si les deux existent, la valeur utilisateur l’emporte. Comparez ensuite les entrées de cette ACL au flux qui vous intéresse, dans la direction où le filtre évalue.

Un filtre qui autorise le serveur d’application ne dit rien sur l’administration. Ce sont des règles distinctes sur un chemin distinct.

Vérifiez une autorisation et un refus

Packet-tracer est le moyen le plus rapide de voir la décision sans attendre qu’un utilisateur la signale. Donnez-lui le flux du côté déchiffré et laissez-le nommer les étapes ACL, NAT et inspection qu’il traverse.

1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
2. Lisez la ligne de résultat : elle nomme l’ACL qui a autorisé ou rejeté le paquet.
3. Répétez avec la destination d’administration sur l’interface inside et confirmez un refus.
4. Répétez encore une fois après tout changement, afin que l’état avant et l’état après soient tous deux enregistrés.

Vérifiez ensuite avec du trafic réel : une requête applicative réussie depuis l’agence et une tentative SSH échouée vers l’ASA. Packet-tracer modélise le chemin ; un flux réel prouve que le modèle correspondait.

Annulez le changement qui l’a fait fonctionner

Si le correctif consistait à désactiver le contournement d’ACL ou à élargir un filtre, conservez la configuration précédente. Une capture show run des objets concernés, enregistrée avant le changement, suffit à les restaurer ; la configuration ASA est orientée lignes, donc revenir en arrière signifie ressaisir les anciennes lignes, pas restaurer un fichier.

Consignez la paire d’interfaces, le filtre effectif, le nom de l’ACL issu de packet-tracer et les commandes exactes que vous avez modifiées. Cette trace transforme la prochaine revue en vérification de cinq minutes au lieu d’un nouveau débat sur les niveaux de confiance.