NAT d'identité ASA contre exclusion NAT IOS pour le trafic VPN

Une agence conserve un PAT internet et un VPN site à site sur la même passerelle Cisco, et le VPN cesse de fonctionner dès que le NAT est ajouté. Les adresses à l'intérieur du tunnel ne correspondent plus à ce que protège l'ACL crypto, ou le pair voit des adresses traduites pour lesquelles il n'a pas de route. Cisco résout cela à deux endroits : l'ASA sélectionne une règle NAT qui associe une adresse à elle-même, tandis qu'IOS garde le flux hors d'une règle de traduction via un deny dans l'ACL. Les deux préservent les adresses d'origine, et aucune n'est un contournement du traitement NAT.

Consignez le flux avant de choisir une règle

Commencez par écrire le flux que vous comptez protéger : source du LAN, destination distante et la paire d'adresses exacte que protège la stratégie IPsec. Faites-le avant de modifier une règle, car le tuple indique quel classificateur ou quelle règle NAT aurait dû correspondre.

Cherchez ensuite la règle qui a réellement correspondu, pas celle que vous visiez. Sur les deux plateformes, le NAT est évalué dans un ordre, et une règle antérieure peut l'emporter avant que votre exception soit examinée. Une exception qui semble correcte mais perd face à une autre règle ne remet jamais le paquet attendu à la stratégie de protection. Le symptôme est identique à une exception absente, c'est pourquoi l'ordre des règles doit être lu avant de changer la configuration.

Le NAT d'identité ASA est une règle, pas un contournement

Sur l'ASA, le NAT d'identité est une règle NAT dont l'adresse traduite est égale à l'originale. Elle est sélectionnée comme toute autre règle et installe toujours une entrée de traduction, donc le paquet ne saute pas le traitement NAT. Ce qui change, c'est que les adresses sur le fil restent les mêmes, et c'est ce dont la stratégie IPsec a besoin.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

Les interfaces de la règle et son paramètre route-lookup doivent correspondre à la conception du transfert. Une règle qui associe correctement l'adresse mais s'applique à la mauvaise paire d'interfaces ne sera pas sélectionnée pour votre flux. Route-lookup décide si le paquet traduit est routé ou si la destination d'origine est utilisée, et cela détermine si le trafic de retour revient par le tunnel.

L'accès de gestion à l'ASA lui-même est un cas distinct. Si vous utilisez le NAT d'identité pour le trafic de gestion, l'exigence route-lookup propre à la version s'applique, et une exception large copiée d'un exemple VPN ne réparera pas SSH.

Un deny dans l'ACL NAT d'IOS signifie non sélectionné ici

Sur IOS, le NAT internet est piloté par une liste de sources, et cette ACL est un classificateur, pas un filtre. Une ligne permit sélectionne le trafic pour la traduction ; une ligne deny signifie que le paquet n'est pas sélectionné ici. Ce deny n'est pas un ordre de rejeter le paquet comme l'est un deny dans une ACL d'interface.

Non sélectionné ici est aussi plus étroit que jamais traduit nulle part. Une autre règle NAT, une autre interface ou une route-map peuvent encore traduire le flux, il faut donc lire toute la table NAT. Le paquet a aussi besoin d'une route, d'une ACL crypto correspondante et d'une autorisation aux frontières réelles du contrôle d'accès.

Un agencement IOS minimal place le deny au-dessus du permit dans la même liste et pointe la règle overload vers cette liste. L'ACL crypto protège alors la même paire que le deny exclut de la traduction.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Une question testable pour les deux modèles

Les deux modèles répondent à la même question : quelle règle a correspondu à ce flux, et quelles adresses ont quitté l'interface ? Capturez sur l'interface externe et comparez l'adresse source avant et après la passerelle. Vérifiez ensuite la vision du pair sur le tunnel, car l'SA peut être établie alors que le flux protégé est traduit ailleurs.

Sur l'ASA, affichez nat detail et la table de traduction ; sur IOS, affichez ip nat translations et les compteurs ACL correspondants. Une règle qui n'incrémente jamais n'a jamais été sélectionnée, ce qui désigne l'ordre, l'interface ou la direction plutôt que la configuration crypto.

Où la configuration se trompe habituellement

Les échecs courants sont mécaniques. Le deny se trouve sous le permit et ne correspond jamais. Le classificateur est appliqué dans le mauvais sens, si bien que le flux de retour est traduit. La règle d'identité couvre les bonnes adresses mais la mauvaise paire d'interfaces. L'ACL crypto protège un sous-réseau qui ne correspond plus à ce que présente la règle NAT.

Consignez la paire d'adresses d'origine et présentée à côté du responsable de la règle, afin que l'ingénieur suivant voie pourquoi un classificateur refuse la traduction alors que le pare-feu autorise l'application. Gardez cela dans le ticket de changement, pas dans une note personnelle. Relancez ensuite le flux après tout changement NAT, car l'ordre des règles fait partie de la configuration même lorsque le texte de la règle est inchangé. Un tunnel qui monte ne prouve pas que les adresses ont survécu ; seuls le paquet capturé et la vue décapsulée du pair le prouvent.