ASA hairpin : sortie internet ou branche VPN site à site ?

Deux utilisateurs d’accès distant derrière le même ASA peuvent envoyer du trafic par la même interface externe et recevoir un traitement complètement différent. L’un va vers un site web public, donc le paquet a besoin d’une traduction de source et d’une route internet. L’autre va vers un serveur derrière un tunnel site à site qui se termine aussi sur cette interface, donc le paquet a besoin d’une identité, d’un sélecteur de tunnel correspondant et d’un chemin de retour vers le pool de clients. L’autorisation pour la même interface est une condition préalable pour les deux et une solution pour aucune.

Deux branches, une interface

Décidez quelle branche vous construisez avant de saisir une règle NAT, car les règles ne sont pas interchangeables. La branche A est du client vers internet : l’adresse du pool entre, l’adresse publique traduite sort, retour par la même interface. La branche B est du client vers un préfixe privé de l’autre côté d’un autre pair IPsec : l’adresse du pool est conservée, rechiffrée et livrée à un pair qui doit savoir comment répondre au pool.

Ce dont les deux ont besoin d’abord, c’est l’autorisation pour la même interface. Sans elle, l’ASA refuse de transmettre un paquet par l’interface par laquelle il est arrivé, et la panne ressemble à un problème de routage plutôt qu’à un problème de stratégie :

same-security-traffic permit intra-interface

Cette seule ligne autorise un schéma de transmission, comme le décrit la référence NAT de l’ASA pour les chemins par la même interface. Elle n’ajoute pas de route client, n’autorise aucune ressource, ne traduit aucune adresse et ne négocie aucun sélecteur IPsec ; attendez-vous donc à ajouter trois ou quatre choses de plus après elle et ne lisez pas son acceptation comme un progrès.

Branche A : le client veut internet

Pour une sortie internet, l’adresse du pool doit cesser d’être privée avant que le paquet ne quitte l’équipement. Dans une conception PAT ordinaire, la règle traduit le pool vers l’adresse de l’interface externe, et l’état de retour rétablit le flux vers le client :

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Confirmez ensuite que le client a bien demandé à l’ASA de transporter ce trafic. Une exclusion du tunnel divisé envoie la destination publique par la connexion propre du téléphone, qui n’atteint jamais l’ASA, et aucune règle NAT ne répare un paquet qui n’a jamais été envoyé. Comparez la liste de tunnel divisé de la stratégie de groupe avec la destination que vous testez.

Le reste de la branche est ordinaire : une route par défaut ou spécifique utilisable depuis l’interface externe, une stratégie d’accès qui autorise le flux, et le DNS traité selon la stratégie de résolveur choisie. Ajoutez route-lookup ici pour la même raison que ci-dessous, puisque les interfaces d’entrée et de sortie sont identiques.

Branche B : le client veut un site privé

Cette branche échoue à plus d’endroits, alors écrivez-la dans l’ordre. D’abord la route du client : le préfixe de destination doit figurer dans la liste de tunnel divisé, sinon le client ne le placera pas dans le tunnel. Ensuite le sélecteur de tunnel : l’ACL de chiffrement site à site doit couvrir l’adresse du pool vers le préfixe distant, pas seulement le LAN local vers le préfixe distant. Enfin l’identité, pour que l’adresse du pool ne soit pas traduite vers le PAT internet au passage.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

Le côté distant est la partie que les gens oublient de tester. Le pair a besoin d’une route de retour vers le pool et d’un sélecteur qui l’inclut, et sa propre stratégie doit autoriser les adresses source qu’il verra. Si le site est utilisé via une vue traduite, c’est une conception valable, mais alors les deux pairs, les deux sélecteurs et les deux tables de routage doivent s’accorder sur les adresses traduites.

Vérifiez aussi l’ordre des règles. Une règle PAT large au-dessus de la règle d’identité traduira l’échange privé avant même que la règle d’identité soit évaluée, et le symptôme est un tunnel de site sans SA correspondant plutôt qu’une erreur NAT.

Le test qui vous dit quelle branche vous avez construite

Utilisez l’évaluation de chemin de l’ASA lui-même au lieu de lire la configuration en espérant. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed affiche la décision NAT, la route et le résultat ACL pour un flux ; répétez avec une destination privée. Si la phase NAT réécrit un flux privé à privé, vous avez construit la branche A pour un paquet qui avait besoin de la branche B.

Deux autres commandes comblent l’écart. show nat detail imprime l’ordre des règles suivi par packet-tracer, et show crypto ipsec sa montre si un sélecteur existe pour la paire attendue. Un SA manquant est un problème de configuration de sélecteur ou de pair, pas quelque chose que la règle NAT peut réparer.

Vérifiez chaque branche avec le trafic qu’elle sert

Acceptez la branche A avec une requête publique ordinaire du client, et la branche B avec une requête vers une ressource privée qui existe réellement. Répétez ensuite chacune avec une ressource refusée, car « autorisé » et « permis par la stratégie d’accès » ne sont pas la même preuve, et un ping émis depuis le concentrateur n’exerce aucun des deux chemins client.

Gardez les deux enregistrements de test séparés dans le ticket : adresse source, destination, règle NAT qui a correspondu et résultat. Quand le prochain rapport dira « le VPN est cassé », cette paire vous dit en une minute quelle branche a régressé, et la réponse est généralement une route ou un sélecteur plutôt que la ligne de la même interface que tout le monde soupçonne d’abord.