Blog CCIE

Bonjour à tous,

Cela fait un moment que je n’avais pas écrit sur cet espace, ma préparation pour le lab s’intensifie de jours en jours. Je sens que je deviens de plus en plus confiant sur les technologies et la juste interprétation des tâches. Je posterais des détails dans la foulée après cet article.

Mais pour l’instant, parlons d’un mode d’implémentation qui m’a, à première vue choqué mais qui se révèle au final très logique, vous allez le voir.

« Faites du NAT on a stick sans VLAN! »

Lorsque vous pensez à la translation d’adresse, vous pensez à la translation statique et dynamique surchargée(PAT avec overload) entre zones inside et outside. Vous pouvez l’appliquer sur des ports physiques ou des sous-interfaces de VLAN sur un routeur. Jusque là rien de bien exceptionnel.

L’énoncé nous demande de faire du NAT on a stick sans utiliser de sous-interfaces et donc de VLAN. Vous avez bien lu. Il faut que le routeur soit capable de faire de la translation d’adresse sur un même port physique! Regardons la topologie pour avoir plus de détail sur ce qui nous attend.

Topologie

D’emblée, la topologie peut vous sembler très très étrange, notamment sur le plan d’adressage.

L’interface physique FastEthernet0/0 du routeur R1 est « connectée » à deux sous-réseaux en même temps, 172.16.0.0/24 et 155.2.0.0/24. Le tout relié par un switch qui ne supporte pas, dans le scénario, le tagging dot1q ou plus généralement les VLAN.

Le but de la tâche est de permettre au réseau 172.16.0.0/24 de communiquer avec R3 sans que celui-ci n’ait connaissance de ce préfixe. La tâche nous oblige également à « masquer » ce subnet derrière uniquement l’IP d’interface de R1 reliant R3(155.2.0.1/24), ce qui nous aiguille vers de l’overload.

Tout cela va être rendu possible par deux composants, le PBR(Policy-Based Routing) et les adresses secondaires.

Implémentation

Pour la bonne compréhension de chacune des étapes nous permettant de répondre à ce besoin, abordons de façon ordonnée les choses.

Première étape – Affectation de plusieurs IPs sur une interface physique

Comme vous le savez, une interface physique d’un routeur peut contenir une adresse principale et plusieurs secondaires.

Dans ce cas, l’adresse principale sera portée sur le subnet 155.2.0.0/24 pour les besoins de notre implémentation future. La seconde sera donc portée sur le subnet 172.16.0.0/24.

! On R1
interface FastEthernet0/0
 ip address 172.16.0.1 255.255.255.0 secondary
 ip address 155.2.0.1 255.255.255.0

Deuxième étape – Définition d’une interface Loopback et des zones inside/outside

Et c’est là où va être l’astuce!

On va tout simplement sur R1 définir une interface de Loopback avec une adresse IP quelconque pour pouvoir re-router le traffic entrant de la classe 172.16.0.0/24 vers celle-ci.

L’interêt prend tout son sens lorsque vous considerez que l’interface de Loopback se trouvera dans la zone inside alors que l’interface principale se trouvera dans la zone outside.

Pour bien voir comment la PBR va entrer en jeu, analysons le traitement prévu du traffic :

1. R1 recoit du traffic provenant de 172.16.0.0/24
2. R1 re-route celui-ci, grâce à une PBR vers l’interface Loopback0 et rentre dans la zone de NAT inside
3. R1 analyse la règle de NAT configurée et translate la source vers l’IP d’interface primaire de fa0/0, configurée en NAT outside

On se sert donc d’une interface de Loopback quelconque pour faire entrer notre traffic dans la zone inside et le translater comme si de rien n’était.

Notez encore une fois que l’adresse IP définie sur l’interface de Loopback n’a aucun impact sur le NAT en lui-même et ne modifie en rien les informations source/destination de couche 3 des paquets aménés à être translatés.

Passons à l’implémentation maintenant de cette étape!

! On R1
int lo0
ip add 150.2.1.1 255.255.255.0
ip nat inside
!
ip access-list standard SUBNET_TO_NAT
permit 172.16.0.0 0.0.0.255
!
route-map PBR permit 10
match ip address SUBNET_TO_NAT
set interface Loopback0
!
int fa0/0
ip policy route-map PBR
ip nat outside
!
ip nat inside source list SUBNET_TO_NAT interface FastEthernet0/0 overload

La configuration est ici assez simple quand vous avez compris le mécanisme.

Vérification

Pour vérifier si tout cela fonctionne, rajoutons une route par défaut pointant vers R1 sur R2 et essayons d’envoyer un ping à destination de R3, 155.2.0.3.

! On R2
ip route 0.0.0.0 0.0.0.0 172.16.0.1
R2#ping 155.2.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.2.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/35/44 ms
R2#

Observons ce qui s’est passé sur R1 maintenant.

R1#deb ip nat 
IP NAT debugging is on
*Mar 1 00:01:42.371: NAT: s=172.16.0.2->155.2.0.1, d=155.2.0.3 [10]
*Mar 1 00:01:42.383: NAT*: s=155.2.0.3, d=155.2.0.1->172.16.0.2 [10]
*Mar 1 00:01:42.407: NAT: s=172.16.0.2->155.2.0.1, d=155.2.0.3 [11]
*Mar 1 00:01:42.427: NAT*: s=155.2.0.3, d=155.2.0.1->172.16.0.2 [11]
*Mar 1 00:01:42.447: NAT: s=172.16.0.2->155.2.0.1, d=155.2.0.3 [12]
*Mar 1 00:01:42.471: NAT*: s=155.2.0.3, d=155.2.0.1->172.16.0.2 [12]
*Mar 1 00:01:42.491: NAT: s=172.16.0.2->155.2.0.1, d=155.2.0.3 [13]
*Mar 1 00:01:42.511: NAT*: s=155.2.0.3, d=155.2.0.1->172.16.0.2 [13]
*Mar 1 00:01:42.535: NAT: s=172.16.0.2->155.2.0.1, d=155.2.0.3 [14]
*Mar 1 00:01:42.555: NAT*: s=155.2.0.3, d=155.2.0.1->172.16.0.2 [14]

Comme vous pouvez le voir sur la première ligne de debug, la source du paquet ICMP 172.16.0.2 est translatée avec l’IP primaire de l’interface FastEthernet0/0 155.2.0.1, la destination reste intacte.

La deuxième ligne de debug nous montre que la destination du paquet retour est bien translatée dans l’autre sens(la destination 155.2.0.1 redeviens 172.16.0.2).

Conclusion

Vous l’avez vu, cette solution ne s’invente pas car elle bouscule la vision fondamentale que vous avez du NAT, il suffit juste de l’avoir rencontré pour la connaître !

— Julien