Quelle interface reçoit le NAT intérieur et extérieur sur une sortie VPN IOS

Les routeurs qui offrent une sortie Internet en tunnel complet font deux tâches qui ressemblent à une. Ils terminent le tunnel et transmettent le paquet client déchiffré vers Internet. Seule la seconde tâche demande une traduction, et celle-ci doit correspondre au flux interne. Cette distinction décide quelles interfaces portent les rôles NAT et quelle plage d'adresses apparaît dans la règle.

Suivez un paquet à travers le routeur

Prenez un client sur 10.90.0.25 qui ouvre un service HTTPS public. Que cette destination entre ou non dans le tunnel relève de la politique du client lui-même. Une fois qu'elle y entre, le routeur déchiffre le paquet et le remet à une interface virtuelle, d'où il est routé vers le lien montant public.

Cette interface virtuelle est l'intérieur de la traduction. Le lien montant public en est l'extérieur. Si les rôles sont inversés ou absents, le paquet sort avec une source privée ou il est abandonné avant d'être traduit.

Adaptez la politique de traduction au pool de clients

La règle NAT doit nommer la plage que les clients reçoivent réellement, pas le LAN du bureau qui partage par hasard le même lien montant. Une règle qui ne couvre que le sous-réseau local manque les clients distants, même lorsque les deux sortent par la même interface.

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

Gardez les exceptions des sites privés à part. Le trafic vers des destinations internes doit conserver sa source d'origine, sinon la destination répondra à une adresse qu'elle ne peut pas atteindre et le trajet retour échouera d'une manière qui ressemble à une boucle de routage.

Appliquez les rôles aux interfaces réelles du design déployé. Un fragment Virtual-Template copié d'une ancienne réponse Easy VPN n'est pas une configuration actuelle complète, et le type de tunnel utilisé détermine quelle interface reçoit le paquet déchiffré.

Séparez le transport externe de la traduction interne

Traduire une source applicative déchiffrée n'est pas la même opération que pousser des paquets IKE ou protégés à travers un équipement NAT en amont. La première change ce qu'Internet voit comme source de la requête du client ; la seconde maintient un tunnel vivant à travers un intermédiaire.

Les confondre produit deux échecs classiques. Un routeur qui traduit son propre transport de tunnel casse la relation avec le pair, tandis qu'un routeur qui ne traduit jamais le flux interne transmet des adresses privées vers Internet. Lisez quel flux vous regardez avant de modifier une règle, et vérifiez si le tunnel est resté monté après le changement. Une règle qui répare la navigation tout en faisant tomber le tunnel a déplacé le problème au lieu de le résoudre.

Aucun des deux échecs ne se corrige en changeant l'autre. Lisez quel flux vous regardez avant de modifier une règle.

Vérifiez aux deux frontières

Lisez la source applicative à la frontière Internet, et la destination restaurée sur le trajet retour. La première dit si la traduction a eu lieu ; la seconde dit si le mappage inverse est revenu au bon client.

Testez ensuite un client qui utilise un chemin de tunnel divisé approuvé. Ce client n'exerce jamais la traduction Internet de ce routeur, il devrait donc se comporter différemment, et la différence confirme quel chemin le trafic a pris.

Si les deux clients se comportent à l'identique, la politique de tunnel divisé ne fait pas ce que le design annonce. Corrigez cela avant d'ajouter d'autres règles de traduction, car une règle écrite pour un chemin inutilisé masque le vrai problème.