Configuration Du NAT Sur Un Routeur Cisco en PDF [PDF]

Zitiervorschau

Configuration du NAT sur un routeur Cisco De Steve De Jongh | 6 avril 2013 | Cisco, La pratique Quand il s’agit d’interconnecter un réseau privé (que ce soit d’entreprise ou particulier), en IPv4, il est pratiquement impossible de se passer du NAT. Voici donc une configuration qui reprend l’essentiel des trois principaux types de NAT que l’on peut configurer, à savoir:   

Le NAT statique Le NAT dynamique avec pool d’adresses Le NAT dynamique avec surcharge (NAT overload, aussi connu sous le nom de PAT)

Topologie du labo

Le labo est divisé en deux parties, le côté privé (réseau de l’entreprise) et le côté publique (le FAI et Internet). Le routeur ISP (qui représente le FAI), n’a aucune connaissance des réseaux privés de l’entreprise et ne peut donc rien router à destination des réseaux 192.168.x.x. (comme défini dans la RFC1918). Ces adresses sont réservées pour l’utilisation dans les réseaux privés. Il en va de même pour toutes les adresses faisant parties des plages suivantes:   

10.0.0.0/8 (de 10.0.0.0 à 10.255.255.255) 172.16.0.0/12 (de 172.16.0.0 à 172.31.255.255) 192.168.0.0/16 (de 192.168.0.0 à 192.168.255.255)

Dès lors, nous allons configurer le NAT afin de permettre un accès à Internet (simulé par l’adresse 8.8.8.8/32 configurée sur une interface loopback d’ISP):   

Le réseau 192.168.0.0/24 utilisera du NAT dynamique avec surcharge. Le réseau 192.168.1.0/24 utilisera du NAT avec pool d’adresse. La machine 192.168.1.100 sera accessible depuis le réseau publique grâce à une configuration de NAT statique.

1

Configuration de la topologie de base Sur ISP: Configuration de l’interface loopback ISP#conf t ISP(config)#int l0 ISP(config-if)#ip address 8.8.8.8 255.255.255.255 ISP(config-if)#exit

Configuration de la liaison sérielle vers R1 ISP(config)#int s0/0 ISP(config-if)#no shut ISP(config-if)#ip address 80.79.100.1 255.255.255.252 ISP(config-if)#exit

Configuration de la route vers le pool d’adresses publique ISP(config)#ip route 201.49.10.16 255.255.255.240 serial 0/0

Sur R1 : Configuration de l’interface sérielle vers ISP R1#conf t R1(config)#int s0/0 R1(config-if)#ip address 80.79.100.2 255.255.255.252 R1(config-if)#no shut R1(config-if)#exit

Configuration de l’interface du LAN1 R1(config)#int fa0/0 R1(config-if)#ip address 192.168.0.1 255.255.255.0 R1(config-if)#no shut R1(config-if)#exit

Configuration de l’interface du LAN2 R1(config)#int fa0/1 R1(config-if)#ip address 192.168.1.1 255.255.255.0 R1(config-if)#no shut R1(config-if)#exit

Configuration de la route par défaut R1(config)#ip route 0.0.0.0 0.0.0.0 serial 0/0

Pour le moment il est possible d’effectuer les tests suivants:   

Effectuer un ping depuis chaque PC vers R1 Effectuer un ping entre les PCs de LAN différent Effectuer un ping depuis R1 vers 8.8.8.8

2

Test de C1 à R1 VPCS[1]> ping 192.168.0.1 192.168.0.1 icmp_seq=1 ttl=255 192.168.0.1 icmp_seq=2 ttl=255 192.168.0.1 icmp_seq=3 ttl=255 192.168.0.1 icmp_seq=4 ttl=255 192.168.0.1 icmp_seq=5 ttl=255

time=70.000 time=54.000 time=67.000 time=65.000 time=63.000

ms ms ms ms ms

time=31.000 time=16.000 time=32.000 time=32.000 time=32.000

ms ms ms ms ms

Test de C1 à C2 VPCS[1]> ping 192.168.1.10 192.168.1.10 icmp_seq=1 ttl=63 192.168.1.10 icmp_seq=2 ttl=63 192.168.1.10 icmp_seq=3 ttl=63 192.168.1.10 icmp_seq=4 ttl=63 192.168.1.10 icmp_seq=5 ttl=63

Test de R1 à 8.8.8.8 R1#ping 8.8.8.8 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/29/112 ms

Par contre impossible par exemple pour C1 de communiquer avec 8.8.8.8 VPCS [1]> ping 8.8.8.8 8.8.8.8 icmp_seq=1 timeout 8.8.8.8 icmp_seq=2 timeout 8.8.8.8 icmp_seq=3 timeout 8.8.8.8 icmp_seq=4 timeout 8.8.8.8 icmp_seq=5 timeout

Configuration commune à tout type de NAT La première chose à faire lorsque l’on configure du NAT, quel qu’en soit le type, c’est d’indiquer au routeur où se situe le réseau privé et où se situe le réseau publique. Le NAT ne prend effet que lorsque qu’un paquet est routé d’une interface « inside » (côté privé) vers une interface « outside » (côté publique) et vice-versa. Dans notre cas, les interfaces Fa0/0 et Fa0/1 sont du côté privé et seront déclarées comme « inside », l’interface S0/0 par contre, étant du côté publique, sera configurée comme « outside ». R1(config)#int fa0/0 R1(config-if)#ip nat inside R1(config-if)#exit R1(config)#int fa0/1 R1(config-if)#ip nat inside R1(config-if)#exit R1(config)#int s0/0 R1(config-if)#ip nat outside R1(config-if)#exit

3

Configuration du NAT statique pour C3 Ce que nous allons configurer ici c’est une translation statique dans la table de translation NAT, ce qu’on appelle vulgairement sur du matériel domestique « ouvrir un port ». Nous allons explicitement indiquer au routeur que ce qui arrive sur son interface publique (S0/0) et dont l’adresse destination est 201.49.10.30 (une des adresse du pool publique) doit être redirigé vers 192.168.1.100. Du point de vue du routeur cela revient à modifier l’adresse IP destionation dans l’en-tête IPv4 avant de router le paquet. Cela signifie aussi que si C3 envoi un paquet vers internet, à la sortie de S0/0 de R1 l’adresse source (192.168.1.100) sera remplacée par l’adresse indiquée dans la translation, soit 201.49.10.30. R1(config)#ip nat inside source static 192.168.1.100 201.49.10.30

La table de translations NAT doit mainentant ressembler à ceci: R1#show ip nat translations Pro Inside global Inside local Outside local Outside global --- 201.49.10.30 192.168.1.100 ----R1#

A présent C3 doit pouvoir communiquer avec le réseau publique VPCS[3]> ping 8.8.8.8 8.8.8.8 icmp_seq=1 ttl=254 8.8.8.8 icmp_seq=2 ttl=254 8.8.8.8 icmp_seq=3 ttl=254 8.8.8.8 icmp_seq=4 ttl=254 8.8.8.8 icmp_seq=5 ttl=254

time=119.000 ms time=102.000 ms time=75.000 ms time=117.000 ms time=116.000 ms

Chaque paquet a donc été translaté, preuve en est la table de translations juste après l’émission de ces pings: R1#show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 201.49.10.30:33598 192.168.1.100:33598 8.8.8.8:33598 8.8.8.8:33598 icmp 201.49.10.30:33854 192.168.1.100:33854 8.8.8.8:33854 8.8.8.8:33854 icmp 201.49.10.30:34366 192.168.1.100:34366 8.8.8.8:34366 8.8.8.8:34366 icmp 201.49.10.30:34622 192.168.1.100:34622 8.8.8.8:34622 8.8.8.8:34622 icmp 201.49.10.30:34878 192.168.1.100:34878 8.8.8.8:34878 8.8.8.8:34878 --- 201.49.10.30 192.168.1.100 --- --R1#

On peut observer le résultat de la translation du côté de ISP aussi à l’aide de la commande « debug ip packet » qui va afficher le détail de chaque paquet IP traité par le routeur (Attention, dans un environnement réel cette commande peut gravement saturer le routeur). ISP#debug ip packet *Mar 1 02:22:49.491: IP: tableid=0, s=201.49.10.30 (Serial0/0), d=8.8.8.8 (Loopback0), routed via RIB *Mar 1 02:22:49.491: IP: s=201.49.10.30 (Serial0/0), d=8.8.8.8, len 92, rcvd 4 *Mar 1 02:22:49.495: IP: tableid=0, s=8.8.8.8 (local), d=201.49.10.30 (Serial0/0), routed via FIB *Mar 1 02:22:49.495: IP: s=8.8.8.8 (local), d=201.49.10.30 (Serial0/0), len 92, sending

4

Configuration du NAT avec pool d’adresses Pour l’instant seul C3 a accès au réseau publique, nous allons maintenant configurer un autre type de NAT pour le réseau 192.168.1.0/24 (à l’exception de C3). Ici, au lieu de configurer une translation statique, nous allons donner au routeur une plage d’adresses publiques (un pool d’adresse) dans laquelle il peut piocher pour créer dynamiquement les translations. Tout d’abord créons le pool d’adresses R1(config)#ip nat pool POOL-NAT-LAN2 201.49.10.17 201.49.10.30 netmask 255.255.255.240

Ici on crée donc une plage d’adresse nommée POOL-NAT-LAN2 allant de 201.49.10.17 à 201.49.10.30.Il nous faut ensuite définir quelles adresses IP sources seront susceptibles d’êtres translatées … pour cela il faut créer une ACL. R1(config)#access-list 1 deny 192.168.1.100 R1(config)#access-list 1 permit 192.168.1.0 0.0.0.255

On autorise donc à être translatées les adresses ip du réseau 192.168.1.0/24 sauf 192.168.1.100 (pour laquelle on a déjà une translation statique). Il ne reste plus qu’à configurer le NAT en lui même R1(config)#ip nat inside source list 1 pool POOL-NAT-LAN2

On instruit donc ici le routeur de créer dynamiquement une translation pour les paquets arrivant sur une interface « inside » routés par une interface « outside » dont l’adresse IP source correspond à l’ACL 1 et de remplacer l’IP source par une de celles comprises dans le pool POOL-NAT-LAN2. Attention, si il y a plus de machine dans le réseau privé que d’adresses publiques disponibles, il faut alors rajouter le mot clé « overload » à la commande: R1(config)#ip nat inside source list 1 pool POOL-NAT-LAN2 overload

Ceci permet de « partager » les adresses publiques en translatant également les numéros de ports dans l’entête de la couche transport (méthode communément appelée PAT). A présent C2 (et les autres machines qui seraient dans le réseau 192.168.1.0/24) peuvent communiquer avec l’extérieur. VPCS[2]> ping 8.8.8.8 8.8.8.8 icmp_seq=1 ttl=254 8.8.8.8 icmp_seq=2 ttl=254 8.8.8.8 icmp_seq=3 ttl=254 8.8.8.8 icmp_seq=4 ttl=254 8.8.8.8 icmp_seq=5 ttl=254

time=111.000 ms time=97.000 ms time=143.000 ms time=131.000 ms time=99.000 ms

La table de translation de R1 a maintenant une nouvelle entrée crée dynamiquement, mais qui réserve l’adresse publique pour C2 (tant que l’on ne purge pas la table NAT). R1#sh ip nat trans Pro Inside global Inside local Outside local Outside global --- 201.49.10.17 192.168.1.10 --- ----- 201.49.10.30 192.168.1.100 --- --R1#

5

Configuration du NAT dynamique avec surcharge (sans pool) Il reste encore à configurer R2 pour que le réseau 192.168.0.0/24 puisse accéder à l’extérieur. Pour cela nous allons configurer le troisième type de NAT, à savoir du NAT dynamique avec surcharge (overload) en utilisant l’adresse publique configurée sur l’interface S0/0 de R1. Notez que c’est la configuration la plus courante dans un réseau modeste (par exemple dans un réseau domestique). Cette méthode ne requiert pas d’obtenir de nouvelles adresses publiques auprès du provider. Nous devons cette fois aussi identifier les adresses sources à faire passer par le NAT, donc nous créons une nouvelle ACL. R1(config)#access-list 2 permit 192.168.0.0 0.0.0.255

Il ne reste plus qu’à configurer le NAT. R1(config)#ip nat inside source list 2 interface serial 0/0 overload

Nous disons ici au routeur de translater les paquets provenant des adresses décrites dans l’ACL 2 (192.168.0.0/24) et de remplacer l’adresse IP source par celle configurée sur l’interface Serial 0/0 en la surchargeant pour permettre à plus d’une machine de communiquer avec l’extérieur (PAT). C1 (ainsi que toute machine de ce réseau) peut communiquer avec l’extérieur désormais VPCS[1]> ping 8.8.8.8 8.8.8.8 icmp_seq=1 ttl=254 8.8.8.8 icmp_seq=2 ttl=254 8.8.8.8 icmp_seq=3 ttl=254 8.8.8.8 icmp_seq=4 ttl=254 8.8.8.8 icmp_seq=5 ttl=254

time=132.000 time=130.000 time=127.000 time=112.000 time=125.000

ms ms ms ms ms

Le « debug ip packets » sur ISP donne le résultat suivant ISP# *Mar 1 routed *Mar 1 *Mar 1 routed *Mar 1

03:11:46.195: via RIB 03:11:46.195: 03:11:46.199: via FIB 03:11:46.199:

IP: tableid=0, s=80.79.100.2 (Serial0/0), d=8.8.8.8 (Loopback0), IP: s=80.79.100.2 (Serial0/0), d=8.8.8.8, len 92, rcvd 4 IP: tableid=0, s=8.8.8.8 (local), d=80.79.100.2 (Serial0/0), IP: s=8.8.8.8 (local), d=80.79.100.2 (Serial0/0), len 92, sending

On voit là que c’est bien l’adresse de S0/0 qui est utilise pour remplacer l’IP source du paquet.

6

Configure NAT – GNS3 Lab To configure static NAT we need to complete these tasks: * Define the router’s interfaces as inside or outside: R0uter(config-if)#ip nat inside (or ip nat outside) * Define static mapping between the inside address and the outside address: R0uter(config)#ip nat inside source static + Static NAT: To make everything clear, we will configure static NAT in GNS3. Open your GNS3 and build a topology like this:

(IOS used: c2600-bin-mz.123-6f.bin but you can use other versions) We should use 3 routers in this topology but I want to save some RAM and demonstrate how to ping from the loopback interface so I only use two :) Therefore we should configure the loopback interface of R0 as the source IP address and the fa0/0 interface of R0 as the “outgoing static NAT” address. R0#configure terminal R0(config)#int loopback0 R0(config-if)#ip address 10.0.0.1 255.0.0.0 R0(config-if)#ip nat inside R0(config-if)#int f0/0 R0(config-if)#ip address 200.0.0.1 255.255.255.0 R0(config-if)#no shutdown R0(config-if)#ip nat outside R0(config-if)#exit Finally, we have to tell the router to translate my private IP 10.0.0.1 to public IP 200.0.0.2 so that I can go to the Internet! R0(config)#ip nat inside source static 10.0.0.1 200.0.0.2 In R1 we just assign the IP address and no shut its interface. R1#config terminal R1(config)#int f0/0 R1(config-if)#ip address 200.0.0.10 255.255.255.0 R1(config-if)#no shutdown Check if all things are right or not: R0#show ip nat translations 7

In this article we don’t use a host attached to R0 so if we want to test our NAT configuration we have to ping from R0′s loopback interface by using the ping extended command: We can use the extended ping command by typing only “ping” at the privileged mode, specify the “target IP address” and type “y” at the “Extended commands” and specify the “source address or interface” at shown below:

To approve NAT works well we can disable static NAT with the following command R0(config)#no ip nat inside source static 10.0.0.1 200.0.0.2 Now if we use the extended ping command (without NAT configured):

-> We can’t ping from the loopback interface. Download static NAT configuration: http://www.9tut.com/download/NAT_static_CCNA_self_study.zip + Dynamic NAT: To configure dynamic NAT we need to complete these tasks: 8

* Define a pool of addresses (public IP) to be used for dynamic NAT allocation Router(config)#ip nat pool pool_name start_ip end_ip { netmask netmask | prefix-length prefix-length } * Configure a standard access control list to define what internal traffic will be translated Router(config)#access-list access-list-number permit source [source-wildcard] Link the access list to the NAT pool Router(config)#ip nat inside source list access-list-number pool pool_name Define interfaces as either inside and outside Router(config-if)# ip nat inside (on fa0/0, for example) Router(config-if)#ip nat outside (on fa0/1, for example) * Dynamic NAT configuration example: RouterA(config)# access-list 1 permit 192.168.0.0 0.0.0.255 RouterA(config)# ip nat pool PoolforNAT 200.23.123.6 200.23.123.10 netmask 255.255.255.0 RouterA(config)# ip nat inside source list 1 pool PoolforNAT Note: In the above command, the word “inside” means “I want to NAT from inside to outside”; “list 1″ means “the source IP addresses to NAT are included in Access-list 1″; “pool PoolforNAT” means “NAT to the IP addresses specified in PoolforNAT”. RouterA(config)# int loopback0 RouterA(config-if)# ip nat inside RouterA(config-if)# int fa0/0 RouterA(config-if)# ip nat outside Configure PAT (NAT Overload) * Configure a standard access list to define what internal traffic will be translated * Link the access list to the interface to be used for PAT * Define interfaces as either inside or outside PAT router commands RouterA(config)# access-list 1 permit 192.168.0.0 0.0.0.255 RouterA(config)# ip nat inside source list 1 interface fa0/0 overload (Notice the “interface fa0/0″ means “NAT out of this interface” and the keyword overload for PAT in the above command) RouterA(config)# interface fa0/0 RouterA(config-if)# ip nat outside RouterA(config-if)# interface loopback0 RouterA(config-if)# ip nat inside

9

Configuration DHCP sur un routeur Cisco Le protocole DHCP (Dynamic Host Configuration Protocol) a pour fonctionnalité de fournir aux machines qui le demandent une configuration IP complète, adresse IPv4, masque de sous-réseau, passerelle par défaut, serveur dns… Cet article a pour sujet la configuration d’un routeur Cisco en serveur DHCP.

Topologie de la configuration

Nous allons ici réaliser la configuration de R1, routeur d’accès à internet du réseau et DHCP, routeur faisant office de serveur DHCP. Bien entendu les services DHCP auraient pu être configurés sur R1, mais pour des raisons didactiques j’ai choisi de séparer cette fonctionnalité. vous comprendre pourquoi plus tard dans l’article. La configuration ne reprendra que ce qui est relatif au DHCP, R1 est donc censé être configuré selon les besoins standards (adresses IPv4 sur les interfaces, route par défaut pointant vers ISP, et bien sûr un peu de NAT pour permettre l’accès au réseau publique).

Configuration initiale Afin d’éviter de finir avec un article de plusieurs pages de long, je ne mettrai ici que la configuration nécessaire. Les paramètres par défaut ne sont pas inclus. Sur ISP hostname ISP ! interface Loopback0 ip address 8.8.8.8 255.255.255.255 ! interface Serial0/0 ip address 80.100.200.1 255.255.255.252 clock rate 2000000

Sur R1 interface FastEthernet0/0

10

ip address 192.168.0.1 255.255.255.0 ip nat inside ip virtual-reassembly duplex auto speed auto ! interface Serial0/0 ip address 80.100.200.2 255.255.255.252 ip nat outside ip virtual-reassembly clock rate 2000000 ! interface FastEthernet0/1 ip address 192.168.1.1 255.255.255.0 ip nat inside ip virtual-reassembly duplex auto speed auto ! ip route 0.0.0.0 0.0.0.0 Serial0/0 ! ip nat inside source list 1 interface Serial0/0 overload ! access-list 1 permit any

Sur DHCP hostname DHCP ! interface FastEthernet0/0 ip address 192.168.1.5 255.255.255.0 duplex auto speed auto ! ip route 0.0.0.0 0.0.0.0 192.168.1.1

Attention, la route par défaut sur DHCP est nécessaire pour la suite de la configuration, j’en toucherai un mot plus loin.

Piqûre de rappel Le protocol DHCP est véhiculé directement dans une trame. De plus la machine qui émet une requête DHCP, n’ayant encore aucune identité (adresse IPv4 etc) n’a d’autre possibilité que de communiquer par broadcast. Cela signifie donc que la requête DHCP émise par cette machine est une trame broadcast. Cela peut paraître sans importance, mais il ne faut pas oublier qu’un broadcast est confiné dans son domaine de diffusion, autrement dit, il ne dépasse pas un routeur. Hors, ici, entre le serveur DHCP et le LAN1 il y a R1… un routeur! Nous devrons donc par la suite s’assurer que R1 soit configuré pour relayer la requête DHCP à destination du serveur DHCP.

Méthode de configuration Afin que DHCP puisse distribuer des adresses à la fois dans le LAN1 et dans le LAN2 nous allons devoir configurer les points suivants:

11

  

Exclure les adresses qu’on souhait ne pas distribuer (celle de la passerelle, ou de machines ayant des adresses fixes) Pour chaque LAN configurer un pool DHCP dans lequel on spécifiera les options (passerelle, serveur dns, adresse réseau, …) Configurer le relai DHCP pour le LAN1, sur R1.

La configuration La bonne pratique veut que l’on configure le serveur DHCP dans un ordre qui peut paraître illogique au premier abord. Ce qu’il faut savoir, c’est qu’une fois le pool DHCP configuré, le routeur va commencer à attribuer des adresses. Il est donc conseillé de configurer en premiers les options (adresses à exclure paramètres du pool… le tout avant de définir la plage d’adresse à prendre en charge), sans quoi il se pourrait que les premières configurations reçues par les machines soient incomplètes. Commençons par le routeur DHCP… Exclusion des adresses nécessaires (adresse des passerelles, du serveur DHCP, …) ici nous allons exclure les dix premières de chaque LAN (choix arbitraire). DHCP(config)#ip dhcp excluded-address 192.168.0.1 192.168.0.10 DHCP(config)#ip dhcp excluded-address 192.168.1.1 192.168.1.10

Attention dans la définition des adresses à exclure, la première adresse donne le début de la plage et la deuxième la fin de la plage à exclure. Si vous ne souhaitez qu’exclure une adresse, il suffit de ne pas donner d’adresse de fin. Configurons maintenant le pool DHCP pour la LAN1… DHCP(config)#ip dhcp pool LAN1 DHCP(dhcp-config)#default-router 192.168.0.1 DHCP(dhcp-config)#dns-server 8.8.8.8 DHCP(dhcp-config)#network 192.168.0.0 255.255.255.0 DHCP(dhcp-config)#exit

On a donc créé ici un pool DHCP nommé LAN1, dans lequelles les machines recevront comme passerelle par défaut 192.168.0.1 (l’adresse de R1 dans le LAN1), un serveur DNS 8.8.8.8 (totalement fictif ici, mais il me semblait indispensable de montrer comment le configurer)… et cette configuration sera valable pour le réseau 192.168.0.0/24 (plage d’adresse à distribuer de laquelle il faut soustraire les adresses précédemment exclues). Faison de même pour le LAN2… DHCP(config)#ip dhcp pool LAN2 DHCP(dhcp-config)#default-router 192.168.1.1 DHCP(dhcp-config)#dns-server 8.8.8.8 DHCP(dhcp-config)#network 192.168.1.0 255.255.255.0 DHCP(dhcp-config)#exit

A présent les machnes du LAN2 doivent recevoir leur configuration correctement étant donné que le serveur DHCP est dans le même domaine de diffusion qu’elles. Vérifions sur C2… VPCS[2]> ip dhcp DDORA IP 192.168.1.11/24 GW 192.168.1.1

12

Le serveur DHCP devrait également avoir gardé ce bail DHCP en mémoire… DHCP#show ip dhcp binding Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name 192.168.1.11 0100.5079.6668.01 Mar 02 2002 12:34 AM Automatic DHCP#

Par contre … impossible pour C1 de recevoir sa configuration … VPCS[1]> ip dhcp DDD Can't find dhcp server

En effet, lorsque R1 reçoit la tramme de broadcast contenant la requête DHCP de C1, vu qu’il ne sait rien en faire, il la « jette » purement et simplement. Il nous faut configurer le relai des trames DHCP vers le serveur DHCP. Pour cela nous devons dire explicitement à R1 de relayer ces trames à 192.168.1.5 (le serveur DHCP) lorsqu’elles entrent sur son interface Fa0/0. Voici la manipulation: R1(config)#interface fastEthernet 0/0 R1(config-if)#ip helper-address 192.168.1.5

Notez que la commande « ip helper-address » a plus d’utilité que le simple relai des requêtes DHCP. Elle sert à relayer les broadcasts UDP de plusieurs protocoles (DHCP, NTP, Netbios…). A présent C1 peut aussi obtenir sa configuration par DHCP VPCS[1]> ip dhcp DDORA IP 192.168.0.11/24 GW 192.168.0.1

DHCP doit également avoir retenu les informations concernant ce bail DHCP… DHCP#show ip dhcp binding Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name 192.168.0.11 0100.5079.6668.00 Mar 02 2002 01:27 AM Automatic 192.168.1.11 0100.5079.6668.01 Mar 02 2002 12:34 AM Automatic DHCP#

Quelques explications complémentaires… Comment fait DHCP pour savoir dans quel pool d’adresse il doit piocher en réponse à une requête venant du LAN1 ou du LAN2 ? Dans le cas du LAN2, la requête arrive sous forme de broadcast, sur l’interface ethernet de DHCP, il lui suffit alors de fournir une configuration pour une machine dansle même domaine de diffusion que lui, donc le pool LAN2. Par contre dans le cas du LAN1, la requête arrive à DHCP sous forme d’unicast, car elle est relayée par R1. R1 a en réalité, construit un paquet unicast, avec comme adresse source celle de son interface dans le LAN1 et comme destination celle du serveur DHCP. 13

Dés lors quand DHCP reçoit la requête unicast, il propose une adresse provenant du pool dont la plage d’adresse correspond à celle configurée sur l’interface Fa0/0 de R1.

Quelques paramètres en plus… Bien entendu la configuration du DHCP ne se limite pas à une adresse, un masque, une passerelle et un serveur DNS. Voici quelques autres paramètres configurables… Définir le nom de domaine qui sera associé à l’interface recevant la configuration… DHCP(config)#ip dhcp pool LAN1 DHCP(dhcp-config)#domain-name test.lab

Configurer la durée du bail DHCP… DHCP(dhcp-config)#lease 5 10 30

Le format est « lease ». On peut également défini un bail illimité en utilisant « lease infinite ». Il est également possible de configurer des options « brutes ». Ce sont des paramètres n’ayant pas de nom spécifiques. Mais la syntaxe varie en fonction des données à fournir. Par exemple, si on doit renseigner une adresse de serveur TFTP pour qu’une machine puisse y récupérer une image de démarrage (c’est le cas dans avec les systèmes de déploiement réseau), il faut indiquer l’option 150, avec comme paramètre l’adresse ip du serveur TFTP. DHCP(dhcp-config)#option 150 ip 192.168.1.50

Encore une vérification… Nous avons vu précédemment la commande « show ip dhcp binding » qui affiche la liste des baux en cours. Il est aussi possible d’afficher les pools DHCP et leurs statistiques… DHCP#sh ip dhcp pool LAN1 Pool LAN1 : Utilization mark (high/low) : 100 / 0 Subnet size (first/next) : 0 / 0 Total addresses : 254 Leased addresses : 1 Pending event : none 1 subnet is currently in the pool : Current index IP address range Leased addresses 192.168.0.12 192.168.0.1 - 192.168.0.254 1 DHCP#

Voilà de quoi configurer un serveur DHCP fonctionnel.

14

HSRP : Hot Standby Router Protocol Sur un PC on configure généralement une seule passerelle par défaut… Mais que se passe-t-il si celle-ci est hors service ? … La réponse est simple … plus moyen de communiquer en dehors de son domaine de diffusion. Pour remédier à cela, il existe plusieurs méthodes pour gérer la redondance de passerelle dont les protocoles HSRP, VRRP et GLBP. Voici un exemple simple de mise en place de redondance de passerelle à l’aide de HSRP. Il est toutefois important de noter qu’il s’agit d’un protocole propriétaire Cisco.

La topologie

Afin d’aller directement à l’essentiel, la configuration de base de la topologie est considérée comme terminée. Pour ma part j’ai simplement activé EIGRP entre R1, R2 et R3. R3 dispose d’une interface Loopback (1.1.1.1/32) que j’utiliserai pour tester la communication depuis le PC. Le PC (C1) est configuré avec l’adresse 192.168.0.10/24 avec une passerelle par défaut 192.168.0.254. Notez qu’il ne s’agit pas de l’adresse configurée sur R1 ou R2 … Mais ce sera celle dont le rôle sera assumé soit par R1 soit par R2 en fonction de l’état du réseau.

Principe général HSRP est un protocole qui fourni une solution de continuité de service principalement pour la redondance de passerelles par défaut. Pour chaque réseau, on associe les interfaces des routeurs à un groupe HSRP (le même n° de groupe pour toutes les interfaces qui doivent assurer le même rôle). A ce groupe on associe une adresse IP virtuelle (dans le cas présent ce sera 192.168.0.254). La redondance est mise en place par le biais du protocole ARP. Lorsque le PC doit envoyer une trame à sa passerelle, il émet une requête ARP et celle-ci répond en fournissant son adresse MAC. Avec HSRP, les routeurs vont associer une adresse MAC particulière à l’adresse IP virtuelle sous la forme 00:00:0c:07:ac:XX (où XX est le n° du groupe HSRP).

15

Dés lors, pour le PC, quoi qu’il arrive, ce sera cette adresse MAC qui identifiera sa passerelle. De leur côté les routeurs dialoguent par multicast afin de négocier et de savoir qui devra se charger de traiter la trame destinée à l’adresse MAC HSRP.

Configuration de R1 R1(config)# interface FastEthernet0/0 R1(config-if)# standby 1 ip 192.168.0.254 R1(config-if)# standby 1 priority 200 R1(config-if)# standby 1 preempt

On a donc configuré ici l’interface Fa0/0 de R1 pour fonctionner dans le groupe HSRP n°1 auquel on a associé l’adresse IP virtuelle 192.168.0.254. En plus on a défini une priorité de 200 (la plus grande priorité sera la passerelle effective) et on active le droit de préemption (si R1 tombe en panne, R2 prend le relai… mais is R1 revient, il reprendra sa place, sans préemption, R2 resterait la passerelle).

Configuration de R2 R2(config)# interface FastEthernet0/0 R2(config-if)# standby 1 ip 192.168.0.254 R2(config-if)# standby 1 priority 100

La configuration de R2 est similaire à celle de R1, étant donné que R2 est configuré avec une priorité plus faible, il n’est pas nécessaire d’activer la préemption.

Vérification Sur le PC, un test de communication démontre le bon fonctionnement de la configuration… La configuration de C1: NAME IP/MASK GATEWAY MAC VPCS1 192.168.0.10/24 192.168.0.254 00:50:79:66:68:00

Test de communication vers 1.1.1.1 VPCS[1]> ping 1.1.1.1 1.1.1.1 icmp_seq=1 timeout 1.1.1.1 icmp_seq=2 ttl=254 1.1.1.1 icmp_seq=3 ttl=254 1.1.1.1 icmp_seq=4 ttl=254 1.1.1.1 icmp_seq=5 ttl=254

time=50.000 time=50.000 time=39.000 time=48.000

ms ms ms ms

Il est intéressant d’analyser la table ARP de C1… VPCS[1]> arp 00:00:0c:07:ac:01 192.168.0.254 expires in 114 seconds

On constate donc bien que 192.168.0.254 est la passerelle de C1 et que l’adresse MAC associée est bien celle d’un groupe HSRP (ici le groupe 1, indiqué par le dernier octet de l’adresse MAC … 01). Un traceroute prouvera que R1 est bien le routeur faisant office de passerelle… VPCS[1]> trace 1.1.1.1 trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop 1 192.168.0.1 20.000 ms 10.000 ms 10.000 ms

16

2 172.30.0.1 3 1.1.1.1

30.000 ms 10.000 ms 10.000 ms 30.000 ms 10.000 ms 10.000 ms

Vérification de la configuration Sur R1 et R2 il est possible de vérifier le fonctionnement de HSRP d’une simple commande: R1#show standby FastEthernet0/0 - Group 1 State is Active 2 state changes, last state change 00:14:40 Virtual IP address is 192.168.0.254 Active virtual MAC address is 0000.0c07.ac01 Local virtual MAC address is 0000.0c07.ac01 (v1 default) Hello time 3 sec, hold time 10 sec Next hello sent in 1.064 secs Preemption enabled Active router is local Standby router is 192.168.0.2, priority 100 (expires in 8.320 sec) Priority 200 (configured 200) Group name is "hsrp-Fa0/0-1" (default) R1#

On y voit que « State is Active » qui signifie que R1 est la passerelle active (et donc R2 est en standby). Le reste des informations sont explicites.

Que se passe-t-il si R1 tombe en panne … Pour simuler une panne, je mets simplement l’interface Fa0/0 de R1 en shutdown… R1(config-if)# shutdown *Mar 1 00:44:02.331: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Init *Mar 1 00:44:04.343: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down *Mar 1 00:44:05.343: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to down

Réaction immédiate de R2 … R2# *Mar 1 00:44:11.071: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active

R2 est bien devenu la passerelle active, vérifions sur C1… VPCS[1]> ping 1.1.1.1 1.1.1.1 icmp_seq=1 ttl=254 time=32.000 ms 1.1.1.1 icmp_seq=2 ttl=254 time=41.000 ms 1.1.1.1 icmp_seq=3 ttl=254 time=31.000 ms 1.1.1.1 icmp_seq=4 ttl=254 time=31.000 ms 1.1.1.1 icmp_seq=5 ttl=254 time=40.000 ms VPCS[1]> arp 00:00:0c:07:ac:01 192.168.0.254 expires in 15 seconds

Rien n’a changé de son côté, normal … puisque R1 et R2 utilisent la même adresse IP virtuelle associée à la même adresse MAC pour HSRP. Par contre le paquet ICMP passe bien par R2… VPCS[1]> trace 1.1.1.1 trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop 1 192.168.0.2 21.000 ms 11.000 ms 11.000 ms

17

2 172.30.0.5 3 1.1.1.1

31.000 ms 12.000 ms 12.000 ms 32.000 ms 12.000 ms 12.000 ms

Voilà de quoi gérer très simplement la redondance de passerelle par défaut (à condition de disposer de matériel Cisco).

VRRP : Virtual Router Redundancy Protocol Dans l’article précédent nous avons vu une mise en oeuvre simple de HSRP qui permet de gérer la redondance de passerelle (entre autre). Bien que simple à mettre en place, HSRP a comme principal defaut d’être propriétaire Cisco. Voici donc une mise en place équivalente de VRRP, protocole standard défini dans la RFC 5798…

Afin de permettre une comparaison facile avec HSRP, j’ai gardé la même structure pour l’article.

La topologie

La topologie est similaire à celle utilisée dans l’article sur HSRP. R1 et R2 seront donc les deux passerelles par défaut à faire fonctionner en redondance. R1 et R2 communiqueront à l’aide de VRRP par leurs interfaces FastEthernet afin de négocier leur rôle.

Principe général VRRP est donc, à l’instar de HSRP, également un protocole qui fourni une solution de continuité de service principalement pour la redondance de passerelles par défaut. Pour chaque réseau, on associe les interfaces des routeurs à un groupe VRRP (le même n° de groupe pour toutes les interfaces qui doivent assurer le même rôle). A ce groupe on associe une adresse IP virtuelle (dans le cas présent ce sera 192.168.0.254). La redondance est mise en place par le biais du protocole ARP. Lorsque le PC doit envoyer une trame à sa passerelle, il émet une requête ARP et celle-ci répond en fournissant son adresse MAC. Dans le cas de VRRP, les routeurs vont associer une adresse MAC particulière à l’adresse IP virtuelle sous la forme 00:00:5E:00:01:XX (où XX est le n° du groupe VRRP). Dés lors, pour le PC, quoi qu’il arrive, ce sera cette adresse MAC qui identifiera sa passerelle. De leur côté les routeurs dialoguent par multicast (224.0.0.18) afin de négocier et de savoir qui devra se charger de traiter la trame destinée à l’adresse MAC VRRP.

Configuration de R1 R1(config)# interface R1(config-if)# vrrp 1 R1(config-if)# vrrp 1 R1(config-if)# vrrp 1

FastEthernet0/0 ip 192.168.0.254 priority 200 preempt

18

L’interface Fa0/0 de R1 fonctionnera dans le groupe VRRP n°1 auquel on a associé l’adresse IP virtuelle 192.168.0.254. En plus on a défini une priorité de 200 (la plus grande priorité sera la passerelle effective) et on active le droit de préemption (si R1 tombe en panne, R2 prend le relai… mais is R1 revient, il reprendra sa place, sans préemption, R2 resterait la passerelle).

Configuration de R2 R2(config)# interface FastEthernet0/0 R2(config-if)# vrrp 1 ip 192.168.0.254 R2(config-if)# vrrp 1 priority 100

La configuration de R2 est similaire à celle de R1. Notez que les deux routeurs doivent être configurés dans le même groupe et gérer la même adresse virtuelle, sans quoi il n’y aura soit pas de dialogue VRRP soit un conflit d’adresse.

Vérification Configuration de C1: NAME IP/MASK GATEWAY MAC VPCS1 192.168.0.10/24 192.168.0.254 00:50:79:66:68:00

Test de communication vers 1.1.1.1 VPCS[1]> ping 1.1.1.1 1.1.1.1 icmp_seq=1 timeout 1.1.1.1 icmp_seq=2 ttl=254 1.1.1.1 icmp_seq=3 ttl=254 1.1.1.1 icmp_seq=4 ttl=254 1.1.1.1 icmp_seq=5 ttl=254

time=25.000 time=25.000 time=32.000 time=31.000

ms ms ms ms

Il est intéressant d’analyser la table ARP de C1… VPCS[1]> arp 00:00:5e:00:01:01 192.168.0.254 expires in 114 seconds

C1 a bien émi une requête ARP pour obtenir l’adresse MAC correspondant à 192.168.0.254, qui correspond bien à une adresse MAC VRRP où le dernier byte est défini par le n° de groupe VRRP. VPCS[1]> trace 1.1.1.1 trace to 1.1.1.1, 8 hops max, press 1 192.168.0.1 19.000 ms 10.000 ms 2 172.16.0.1 20.000 ms 10.000 ms 3 1.1.1.1 20.000 ms 10.000 ms

Ctrl+C to stop 9.000 ms 10.000 ms 10.000 ms

On constate ici que R1 assure bien le role de 192.168.0.254

Vérification de la configuration Vérification du fonctionnement de VRRP sur R1 : R1#show vrrp FastEthernet0/0 - Group 1 State is Master

19

Virtual IP address is 192.168.0.254 Virtual MAC address is 0000.5e00.0101 Advertisement interval is 1.000 sec Preemption enabled Priority is 200 Master Router is 192.168.0.1 (local), priority is 200 Master Advertisement interval is 1.000 sec Master Down interval is 3.218 sec R1#

Le « State » indique soit Master (actif) soit Backup (en standby). Le reste des informations est explicite.

Que se passe-t-il si R1 tombe en panne … Test de fonctionnement en mettant Fa0/0 de R1 en shutdown… R1(config-if)#shutdown *Mar 1 02:21:46.399: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Master -> Init *Mar 1 02:21:48.403: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down *Mar 1 02:21:49.403: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

Réaction immédiate de R2 … R2# *Mar 1 02:21:41.727: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Backup -> Master

R2 est bien devenu la passerelle active, vérifions sur C1… VPCS[1]> ping 1.1.1.1 1.1.1.1 icmp_seq=1 ttl=254 time=26.000 ms 1.1.1.1 icmp_seq=2 ttl=254 time=19.000 ms 1.1.1.1 icmp_seq=3 ttl=254 time=19.000 ms 1.1.1.1 icmp_seq=4 ttl=254 time=19.000 ms 1.1.1.1 icmp_seq=5 ttl=254 time=19.000 ms VPCS[1]> arp 00:00:5e:00:01:01 192.168.0.254 expires in 7 seconds

Comme pour HSRP,la table ARP de C1 reste identique.La transition entre R1 et R2 est transparente pour C1. VPCS[1]> trace 1.1.1.1 trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop 1 192.168.0.2 9.000 ms 9.000 ms 9.000 ms 2 172.16.0.5 10.000 ms 10.000 ms 10.000 ms 3 1.1.1.1 10.000 ms 11.000 ms 10.000 ms

Conclusion Pour une configuration aussi simple, VRRP fonctionne quasiment comme HSRP, il n’y a donc pas grand chose d’autre à ajouter. Les différences majeures se situent dans les rouages du protocole (adresse multicast utilisée, adresse MAC etc.).

20