mercredi 30 avril 2014

Configuration du DHCP et NAT




Tache 1 : Configurer les routes statique et les routes par défauts au niveau de l’intranet de la société ABC :
Routeur R1 :
R1(config)#ip route 192.168.30.0 255.255.255.0 10.10.10.2
R1(config)#ip route 10.10.9.0 255.255.255.252 10.10.10.2
R1(config)#ip route 192.168.20.0 255.255.255.248 10.10.10.2
R1(config)#ip route 0.0.0.0 0.0.0.0 10.10.10.2
Routeur R2
R2(config)#ip route 192.168.10.0 255.255.255.0 10.10.10.1
R2(config)#ip route 192.168.11.0 255.255.255.0 10.10.10.1
R2(config)#ip route 192.168.30.0 255.255.255.0 10.10.9.1
R2(config)#ip route 0.0.0.0 0.0.0.0 209.165.200.226
Routeur R3
R3(config)#ip route 192.168.20.0 255.255.255.248 10.10.9.2
R3(config)#ip route 192.168.10.0 255.255.255.0 10.10.9.2
R3(config)#ip route 192.168.11.0 255.255.255.0 10.10.9.2
R3(config)#ip route 0.0.0.0 0.0.0.0 10.10.9.2

Tache 2 : Configuration d’un serveur DHCP au niveau de R2:
L’objectif de cette tâche est que les périphériques présents sur les réseaux 192.168.10.0/24 , 192.168.11.0/24 et 192.168.30.0/24 demandent à R2 des adresses IP via le protocole DHCP.
Étape 1 : exclusion des adresses attribuées de manière statique
Le serveur DHCP suppose que toutes les adresses IP d’un groupe d’adresses DHCP peuvent être affectées à des clients DHCP. Vous devez spécifier les adresses IP que le serveur DHCP ne peut affecter aux clients. Il s’agit généralement d’adresses statiques réservées à l’interface des routeurs, à la console de gestion des commutateurs, aux serveurs et aux imprimantes du réseau local. La commande ip dhcp excluded-address empêche le routeur d’attribuer les adresses IP présentes dans la plage configurée.
R2(config)#ip dhcp excluded-address 192.168.10.10
R2(config)#ip dhcp excluded-address 192.168.10.1
R2(config)#ip dhcp excluded-address 192.168.11.10
R2(config)#ip dhcp excluded-address 192.168.11.1
Étape 2 : configuration du pool
Créez le pool DHCP à l’aide de la commande ip dhcp pool et nommez-le R1Fa0.
R2(config)#ip dhcp pool R1Fa0/0
R2(dhcp-config)#network 192.168.10.0 255.255.255.0
Configurez le routeur par défaut et le serveur de noms de domaine du réseau. Les clients reçoivent ces paramètres via le protocole DHCP, de même qu’une adresse IP.
R2(dhcp-config)#default-router 192.168.10.1
R2(dhcp-config)#DNS-server 88.88.88.88
Étant donné que les périphériques du réseau 192.168.11.0/24  et 192.168.30.0/24 requièrent également que R2 leur fournissent des adresses, vous devez créer un pool distinct pour répondre à leurs besoins. Les commandes utilisées sont similaires à celles présentées ci-dessus :
R2(config)#ip dhcp pool R1F0/1
R2(dhcp-config)#network 192.168.11.0 255.255.255.0
R2(dhcp-config)#DEFault-router 192.168.11.1
R2(dhcp-config)#DNS-server 88.88.88.88

R2(config)#IP DHCp pool R3F0/0
R2(dhcp-config)#network 192.168.30.0 255.255.255.0
R2(dhcp-config)#default-router 192.168.30.1
R2(dhcp-config)#DNS-server 88.88.88.88
Étape 3 : configuration d’un agent relais DHCP
Les services réseaux tels que le protocole DHCP fonctionnent via les diffusions de couche 2. Si les périphériques fournissant ces services se trouvent sur un sous-réseau différent de celui des clients, ils ne peuvent pas recevoir les paquets de diffusion. Étant donné que le serveur DHCP et les clients DHCP ne figurent pas sur le même sous-réseau, vous devez configurer R1 pour qu’il transmette les messages de diffusion DHCP à R2, qui correspond au serveur DHCP, à l’aide de la commande de configuration d’interface ip helper-address.
R3(config)#INT F0/0
R3(config-if)#ip helper-address 10.10.9.2
R1(config)#INT F0/0
R1(config-if)#ip helper-address 10.10.10.2
R1(config-if)#exit
R1(config)#int f0/1
R1(config-if)#ip helper-address 10.10.10.2
R2#SHOW IP DHCP BInding
La commande show ip dhcp binding renvoie des informations sur les adresses DHCP actuellement attribuées
IP address            Client-ID/              Lease expiration        Type
                        Hardware address
192.168.10.2      0004.9AD8.83A8                   --                   Automatic
192.168.11.2      00E0.A31A.E050                   --                  Automatic
192.168.30.2     0001.966C.A561                      --                  Automatic
192.168.30.3     00E0.F957.94CD                   --                   Automatic

Tâche 3 : configuration de la traduction d’adresses de réseau (NAT) statique
Étape 1 : mappage statique d’une adresse IP publique à une adresse IP privée
 Les hôtes externes situés derrière FAI peuvent accéder au serveur web (hébergé au niveau de la société) connecté à R2. Désignez de manière statique ladresse IP publique 77.77.77.77 comme adresse à utiliser lors de la traduction dadresses de réseau pour associer les paquets à ladresse IP privée du serveur WEB, à ladresse 192.168.20.2.
R2(config)#ip nat inside source static 192.168.20.2 77.77.77.77
Étape 2 : désignation des interfaces de traduction d’adresses de réseau internes et externes
 Pour que la traduction dadresses de réseau puisse fonctionner, vous devez désigner les interfaces internes et les interfaces externes.
R2(config)#interface serial 0/1/0
R2(config-if)#ip nat outside
R2(config-if)#interface fa0/0
R2(config-if)#ip nat inside
Etape 3 : Mappage statiques des serveurs hebegé au niveau ISP
Les serveyrs  hebergé au niveau du  FAI doivent avoir des adresse ip public fixe pourque tous les internautes peuvent accéder a leurs services , au niveau du routeur du FAI il faut faire le mappage statique (traduction d’adresses privé/public) .
ISP(config)#IP NAT inside source static 192.168.10.3 88.88.88.88
ISP(config)#IP NAT inside source static 192.168.10.2 66.66.66.66
ISP(config)#int fa0/0
ISP(config-if)#ip nat inside
ISP(config-if)#int s0/0/0
ISP(config-if)#ip nat outside
ISP(config-if)#exit
Tâche 4 : configuration du routage statique au niveau du ISP
ISP fait appel au routage statique pour accéder aux réseaux situés au-delà de R2. Cependant, avant denvoyer le trafic vers ISP, R2 traduit les adresses privées en adresses publiques. Par conséquent, il est nécessaire de configurer sur ISP les adresses publiques impliquées dans la configuration de la traduction dadresses de réseau de R2. Indiquez la route statique suivante sur ISP :
ISP(config)#ip route 77:77:77:77 255.255.255.255 serial 0/0/0

Tache 5 : vérification de la configuration de la traduction d’adresses de réseau statique
Tâche 6 : configuration d’un pool d’adresses pour la traduction d’adresses de réseau dynamique
Tandis que la fonction NAT statique fournit un mappage permanent entre une adresse interne et une adresse publique spécifique, la fonction NAT dynamique mappe des adresses IP privées avec des adresses publiques. Ces adresses IP publiques proviennent d’un pool NAT (pool de traduction d’adresses de réseau).
Étape 1 : définition d’un pool d’adresses globales
Créez un pool d’adresses à utiliser pour la traduction des adresses source correspondantes. La commande suivante crée un pool appelé MY-NAT-POOL, qui convertit les adresses correspondantes en une adresse IP disponible dans la plage 209.165.200.241 - -209 165 200 246.
R2(config)#ip nat pool MY-NAT-POOL 209.165.200.241 209.165.200.246 netmask 255.255.255.248

Étape 2 : création d’une liste de contrôle d’accès étendue permettant d’identifier les adresses internes traduites
 R2(config)#ip access-list extended NAT
R2(config-ext-nacl)#permit ip 192.168.10.0 0.0.0.255 any
R2(config-ext-nacl)#permit ip 192.168.11.0 0.0.0.255 any
R2(config-ext-nacl)#permit ip 192.168.30.0 0.0.0.255 any
Étape 3 : établissement d’une traduction de source dynamique par association du pool à la liste de contrôle d’accès
Un routeur peut disposer de plusieurs pools de traduction dadresses de réseau et de plusieurs listes de contrôle daccès. La commande suivante indique au routeur le pool dadresses qui doit être utilisé pour convertir les hôtes autorisés par la liste de contrôle daccès.
R2(config)#ip nat inside source list NAT pool MY-NAT-POOL
Étape 4 : désignation des interfaces de traduction d’adresses de réseau internes et externes
Vous avez déjà désigné les interfaces internes et externes de votre configuration de traduction dadresses de réseau statique. Ajoutez maintenant linterface série s0/0/0 connectée à R2 (pour les réseaux 192.168.10.0 et 192.168.11.0) et S0/0/1(pour le réseau 192.168.30.0) comme interface interne.
R2(config)#int s0/0/0
R2(config-if)#ip nat inside
R2(config-if)#int s0/0/1
R2(config-if)#ip nat inside
R2(config-if)#int s0/1/0
R2(config-if)#ip nat outside
Etape 5 : configuration du routage statique au niveau du ISP
FAI fait appel au routage statique pour accéder aux réseaux situés au-delà de R2. Cependant, avant denvoyer le trafic vers FAI, R2 traduit les adresses privées en adresses publiques. Par conséquent, il est nécessaire de configurer sur FAI les adresses publiques impliquées dans la configuration de la traduction dynamique dadresses de réseau de R2. Indiquez la route statique suivante sur FAI :
ISP(config)#ip route 209.165.200.240 255.255.255.240 serial 0/0/0

Étape 6 : vérification de la configuration
Envoyez une requête ping au routeur ISP à partir de PC1 ou de l’interface Fast Ethernet de R1, en utilisant une commande ping étendue. Vérifiez ensuite la fonction NAT en exécutant les commandes show ip nat translations et show ip nat statistics sur R2.

Tâche 7 : configuration de la surcharge de la fonction NAT
Dans l’exemple précédent, que se passerait-il si vous deviez utiliser un nombre d’adresses IP publiques supérieur aux six adresses autorisées dans le pool ? __________________________________________________________________________________
 Grâce au suivi des numéros de port, la fonction de surcharge de traduction dadresses de réseau permet à plusieurs utilisateurs internes de réutiliser une adresse IP publique. Dans le cadre de cette tâche, vous supprimerez le pool et linstruction de mappage configurés au cours de la tâche précédente. Vous configurerez ensuite la surcharge de traduction dadresses de réseau sur R2, de manière à ce que toutes les adresses IP internes soient traduites en une adresse associée à linterface S0/0/1 de R2 lors de la connexion à un périphérique externe.
Étape 1 : suppression du pool de traduction d’adresses de réseau et de l’instruction de mappage
Utilisez les commandes suivantes pour supprimer le pool de traduction dadresses de réseau et lassociation à la liste de contrôle daccès.
R2(config)#no ip nat inside source list NAT pool MY-NAT-POOL
R2(config)#no ip nat pool MY-NAT-POOL 209.165.200.241 209.165.200.246 netmask 255.255.255.248
Si vous recevez le message suivant, effacez vos traductions dadresses de réseau. %Pool MY-NAT-POOL in use, cannot destroy R2#clear ip nat translation *
Étape 2 : configuration de la traduction d’adresses de port sur R2 à l’aide de l’adresse IP publique de l’interface série 0/1/0
 La configuration est similaire à une traduction dadresses de réseau dynamique, mais au lieu dun pool dadresses, cest le mot clé interface qui est utilisé pour identifier ladresse IP externe. Par conséquent, aucun pool de traduction d’adresses de réseau n’est défini. Le mot clé overload permet d’ajouter le numéro de port à la traduction. Comme vous avez déjà configuré une liste de contrôle daccès pour identifier les adresses IP internes à traduire ainsi que les interfaces internes et externes, il ne vous reste plus quà configurer la commande suivante : R2(config)#ip nat inside source list NAT interface S0/1/0 overload
Étape 3 : vérification de la configuration
Envoyez une requête ping au routeur FAI à partir de PC1 ou de l’interface Fast Ethernet de R1, en utilisant une commande ping étendue. Vérifiez ensuite la fonction NAT en exécutant les commandes show ip nat translations et show ip nat statistics sur R2.


Tâche 8 : configuration de routeur 4 afin que l’internaute puissent se connecter au différents serveur public (utilise la surcharge NAT pour la traduction)

Le service d'adressage IP NAT

Objectifs spécifiques :
  • savoir expliquer les principales caractéristiques et le fonctionnement de NAT et de la surcharge NAT

************
1- Qu'est ce que le NAT?

La fonction NAT agit comme la réceptionniste d’une grande société. Supposons que vous avez demandé à la réceptionniste de ne vous transférer aucun appel sauf contre-indication de votre part. Plus tard, vous appelez un client potentiel et vous lui laissez un message en lui demandant de vous rappeler. Vous dites à la réceptionniste que vous attendez un appel de ce client ; vous lui demandez de transférer l’appel à votre bureau.
Le client appelle le standard de la société car il s’agit du seul numéro qu’il connaît. Lorsque le client indique à la réceptionniste le nom de la personne qu’il souhaite contacter, la réceptionniste consulte une table de recherche dans laquelle votre nom est associé à votre extension. La réceptionniste sait que vous attendez cet appel ; elle transfère donc l’appel à votre extension.

Ainsi, pendant que le serveur DHCP attribue des adresses IP dynamiques aux périphériques du réseau, les routeurs compatibles NAT retiennent une ou plusieurs adresses IP Internet valides hors du réseau. Lorsque le client envoie des paquets en dehors du réseau, la fonction NAT traduit l’adresse IP interne du client en adresse externe. Pour les utilisateurs externes, l’ensemble du trafic depuis et vers le réseau a la même adresse IP ou provient du même pool d’adresses.

La principale fonction de NAT est d’enregistrer les adresses IP en autorisant les réseaux à utiliser des adresses IP privées. NAT traduit les adresses non routables, privées et internes en adresses routables publiques.
NAT permet également d’ajouter un niveau de confidentialité et de sécurité à un réseau car il empêche les réseaux externes de voir les adresses IP internes.

Un périphérique compatible NAT fonctionne généralement à la périphérie d’un réseau d’extrémité.


Dans notre exemple, R2 est le routeur périphérique. Un réseau d’extrémité est un réseau ayant une connexion unique vers son réseau voisin. Pour le FAI, R2 forme un réseau d’extrémité.

Lorsqu’un hôte interne au réseau d’extrémité, par exemple PC1, PC2 ou PC 3, souhaite transmettre à un hôte externe, le paquet est transféré à R2, le routeur de passerelle frontière. R2 effectue le processus NAT, c’est-à-dire qu’il traduit l’adresse privée interne de l’hôte en adresse publique externe routable.

Dans la terminologie NAT, le réseau interne désigne l’ensemble des réseaux soumis à la traduction. Le réseau externe désigne toutes les autres adresses. Les désignations des adresses IP sont différentes si ces adresses sont sur réseau privé ou public (Internet) et si le trafic est entrant ou sortant.



La figure montre comment désigner les interfaces lors de la configuration de NAT. Supposons que le routeur R2 a été configuré pour offrir des fonctionnalités NAT. Il dispose d’un pool d’adresses publiques disponibles à louer aux hôtes internes.

Voici les termes relatifs à la fonction NAT :

  • Adresse locale interne : n’est généralement pas une adresse IP attribuée par un organisme d’enregistrement Internet local ou un fournisseur de services et est souvent une adresse privée. Dans la figure, l’adresse IP 192.168.10.10 est attribuée à l’hôte PC1 sur le réseau interne.
  • Adresse globale interne : adresse publique valide attribuée à l’hôte interne lorsque ce dernier quitte le routeur NAT. Lorsque le trafic de PC1 est destiné au serveur Web à l’adresse 209.165.201.1, le routeur R2 doit traduire l’adresse. Dans ce cas, l’adresse IP 209.165.200.226 est utilisée comme adresse globale interne pour PC1.
  • Adresse globale externe : adresse IP accessible attribuée à un hôte sur Internet. Par exemple, le serveur Web est accessible à l’adresse IP 209.165.201.1.

2- Comment fonctionne NAT ? 



Dans cet exemple, un hôte interne (192.168.10.10) souhaite communiquer avec un serveur Web externe (209.165.200.1). Il envoie un paquet à R2, qui est la passerelle frontière configurée NAT pour le réseau.

R2 lit l’adresse IP de destination du paquet et vérifie si le paquet correspond aux critères spécifiés pour la traduction. R2 dispose d’une liste de contrôle d’accès qui identifie le réseau interne comme hôtes valides pour la traduction. Il traduit donc une adresse IP locale interne en adresse IP globale interne, à savoir 209.165.200.226. Il stocke ce mappage de l’adresse locale sur l’adresse globale dans la table NAT.

Le routeur envoie ensuite le paquet vers sa destination. Lorsque le serveur Web répond, le paquet revient à l’adresse globale de R2 (209.165.200.226).

R2 consulte sa table NAT et s’aperçoit que cette adresse IP a été précédemment traduite. Il traduit donc l’adresse globale interne en adresse locale interne ; le paquet est ensuite transféré à PC1 à l’adresse IP 192.168.10.10. Si aucun mappage n’est trouvé, le paquet est abandonné.

Mappage dynamique et mappage statique

Il existe deux types de traduction NAT : dynamique et statique.

  • La fonction NAT dynamique utilise un pool d’adresses publiques et les attribue selon la méthode du premier arrivé, premier servi. Lorsqu’un hôte ayant une adresse IP privée demande un accès à Internet, la fonction NAT dynamique choisit dans le pool une adresse IP qui n’est pas encore utilisée par un autre hôte. Cette description est celle du mappage.

  • La fonction NAT statique utilise un mappage biunivoque des adresses locales et globales ; ces mappages restent constants. Cette fonction s’avère particulièrement utile pour les serveurs Web ou les hôtes qui doivent disposer d’une adresse permanente, accessible depuis Internet. Ces hôtes internes peuvent être des serveurs d’entreprise ou des périphériques réseau.

Les fonctions NAT statique et dynamique nécessitent toutes deux qu’il existe suffisamment d’adresses publiques disponibles pour satisfaire le nombre total de sessions utilisateur simultanées.

3- Surcharge NAT

La surcharge NAT (parfois appelée traduction d’adresses de port ou PAT) mappe plusieurs adresses IP privées à une seule adresse IP publique ou à quelques adresses. C’est ce que font la plupart des routeurs personnels. Votre FAI attribue une adresse à votre routeur et pourtant, plusieurs membres de votre famille peuvent surfer simultanément sur Internet.

Grâce à la surcharge NAT, plusieurs adresses peuvent être mappées à une ou quelques adresses car chaque adresse privée est également suivie par un numéro de port. Lorsqu’un client ouvre une session TCP/IP, le routeur NAT attribue un numéro de port à son adresse source. La surcharge NAT s’assure que les clients utilisent un numéro de port TCP différent pour chaque session client avec un serveur sur Internet. Lorsqu’une réponse revient du serveur, le numéro de port source, qui devient le numéro de port de destination lors du retour, détermine le client auquel le routeur achemine les paquets. Il confirme également que les paquets entrants étaient demandés, ce qui ajoute un niveau de sécurité à la session.


La surcharge NAT utilise des numéros de port source uniques sur l’adresse IP globale interne de façon à assurer une distinction entre les traductions. NAT traitant chaque paquet, il utilise un numéro de port (1331 et 1555 dans cet exemple) pour identifier le client d’où provient le paquet. L’adresse source correspond à l’adresse IP locale interne avec le numéro de port TCP/IP attribué lié. L’adresse de destination correspond à l’adresse IP locale externe avec le numéro de port de service lié, dans ce cas le port 80 : HTTP.

Au niveau du routeur de passerelle frontière (R2), la surcharge NAT utilise comme adresse source l’adresse IP globale interne du client, toujours avec le numéro de port lié. L’adresse de destination reste la même, mais s’appelle désormais adresse IP globale externe. Lorsque le serveur Web répond, le même chemin est suivi, mais en sens inverse.

Les numéros de port sont codés en 16 bits. Le nombre total d’adresses internes pouvant être traduites en une adresse externe peut théoriquement atteindre 65 536 par adresse IP. Cependant, pour être réaliste, le nombre d’adresses internes pouvant se voir attribuer une adresse IP unique se situe aux environs de 4 000.

Dans l’exemple précédent, les numéros de port client des deux adresses de destination, 1331 et 1555, ne changent pas au niveau de la passerelle frontière. Ce scénario est peu probable car il y a de fortes chances que ces numéros soient déjà liés à d’autres sessions sortantes.

La surcharge NAT essaye de conserver le port source d’origine. Cependant, si ce port source est déjà utilisé, la surcharge NAT attribue le premier numéro de port disponible en commençant au début du groupe de ports approprié, à savoir 0-511, 512-1023 ou 1024-65535. Lorsqu’il n’y a plus de ports disponibles et que plusieurs adresses IP externes sont configurées, la surcharge NAT sélectionne l’adresse IP suivante pour essayer d’allouer de nouveau le port source initial. Ce processus se poursuit jusqu’à ce qu’il n’y ait plus de ports ni d’adresses IP externes disponibles.


Dans la figure, les deux hôtes ont choisi le même numéro de port : 1444. Cette situation est acceptable pour l’adresse interne car ils disposent tous deux d’une adresse IP privée unique. Cependant, au niveau de la passerelle frontière, les numéros de port doivent changer car sinon, deux paquets provenant de deux hôtes laisseraient R2 avec la même adresse source. La surcharge NAT a attribué à la deuxième adresse le premier numéro de port disponible, à savoir dans ce cas 1445.

 4- Différences entre NAT et la surcharge NAT

NAT ne traduit en général que des adresses IP sur une base de 1 pour 1 entre des adresses IP publiques et des adresses IP privées.
La surcharge NAT modifie à la fois l’adresse IP privée et le numéro de port de l’expéditeur.
NAT achemine les paquets entrants vers leur destination interne en faisant référence à l’adresse IP source entrante donnée par l’hôte sur le réseau public.
La surcharge NAT choisit les numéros de port vus par les hôtes sur le réseau public.

Avec la surcharge NAT, il n’y a généralement qu’une ou que très peu d’adresses IP exposées au public. Les paquets entrants provenant du réseau public sont acheminés vers leur destination sur le réseau privé en faisant référence à une table dans le périphérique de surcharge NAT qui suit les associations entre ports publics et privés. On appelle cela le suivi de connexions.


vendredi 25 avril 2014

Implementation de GETVPN dans les CEs au niveau d'une architecture MPLS/VPN

Topologie




Introduction


Le GET VPN ça sert à quoi déjà ? Vous avez peut être un super VPN MPLS au bureau qui marche super mais ça vous embête un petit peu d’avoir votre trafic qui se balade en clair. On peut donc mettre du DMVPN, mais on parleras de VPN Overlay dans la mesure ou on réencapsule les paquets et donc on rajoute une surcouche IP, donc on perd l’intérêt du VPN MPLS. Avec le GET VPN, on laisse le backbone MPLS s’occuper du VPN, et nous (le client) on s’occupe du chiffrement du traffic entre les équipement client (le provider n’a pas a gérer la configuration).
Pour fonctionner, le GETVPN utilise une variante de isakmp qui s’appelle GDOI qui permets la synchronisation des clés de sessions IPSec entre les différents clients, le principe du GET VPN étant d’être multicast, tous les clients auront la même clé de chiffrement à l’instant T (TEK – Traffic encryption key) et un rekeying global de cette TEK s’éffectura de temps en temps via la KEK (Key Encryption Key)

Pour fonctionner, le GETVPN utilise une variante de isakmp qui s’appelle GDOI qui permets la synchronisation des clés de sessions IPSec entre les différents clients, le principe du GET VPN étant d’être multicast, tous les clients auront la même clé de chiffrement à l’instant T (TEK – Traffic encryption key) et un rekeying global de cette TEK s’éffectura de temps en temps via la KEK (Key Encryption Key)

Config initiale

Bon je penses que ceux qui suivent un peu mon blog doivent être familier avec les VPNMPLS donc on va passer les détails de la config 
On va commencer par faire une petite capture de ping entre C1 et C2 et faire un capture au niveau de F2/0 de core 1 pour voir ce qu’il ressort:
C1#ping 10.1.2.2 data DEAD repeat 20

Type escape sequence to abort.
Sending 20, 100-byte ICMP Echos to 10.1.2.2, timeout is 2 seconds:
Packet has data pattern 0xDEAD
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 52/106/192 ms
ce qui nous donne:

Mise en place du serveur de certificats IOS

Alors vu que j’ai pas envie de démarrer une VM en CA, et qu’on a pas vu comment faire un CA sous IOS, et bien on va le faire ici.
Le procédure est dispo ici:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080210cdc.shtml
En gros on génère des clés exportables, on les exportes sous forme de certificats, on active le serveur sur un des routeurs (ici core 1) et on va enroller les autres sur ce serveur CA.
c1(config)#crypto key generate rsa general-keys label carsa exportable modulus 512
% They will be replaced.

% The key modulus size is 512 bits
% Generating 512 bit RSA keys, keys will be exportable...[OK]

c1(config)#
*Oct  4 17:24:40.303: %SSH-5-DISABLED: SSH 1.5 has been disabled
*Oct  4 17:24:41.227:  RSA key size needs to be atleast 768 bits for ssh version 2
c1(config)#
*Oct  4 17:24:41.243: %SSH-5-ENABLED: SSH 1.5 has been enabled
!export format PEM, encryption clé privée DES, pass cisco 123
!Je suis pas sur que ça soit obligatoire, je penses que c'est plutot
!pour archiver les clés si on les perds mais j'ai pas testé sans
c1(config)#crypto key export rsa carsa pem url nvram: 3des cisco123
% Key name: carsa
 Usage: General Purpose Key
Exporting public key...
Destination filename [carsa.pub]?
Writing file to nvram:carsa.pub
Exporting private key...
Destination filename [carsa.prv]?
Writing file to nvram:carsa.prv
c1(config)#ip http server !activation HTTP pour SCEP
c1(config)#crypto pki server carsa
c1(cs-server)#database url nvram:
c1(cs-server)#database level names !on stock en plus le nom de chaque certificat
! par défaut minimum = juste le contenu crypto
core1(cs-server)#issuer-name CN=c1 L=MYDESK C=BE
! L = location, C = country
c1(cs-server)#no shut
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password: cisco123 
Re-enter password: cisco123
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
% Exporting Certificate Server signing certificate and keys...

% Certificate Server enabled.
c1(cs-server)#
*Oct  4 17:36:57.087: %PKI-6-CS_ENABLED: Certificate server now enabled.
c1(cs-server)#do write
Building configuration...
[OK]
c1(cs-server)#exi
c1(config)#
Voilà normalement on est bon ici.
On va maintenant « enroller » nous routeurs afin qu’ils puissent s’authentifier les uns et les autres.
Je rappelle la procédure, on fait un trustpoint afin d’obtenir le certificat du CA (via la commande crypto ca authenticate), et ensuite on s’enroll (on demande notre certificat).
c2(config)#crypto ca trustpoint carsa
! vu que j'ai pas mis de CRL dans mon CA ça pourrait déconner
c2(ca-trustpoint)#revocation-check none
c2(ca-trustpoint)#enrollment url http://10.1.1.2:80
c2(ca-trustpoint)#exi
c2(config)#crypto ca authenticate carsa
Certificate has the following attributes:
 Fingerprint MD5: F9060FED EFDD437B 0971B86E 2CC79D65
 Fingerprint SHA1: 9261C779 35420504 12F77C07 B0EF5938 66F3DC48 

% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
c2(config)#crypto ca enroll carsa
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
 password to the CA Administrator in order to revoke your certificate.
 For security reasons your password will not be saved in the configuration.
 Please make a note of it.
!password défini lors du no sh du CA
Password: cisco123
Re-enter password: cisco123 

% The subject name in the certificate will include: c2
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose carsa' commandwill show the fingerprint.

c2(config)# ! voilà la requête de certificat, il faut maintenant l'approuver
*Oct  4 17:46:27.135: CRYPTO_PKI:  Certificate Request Fingerprint MD5: 4D9971C8 F02B5822 B4062ABE E4FD370A
*Oct  4 17:46:27.147: CRYPTO_PKI:  Certificate Request Fingerprint SHA1: 1CD7E7FA B4A4016E 5A7D4F9E FEDD64BD D3234946
c2(config)#
on va donc sur C1:
C1#sh crypto pki server carsa requests
Enrollment Request Database:

Subordinate CA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

RA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

Router certificates requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------
1      pending    B50C87B6E5AD25927EFDB485EF0003ED hostname=C2

C1#crypto pki server carsa grant 1
C1#sh crypto pki server carsa requests
Enrollment Request Database:

Subordinate CA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

RA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

Router certificates requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------
1      granted    B50C87B6E5AD25927EFDB485EF0003ED hostname=C2
on doit voir sur C2:
*Oct  4 18:17:32.151: %PKI-6-CERTRET: Certificate received from Certificate Authority
Maintenant on fait pareil sur C3 ET C1 (les certificats sur C1 servent pour le serveur, pas pour que notre routeur s’authentifie !).

Configuration du GET VPN

Donc le chiffrement va se faire au niveau des clients (C#). Au niveau du process, on a une isakmp (1ère phase uniquement) qui va permettre d’établir une connexion sécurisée entre les différents routeurs, puis GDOI (port UDP 848, ISAKMP=500) va gérer les clés IPSec (au lieu de la phase 2 isakmp).
On a un routeur qui fera office de keyserver (KS) et qui distribuera les TEK ainsi que les message de rekeying, et aura aussi la fonction d’indiquer aux autres routeurs (Group member) le traffic à sécuriser (via une ACL).
Note: on peut redonder les KS.
Note2 (edit): Le KS ne peut, à ma connaissance forwarder du trafic, il est uniquement la pour synchroniser les différents routeurs afin qu’ils puissent communiquer de manière sécurisée, mais ne communique pas. Si quelqu’un toutefois à réussi à faire en sorte que le KS puisse forwarder du trafic, je suis preneur !
Il faut donc que tous nos routeurs aient une policy isakmp identique:
C1(config)#crypto isakmp policy 666
C1(config-isakmp)#auth rsa-sig
C1(config-isakmp)#hash sha
C1(config-isakmp)#group 5
C1(config-isakmp)#exi
Ensuite, coté KS, on créé un transform set et un profile ipsec qui utilise ce transform set, puis une ACL pour le traffic à chiffrer, et enfin la config GDOI.
C1(config)#crypto ipsec transform-set TSET1 esp-aes
C1(cfg-crypto-trans)#mode transport
C1(cfg-crypto-trans)#exi
C1(config)#crypto ipsec profile P1
C1(ipsec-profile)#set transform-set TSET1
C1(ipsec-profile)#exi
C1(config)#ip access-list extended private-traffic
C1(config-ext-nacl)#deny udp any eq 848 any eq 848 ! on chiffre pas GDOI
C1(config-ext-nacl)#permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255
C1(config-ext-nacl)#exi
C1(config)#crypto gdoi group GETVPN1
C1(config-gdoi-group)#identity number 1234 ! doit matcher sur les GM
C1(config-gdoi-group)#server local
C1(gdoi-local-server)#rekey ? ! ici je laisse tout par défaut
 address         Define the rekey packet format
 algorithm       Set the rekey encryption algorithm
 authentication  Identify the rekey authentication keypair
 lifetime        Define the rekey lifetime
 retransmit      Define the rekey retransmission parameters
 transport       Specify the rekey distribution method

C1(gdoi-local-server)#sa ipsec 1
C1(gdoi-sa-ipsec)#profile P1
C1(gdoi-sa-ipsec)#match address ipv4 private-traffic
C1(gdoi-sa-ipsec)#exi
C1(gdoi-local-server)#address ipv4 10.1.1.2 !interface d'écoute
C1(gdoi-local-server)#exi
C1(config-gdoi-group)#exi
Coté client on va voir que c’est beaucoup plus simple, tout est géré par le KS quasiment:
C2(config)#crypto gdoi group GETVPN1
C2(config-gdoi-group)#identity number 1234
C2(config-gdoi-group)#server address ipv4 10.1.1.2
C2(config-gdoi-group)#exi
C2(config)#crypto map GETMAP 10 gdoi
% NOTE: This new crypto map will remain disabled until a valid
 group has been configured.
C2(config-crypto-map)#set group GETVPN1
C2(config-crypto-map)#exi
C2(config)#int F1/0
C2(config-if)#crypto map GETMAP
Et la normalement, tout est bon.
J’ai eu quelques messages sur C2 et C3:
*Oct  4 18:47:43.275: %CRYPTO-5-GM_REGSTER: Start registration to KS 10.1.1.2 for group GETVPN1 using address 10.1.3.2
C3(config-if)#dow
*Oct  4 18:47:43.307: %CRYPTO-6-IKMP_NO_PRESHARED_KEY: Pre-shared key for remote peer at 10.1.1.2 is missing
*Oct  4 18:47:43.319: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
C3(config-if)#do
*Oct  4 18:47:45.743: %GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.1.2 complete for group GETVPN1 using address 10.1.3.2
Ce qui je penses est du au fait que les policy isakmp par défaut sous IOS 15.0 utilise les PSK, et vu que j’ai fait une policy démoniaque (#666) ce n’était peut être pas la première testée, en conséquence de quoi les routeurs veulent s’auth via PSK, ils trouvent pas de PSK, ils passent en rsa-sig
quelques vérifs:
C1#sh crypto gdoi
GROUP INFORMATION

 Group Name               : GETVPN1 (Multicast)
 Group Identity           : 1234
 Group Members            : 2
 IPSec SA Direction       : Both
 Group Rekey Lifetime     : 86400 secs
 Rekey Retransmit Period  : 10 secs
 Rekey Retransmit Attempts: 2

 IPSec SA Number        : 1
 IPSec SA Rekey Lifetime: 3600 secs
 Profile Name           : P1
 Replay method          : Count Based
 Replay Window Size     : 64
 SA Rekey
 Remaining Lifetime  : 3300 secs
 ACL Configured         : access-list private-traffic

 Group Server list       : Local

C1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.1.1.2        10.1.2.2        GDOI_IDLE         1005 ACTIVE
10.1.1.2        10.1.3.2        GDOI_IDLE         1006 ACTIVE

IPv6 Crypto ISAKMP SA
!!!!!!!!!!!!
C2#sh crypto gdoi ipsec sa

SA created for group GETVPN1:
 FastEthernet1/0:
 protocol = ip
 local ident  = 10.1.0.0/16, port = 0
 remote ident = 10.1.0.0/16, port = 0
 direction: Both, replay: Disabled

C2#sh crypto gdoi gm      
Group Member Information For Group GETVPN1:
 IPSec SA Direction       : Both
 ACL Received From KS     : gdoi_group_GETVPN1_temp_acl

 Group member             : 10.1.2.2         vrf: None
 Registration status   : Registered
 Registered with       : 10.1.1.2
 Re-registers in       : 3001 sec
 Succeeded registration: 1
 Attempted registration: 5
 Last rekey from       : 0.0.0.0
 Last rekey seq num    : 0
 Multicast rekey rcvd  : 0
Notez que le KS ne peut faire partie du VPN, ce que je n’avais prévu, sinon j’aurai rajouté un routeur. Pour le KS, il doit soit avoir une connexion dédiée accessible depuis tous les GM, soit être connecté derrière un GM (le GM ne doit pas passer par le KS pour avoir accès au VPN).
Bon pour que vous soyez pas trop déçu, je vous redonne quelques commandes show coté KS:
C1#sh crypto gdoi ks members 

Group Member Information : 

Number of rekeys sent for group GETVPN1 : 0

Group Member ID    : 10.1.2.2
 Group ID          : 1234
 Group Name        : GETVPN1
 Key Server ID     : 10.1.1.2

Group Member ID    : 10.1.3.2
 Group ID          : 1234
 Group Name        : GETVPN1
 Key Server ID     : 10.1.1.2

C1#sh crypto gdoi ks po      
C1#sh crypto gdoi ks policy
Key Server Policy:
For group GETVPN1 (handle: 2147483650) server 10.1.1.2 (handle: 2147483650):

 # of teks : 1  Seq num : 0
 kek policy : FALSE 

 TEK POLICY (encaps : ENCAPS_TRANSPORT)
 spi                : 0xFA94E73B
 access-list        : private-traffic
 transform          : esp-aes
 alg key size       : 16            sig key size          : 0         
 orig life(sec)     : 3600          remaining life(sec)   : 411       
 tek life(sec)      : 3600          elapsed time(sec)     : 3189      
 override life (sec): 0             antireplay window size: 64        

C1#sh cry
C1#sh crypto se
C1#sh crypto session
Crypto session current status

Interface: FastEthernet1/0
Session status: UP-IDLE
Peer: 10.1.2.2 port 848
 IKE SA: local 10.1.1.2/848 remote 10.1.2.2/848 Active 

Interface: FastEthernet1/0
Session status: UP-IDLE
Peer: 10.1.3.2 port 848 
 IKE SA: local 10.1.1.2/848 remote 10.1.3.2/848 Active 

C1#
et coté GM
C2#sh crypto ipse sa

interface: FastEthernet1/0
 Crypto map tag: GETMAP, local addr 10.1.2.2

 protected vrf: (none)
 local  ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
 remote ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
 current_peer 0.0.0.0 port 848
 PERMIT, flags={origin_is_acl,}
 #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
 #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
 #pkts compressed: 0, #pkts decompressed: 0
 #pkts not compressed: 0, #pkts compr. failed: 0
 #pkts not decompressed: 0, #pkts decompress failed: 0
 #send errors 0, #recv errors 0

 local crypto endpt.: 10.1.2.2, remote crypto endpt.: 0.0.0.0
 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
 current outbound spi: 0xFA94E73B(4204062523)
 PFS (Y/N): N, DH group: none

 inbound esp sas:
 spi: 0xFA94E73B(4204062523)
 transform: esp-aes ,
 in use settings ={Transport, }
 conn id: 1, flow_id: SW:1, sibling_flags 80000000, crypto map: GETMAP
 sa timing: remaining key lifetime (sec): (303)
 Kilobyte Volume Rekey has been disabled
 IV size: 16 bytes
 replay detection support: N
 Status: ACTIVE
!!!!...!!!!!
C2#sh crypto session
Crypto session current status

Interface: FastEthernet1/0
Session status: UP-ACTIVE     
Peer: 0.0.0.0 port 848 
 IKE SA: local 10.1.2.2/848 remote 10.1.1.2/848 Active
 IPSEC FLOW: permit ip 10.1.0.0/255.255.0.0 10.1.0.0/255.255.0.0
 Active SAs: 2, origin: crypto map
C2#sh crypto gdoi gm acl
Group Name: GETVPN1
 ACL Downloaded From KS 10.1.1.2:
 access-list  permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255
 ACL Configured Locally:
bon il y en a d’autres, mais maintenant on va conclure par un petit ping voir la différence ! Ce coup ci je vais pinger entre C2 et C3 et sniffer sur Core3 F2/0.
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.3.2, timeout is 2 seconds:
Packet has data pattern 0xDEAD
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 248/274/304 ms
et la pas de suprise, on voit plus de traffic en clair, mais bien du traffic sécurisé via ESP.