Andres Christophe

Travail de Bachelor 2016
Intégration et implémentation du
protocole IPv6 pour des services Cloud
Période de réalisation Juillet à septembre 2016
Filière Télécommunications
Réseaux et Services
Auteur Andres Christophe

Heig-vd
Conseiller Füllemann Pierre

Heig-vd
Mandant Pose Javier

Cisel informatique SA
Travail de Bachelor
Préambule
Ce travail de Bachelor est réalisé en vue de l’obtention du titre de Bachelor of Sciences en Ingénierie.
Son contenu, sans préjuger de sa valeur, n’engage ni la responsabilité de l’auteur, ni celles du jury du
travail de Bachelor et de l’Ecole.
Aucune utilisation, même partielle, de ce travail ne peut être faite sans l’autorisation écrite préalable de la
Direction. Toutefois, l’entreprise ou l’organisation qui a confié un sujet de travail de Bachelor peut utiliser
les résultats du travail pour ses propres besoins.
La cheffe du
Département de la formation En
Emploi
L. Larghi
Yverdon-les-Bains, septembre 2016
HEIG-VD, av. Sport 20, 1401 Yverdon-les-Bains

Tél. 024/557 76 09 / 07 Fax : 024/557 76 01
Intégration et implémentation du protocole IPv6 pour des services Cloud | Andres Christophe
Résumé
Afin de bénéficier des avantages du protocole IPv6, CISEL souhaite l’intégrer pour les différents services
Cloud qu’elle propose à ses clients. Ce travail de diplôme développe dans un premier temps un concept
de migration incluant les méthodes de transition Dual-Stack et NAT64. Sur cette base un réseau de test
« POC » a été configuré et a permis de confirmer la compatibilité des services de base (routage, DNS,
IPAM, filtrage IP, reverse Proxy) ainsi que deux des principaux services Cloud proposés par le mandant.
Une documentation complète dans le but d’un déploiement futur de la solution a également été
établie.
RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 1 | 149

Table des matières

1. Introduction..................................................................................................................................... 7
1.1. Présentation de l’entreprise.................................................................................................... 7
1.2. Contexte .................................................................................................................................. 8
2. Présentation du protocole IPv6 ....................................................................................................... 8
2.1. Entête IPv6 vs IPv4 ................................................................................................................ 10
2.1.1. Correspondances ........................................................................................................... 11
2.1.2. Fragmentation ............................................................................................................... 12
2.2. Adresse IPv6 .......................................................................................................................... 12
2.2.1. Types d’adresses............................................................................................................ 13
2.2.2. Les Adresses Unicast ..................................................................................................... 14
2.2.3. Les Adresses Anycast ..................................................................................................... 17
2.2.4. Les Adresses Multicast .................................................................................................. 17
2.3. ICMPv6 .................................................................................................................................. 18
2.3.1. ICMPv6 error message .................................................................................................. 19
2.3.2. ICMPv6 Informational Messages ................................................................................... 20
2.4. Path MTU Discovery .............................................................................................................. 21
2.5. Neighbor Protocol ................................................................................................................. 22
2.6. Stateless Address Autoconfiguration .................................................................................... 23
2.7. Méthode de transition vers IPV6 .......................................................................................... 24
2.7.1. Dual-Stack IPV4/IPV6..................................................................................................... 24
2.7.2. Tunneling over IPv4 ....................................................................................................... 26
2.7.3. 6to4 Tunnels .................................................................................................................. 27
2.7.4. NAT64 ............................................................................................................................ 28
2.7.5. Autres possibilités ......................................................................................................... 29
3. Cahier des charges......................................................................................................................... 30
3.1. Problématique ....................................................................................................................... 30
3.2. Objectifs................................................................................................................................. 30
4. Analyse .......................................................................................................................................... 31
4.1. Résumé de la situation .......................................................................................................... 31
4.2. Concept de migration des services Cloud ............................................................................. 32
4.2.1. Concept réseau .............................................................................................................. 32
4.2.2. Concept service Cloud ................................................................................................... 33

4.2.3. Conclusion Concept ....................................................................................................... 35

4.3. Plan d’adressage IPv6 ............................................................................................................ 36
4.3.1. Concept d’adressage ..................................................................................................... 38
4.4. Stratégie de tests ................................................................................................................... 40
5. Analyse de risque .......................................................................................................................... 40
6. Réalisation de la maquette............................................................................................................ 42
6.1. Configuration du routeur ASR1001 ....................................................................................... 42
6.1.1. Configuration du routage BGP ...................................................................................... 43
6.1.2. Configuration de l’interface 0/0/0 ................................................................................ 43
6.1.3. Configuration de l’interface 0/0/1 ................................................................................ 44
6.1.4. Contrôle de la configuration.......................................................................................... 44
6.1.5. Connexion entre le routeur et firewall .......................................................................... 45
6.2. Configuration du firewall Externe en Dual-Stack .................................................................. 46
6.2.1. Configuration de base ................................................................................................... 46
6.2.2. Création des zones ........................................................................................................ 46
6.2.3. Configuration des interfaces outside et inside.............................................................. 47
6.2.4. Configuration des interfaces pour les DMZ ................................................................... 49
6.2.5. Création des objets........................................................................................................ 50
6.2.6. Création des règles ........................................................................................................ 50
6.2.7. Configuration du routage static .................................................................................... 51
6.3. Configuration du firewall Interne en Dual-Stack ................................................................... 53
6.3.2. Configuration des zones ................................................................................................ 54
6.3.3. Configuration de l’interface outside ............................................................................. 54
6.3.4. Configuration des sous-interfaces ................................................................................. 55
6.3.5. Création des objets........................................................................................................ 56
6.3.6. Configuration des règles................................................................................................ 57
6.3.7. Configuration du routage .............................................................................................. 58
6.3.8. Test de connexion ......................................................................................................... 58
6.4. Configuration du switch Cisco Catalyst 2960 ........................................................................ 60
6.4.2. Configuration des VLAN et adresse IP du switch........................................................... 61
6.4.3. Configuration des interfaces 1 et 2 ............................................................................... 61
6.4.4. Configuration de l’interface 3........................................................................................ 62

6.4.5. Configuration des interfaces 4, 5 et 6 ........................................................................... 62

6.4.6. Configuration des interfaces 7 et 8 ............................................................................... 63
6.4.7. Configuration de l’interface gigabit ............................................................................... 63
6.4.8. Connexion câbles ........................................................................................................... 63
6.5. Configuration de la plateforme Infoblox ............................................................................... 64
6.5.2. Configuration lan1, lan2 et MGMT ................................................................................ 65
6.5.3. Configuration DHCPv6 ................................................................................................... 66
6.5.4. Configuration DHCPv4 ................................................................................................... 70
6.5.5. Utilisation de l’IPAM Infoblox ........................................................................................ 71
6.5.6. Configuration du DNS .................................................................................................... 74
6.6. Configuration de l’environnement Vmware ......................................................................... 83
6.6.1. Configuration des switch ............................................................................................... 83
6.6.2. Contrôle de la configuration.......................................................................................... 85
6.6.3. Configuration du serveur............................................................................................... 86
6.6.4. Configuration du Virtual switch VMware ...................................................................... 86
6.6.5. Création du volume de stockage ................................................................................... 87
6.7. Installation serveur Active Directory ..................................................................................... 88
6.7.1. Configuration réseau ..................................................................................................... 88
6.7.2. Installation Active Directory .......................................................................................... 90
6.8. Installation du serveur Exchange .......................................................................................... 92
6.8.1. Configuration réseau ..................................................................................................... 93
6.8.2. Ajout de du serveur dans le domaine ........................................................................... 94
6.8.3. Installation d’Exchange.................................................................................................. 95
6.8.4. Configuration d’exchange ............................................................................................. 96
6.8.5. Création du certificat ..................................................................................................... 99
6.8.6. Configuration du connecteur de réception ................................................................. 100
6.8.7. Installation du certificat............................................................................................... 103
6.9. Installation du réseau client de test .................................................................................... 104
6.9.1. Création du Tunnel ...................................................................................................... 105
6.9.2. Configuration du firewall ............................................................................................. 105
6.9.3. Validation sur poste de test client............................................................................... 108
6.10. Installation du « Reverse-Proxy » pour Exchange ........................................................... 109
6.10.1. Configuration des interfaces ....................................................................................... 110

6.10.2. Configuration de l’interface de management ............................................................. 110

6.10.3. Configuration de l’interface Proxy_pub ...................................................................... 111
6.10.4. Configuration de l’interface Proxy_priv ...................................................................... 111
6.10.5. Configuration du HAPROXY ......................................................................................... 112
6.10.6. Génération du certificat au format pem ..................................................................... 113
6.11. Installation du Serveur CISSYNC ...................................................................................... 115
6.11.1. Préparation du serveur Linux ...................................................................................... 115
6.11.2. Configuration des interfaces réseaux .......................................................................... 116
6.11.3. Création du certificat ................................................................................................... 117
7. Validation du service Cloud Exchange ......................................................................................... 118
7.1. Ajustement de la configuration ........................................................................................... 118
7.2. Test d’accès configuration Dual-Stack................................................................................. 119
7.3. Test d’accès configuration IPv4 ........................................................................................... 121
7.4. Test d’accès configuration IPv4 avec NAT64 ....................................................................... 122
7.5. Transfert flux IPv4 vers IPv6 depuis HAPROXY .................................................................... 123
7.6. Conclusion des tests ............................................................................................................ 124
8. Validation du service CISSYNC ..................................................................................................... 125
8.1. Test d’accès configuration Dual-Stack................................................................................. 125
8.1.1. Accès au service web ................................................................................................... 125
8.1.1. Accès à la synchronisation de fichier........................................................................... 126
8.2. Test d’accès configuration IPv4 ........................................................................................... 127
8.2.1. Accès au service web ................................................................................................... 127
8.2.2. Accès au service de synchronisation ........................................................................... 127
8.3. Conclusion des tests ............................................................................................................ 128
9. Validation des switch layer 3 ...................................................................................................... 128
9.1. Nexus 5548 .......................................................................................................................... 128
9.2. Cisco 3750-X ........................................................................................................................ 128
10. Evaluation de la plateforme Infoblox ...................................................................................... 129
11. Prochaines étapes ................................................................................................................... 129
12. Conclusion ............................................................................................................................... 130
13. Remerciements ....................................................................................................................... 131
14. Listes des figures ..................................................................................................................... 133
15. Listes des tableaux .................................................................................................................. 139
16. Annexes ................................................................................................................................... 140

16.1. Planification ..................................................................................................................... 140

16.2. Journal de travail ............................................................................................................. 140
16.3. Listes des symboles et abréviations ................................................................................ 148
16.4. Liste des références ......................................................................................................... 149

1.Introduction
1.1. Présentation de l’entreprise
CISEL Informatique SA est une société active dans les prestations de services informatiques. Elle fut
créée en 1971. Le siège de l’entreprise se situe à Matran (FR) et la succursale à Morges (VD). Sur les
deux sites réunis, on dénombre plus de 80 collaborateurs.
L’entreprise propose 4 principaux types de prestations :
• Le Cloud : Hébergement des ressources informatiques au sein de l’infrastructure CISEL, afin de

mettre à disposition ces ressources aux entreprises clientes externes. C’est sur cette prestation
que porte le travail de diplôme.
• Solutions et infrastructures : infrastructures et systèmes, services managés, réseau et sécurité,
délégation
• SAP et solutions métiers : SAP Business One, SAP Business Suite, Consulting et délégation
• Printing : Impression & mise sous pli
La clientèle de CISEL Informatique est essentiellement composée de PME en Suisse romande, de tailles
et de secteurs d’activités différents : de grands comptes tels que Groupe E, Romande Energie, CIMO,
mais également des sociétés plus petites telles que des boucheries, des communes ou encore des
cabinets médicaux.
Figure 1-1 | Logo de CISEL Informatique

1.2. Contexte
Afin de bénéficier des avantages du protocole IPv6, CISEL souhaite l’intégrer pour les différents services
Cloud qu’elle propose à ses clients. Dans ce travail de diplôme, il est prévu d’établir dans un premier
temps un concept, sur la base duquel il faudra mettre en place une démonstration représentative de
l’infrastructure actuellement en place chez CISEL informatique.
Une fois la maquette validée, il sera par la suite possible de reprendre ce concept afin de mettre en
place IPV6 pour les services Cloud sur l’infrastructure Cisel. Cisel ayant choisi comme méthode de
transition Dual-Stack, il est également important de confirmer la compatibilité des équipements avec
ce moyen de transition. Les services de base (routage, DNS, IPAM, filtrage IP, reverse Proxy) devront
être évalués et s’il n’est pas possible de configurer Dual-Stack sur les équipements qui fournissent ce
service, il faudra proposer une solution alternative.
Les techniques de transition NAT64 et tunneling over IPv4 seront également utilisées, cela se configure
directement sur les firewalls, il faudra donc vérifier également que ceux-ci sont compatibles avec ces
technologies.
Il est donc important pour Cisel d’intégrer ce nouveau protocole IPv6 progressivement. La méthode
Dual-Stack permet justement de faire coexister sur une longue période IPv4 et IPv6 au sein du même
réseau. De cette manière, il sera possible également pour Cisel de migrer vers IPv6, autre service que
le Cloud et même, à terme, d’avoir une configuration native IPv6 sur tous les équipements. Ce travail
n’est pas le but, mais il permet une introduction d’IPv6 afin de se familiariser avec ce nouveau
protocole et pouvoir ensuite le maîtriser.
2.Présentation du protocole IPv6

L’essentiel des réseaux informatiques et de télécommunication est actuellement basé sur le protocole
IPv4 (internet Protocol version 4). Le problème qui se manifeste ces dernières années est le manque
d’adresses publiques IPV4. La solution qui a été apportée pour palier à ce problème est l’utilisation du
NAT (Network Address Translation). NAT possède cependant des inconvénients, comme par exemple
le fait que la connexion ne se fasse plus de client à client (host-to-host connectivity). C’est une des
nombreuses raisons qui nous pousse à migrer vers la nouvelle version du protocole qui s’intitule IPv6
(Internet Protocol version 6). Avec IPV6 on ne peut plus vraiment parler de limitation d’adresses
publiques, car il faudrait placer plus de 667 millions de milliards d’appareils connectés à internet sur
chaque millimètre carré de surface terrestre pour arriver à saturation1.
1
Source : https://fr.wikipedia.org/wiki/Adresse_IPv6

On peut citer les avantages et bénéfices d’IPv6 suivants :
• Extension de la plage d’adresse IP avec 128 bits contre 32 pour IPv4

• Auto-configuration par l’hôte de son adresse IPv6 routable sur Internet
• Plus de nécessité d’utiliser NAT/PAT, car tous les équipements peuvent obtenir une adresse
public
• Plus d’utilisation du broadcast (moins efficace que le multicast)
• Nombreuses méthodes de transition vers IPv6 (Dual-Stack ou tunneling)
Sur l’image ci-dessous, on peut constater que la Suisse est bien placée au niveau des pays européens
en termes de déploiement du protocole IPV6. Elle possède l’indice 8.6 sur 10 et compte 28%
d’utilisateurs finaux qui peuvent consulter du contenu avec le protocole IPV6.
Figure 2-1 | Statistiques de l’utilisation d’IPV6 en suisse
2
Source : http://6lab.cisco.com/stats/index.php

2.1. Entête IPv6 vs IPv4

Voici la structure de l’entête IPv4 (RFC 791)
Figure 2-2 | entête IPv4
Et voici celle d’IPv6 (RFC 2460)
Figure 2-3 | Entête IPv6
La taille de l’entête IPv6 est de 40 octets. Contrairement à IPv4 cette taille est fixe, en effet avec IPv4
la taille de l’entête peut varier de 20 à 60 octets selon l’option, même s’il est rare de voir en pratique
des tailles d’entête différentes de 20 octets pour IPv4.
On peut constater qu’il y a moins de champs utilisés pour l’entête IPv6 que pour IPv4. Voici la
signification des champs pour IPv6 :
• Version (4 bits) : correspond à la version du protocole internet, cette valeur est fixée à 6 pour
IPv6
• Traffic Class (8 bits) : Utilisé pour la qualité de service
3
Source : GRAZIANI, Rick. IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6.
CiscoPress. 2013.
4
CiscoPress. 2013.

• Flow Label (20 bits) : Permet de marquer un flux pour un traitement spécial (Paquets voix et
vidéo d’une vidéo-conférence)
• Payload Length (16 bits) : Taille de données utiles du paquet (Entête IPv6 non-compris)
• Next Header (8 bits) : Identifie le protocole de couche supérieure ou une extension de
l’entête IPv6
• Hop Limit (8 bits) : Durée de vie du paquet IPv6
• Source Address (128 bits) : L’adresse IPv6 de l’expéditeur
• Destination Address (128 bits) : L’adresse IPv6 du destinataire
2.1.1. Correspondances
Voici les correspondances des champs IPv4 et IPv6:
IPv6 IPv4
Traffic Class Type of Service
Payload Length Total Length
Hop Limit Time to live
Next Header Protocol
Tableau 2-1 | correspondances IPv4/IPv6
On peut ajouter que pour le champ « Payload Length » on ne prend pas en compte la taille de l’entête
contrairement à « total Lenght ».
Il est également important de relever que contrairement à «Protocol » qui ne contient uniquement
que la valeur du protocole transporté, « Next Header » peut également contenir la valeur d’une
prochaine en-tête ou extension de l’en-tête IPv6.
Voilà trois exemples pour mieux comprendre le « Next Header » avec à chaque fois une valeur
différente, pour la première du TCP, UDP et pour finir de l’ICMPv6.
Figure 2-4 | Next Header IPv6
5
CiscoPress. 2013.

2.1.2. Fragmentation
La différence sur le traitement de la fragmentation avec IPv6 est un point important à expliquer. En
effet, contrairement au Protocol IPv4, seuls les expéditeurs peuvent fragmenter les paquets. Les
équipements intermédiaires (routeurs) ne peuvent pas fragmenter des paquets IPv6. Il est donc
impératif pour l’expéditeur de connaître le MTU (Maximum Transmission Unit) sur tout le chemin
entre la source et la destination. Si un routeur reçoit un paquet IPv6 trop volumineux pour le
transmette, il supprimera le paquet et répondra à l’expéditeur avec un message ICMPv6 « Packet Too
Big ».
2.2. Adresse IPv6

Les adresses ipv6 sont représentées sur 128 bits et contiennent des chiffres en hexadécimale, l’adresse
n’est pas « case sensitive ». Elle contient 6 « hextet ». Un hextet est un groupe de 4 « digits » en
hexadécimale, comme on peut le voir ci-dessous :
Figure 2-5 | Format adresse IPv6
Il est possible de supprimer les zéros à gauche dans les hextets, exemple avec l’adresse
2001:0DB8:AAAA:0001:0000:0000:0000:0200 -> 2001:DB8:AAAA:1:0:0:0:200
On peut aussi écrire « :: » au lieu des blocs de hextet contigus qui ne contiennent que des zéros :
FF02:0000:0000:0000:0000:0000:0000:0001 -> FF02::0001
6
CiscoPress. 2013.

Attention le « :: » ne peut être utilisé qu’une fois dans le bloc d’adresse, sinon on ne peut pas
reconstruire l’adresse sans ambiguïté.
On peut bien sûr combiner les deux écritures :
FF02:0000:0000:0000:0000:0000:0000:0001 -> FF02::1
L’écriture pour le masque de l’adresse IPv6 s’écrit de la même manière que pour CIDR :
Adresse IPv6/longueur du préfixe
Exemple pour l’adresse
2001:0DB8:AAAA:1111:0000:0000:0000:0000/64
2.2.1. Types d’adresses
Les trois types d’adresses sont les suivantes :
• Unicast
• Anycast
• Multicast
Voici un schéma qui résume bien les trois types d’adresses et ses sous-types possibles.
Figure 2-6 | Types d’adresses IPv6
7
CiscoPress. 2013.

2.2.2. Les Adresses Unicast
Ce sont les adresses liées à une interface sur une machine ou un équipement. Quand on envoie un
paquet sur une adresse « Unicast », on cible donc une interface avec une adresse IP.
On peut voir les types d’adresses « Unicast » suivants :
Global Unicast
Ce sont les adresses Global routables et atteignables via internet en IPv6. Elles équivalent aux adresses
publiques pour IPv4.
Voici un schéma de la structure d’adresse :
Figure 2-7 | Structure adresse IPv6
On constate que les 48 premiers bits de l’adresse sont utilisés pour être routés sur internet et ne
doivent en principe pas être modifiés. Les 16 prochains bits sont utilisés pour faire les sous-réseaux,
soit un nombre total de de 65 537 sous-réseaux possibles. Les 64 derniers bits sont pour les interfaces
des machines ou équipements. En général une machine aura une adresse de type
2001:DEAD:BEEF::2/64. A savoir que pour utiliser la technologie « SLAAC » que nous verrons par la
suite (auto configuration de l’adresse IP par l’interface), il faut avoir une configuration des adresses en
/64.
Voici un exemple d’une configuration possible pour un plan d’adressage :
8
CiscoPress. 2013

Figure 2-8 | Exemple de plan d’adressage IPv6
On constate que même pour les liaisons inter-routeur on utilise un masque /64. En effet, on dispose
de tellement de sous-réseaux possibles qu’on n’est plus du tout dans la même logique que pour les
plans d’adressage en IPv4 où il faut économiser les adresses.
Pour configurer une adresse « Global » il faut que l’interface ait une adresse Link-Local configurée. On
arrive à configurer une adresse « Global » de manière dynamique ou statique, comme c’est le cas pour
IPv4.
Voici les différentes options pour les deux possibilités :
10
Figure 2-9 | Options de configuration d’adresse Global Unicast
Mode manuel
9
CiscoPress. 2013
10
CiscoPress. 2013

• Static permet de configurer l’adresse et son préfixe de la même manière qu’avec IPv4.
• EUI-64 permet de ne configurer que le préfixe et la longueur du préfixe à 64, le reste de
l’adresse (interface ID) est générée automatiquement via un algorithme qui prend en compte
l’adresse MAC de la carte réseau.
Mode dynamique
• Stateless Autoconfiguration permet la configuration automatique de l’adresse via les

messages RA du routeur qui informe l’hôte sur le préfixe à utiliser et sa longueur et permet
ensuite la génération du reste de l’adresse via EUI-64. Ce point est décrit plus en détails dans
son chapitre dédié.
• DHCPv6 se distingue en deux types. Le premier « Stateful » distribue l’adresse IPv6 de façon
similaire à IPv4 avec DHCPv4. Le deuxième « Stateless » distribue uniquement des paramètres
complémentaires et non l’adresse IP.
Unique local
Il s’agit des adresses équivalentes aux adresses privées sur IPv4. Il n’est pas conseillé d’utiliser ces
adresses.
Link-Local
Chaque interface doit obligatoirement avoir une adresse Link-Local afin d’avoir une adresse Global.
L’adresse Link-Local permet de communiquer sur son réseau local, mais ce n’est pas une adresse
routable, si un routeur reçoit un paquet destiné à une adresse Link-Local, le routeur va soit traiter le
paquet, car il lui est destiné, soit le rejeter.
Voici donc l’utilisation de l’adresse « Link-Local »
• Avant l’obtention d’une adresse IPv6 routable

• Pour identifier la passerelle par défaut d’une interface (on utilise la « Link-Local », adresse du
routeur)
• Pour l’échange des informations de routage par les routeurs (protocoles dynamiques).
La configuration de l’adresse peut également se faire manuellement ou de manière automatique.
Unspecified
Elle indique l’absence d’une adresse IPv6.
Loopback
Comme pour IPv4 avec une longueur différente ::1/128. Adresse uniquement utilisée localement par
l’hôte.

2.2.3. Les Adresses Anycast
Comme pour IPv4 une adresse Anycast est une adresse unicast configurée sur plusieurs équipements.
Quand on envoie un paquet à une adresse anycast, seul l’équipement le plus « proche » configuré avec
l’adresse unicast reçoit le paquet via la méthode de routage.
2.2.4. Les Adresses Multicast
Une adresse multicast identifie un groupe d’équipements, un paquet envoyé à une adresse multicast
sera reçu par tous les équipements de ce groupe, contrairement à l’adresse unicast. Il faut préciser
qu’il n’y a pas d’adresse broadcast dans IPv6.
Assigned
Il s’agit d’adresses prédéfinies pour des besoins particuliers. Par exemple l’adresse FF01::2 qui
représente l’adresse de tous les routeurs. Voir la RFC 2375 pour plus de détails.

2.3. ICMPv6
On connaît ICMP avec IPv4, très connu pour la commande « Ping » pour vérifier si une machine est
atteignable sur le réseau. Ce protocole permet principalement de connaître la santé du réseau.
Avec ICMPv6 (RFC 4443) il existe de nouvelles fonctionnalités, celle qui nous intéresse particulièrement
permet de faire la liaison entre une adresse de couche 2 et une adresse de couche 3. Pour IPv4 il existe
ARP (Address Resolution Protocol). Avec ICMPv6 cette fonctionnalité est intégrée via le protocole ND
(Neigbhor Discovery Protocol).
Voici les deux types de message ICMPv6 :
• ICMP error messages, le champ « Type » est compris entre 0 et 127

• ICMP informational messages, le champ « Type » est compris entre 128 et 255
Voici comment se présente l’entête :
11
Figure 2-10 | Entête ICMPv6
On peut très clairement observer que les trois premiers champs « Type », « Code » et « Checksum »
restent inchangés de la version ICMP. Il faut cependant préciser que les numéros des types et des
codes des messages sont différents. La taille d’un paquet ICMPv6 ne peut pas être inférieure au
minimum MTU défini pour IPv6 étant de 1’280 Octets. Afin d’identifier un message ICMPv6, nous
aurons la valeur 58 dans le champ « Next Header » de l’en-tête IPv6 qui précède l’en-tête ICMPv6.
11
CiscoPress. 2013

2.3.1. ICMPv6 error message
Comme indiqué précédemment, le champ « Type » sera compris entre 0 et 127. Le champ code
contient des informations détaillées sur le type de message. Voici les quatre messages d’erreur
ICMPv6 :
1. « Destination Unreachable » le paquet n’a pas pu être délivré à destination
Valeur Valeur Signification

champ champ
type code
« No route to destination » : ce code est généré si un routeur n’a pas de route
0
dans sa table de routage pour cette destination et qu’il n’a pas de route par défaut.
« Communication with destination administratively prohibited » : ce code peut
1
être généré par un pare-feu si le type de paquet transmis est filtré.
« Beyond scope of Source address » : ce code est généré si l’adresse source n’est
2
pas atteignable.
« Address unreachable » : ce code est généré si l’adresse de destination n’est pas
1 3 atteignable.
« Port unreachable » : ce code est généré si le port de destination n’est pas

4
atteignable.
« Source address failed ingress/egress policy » : ce code est généré si l’adresse
5
source n’est pas autorisée par des règles de filtrage en entrée ou en sortie.
« Reject route to destination » : On peut apercevoir ce code si la route de
6
destination est une route refusée.
Tableau 2-2 | ICMP error valeur type 1
2. « Packet to big» le paquet est trop volumineux

champ champ
type code
2 0 « Packet to big »
On a également un champ MTU qui va s’ajouter dans l’en-tête ICMPv6 afin d’indiquer la valeur MTU
du prochain saut. Le mécanisme « PATH MTU DISCOVERY » utilise ce champ. Je décrirai plus en détail
dans le chapitre 2.4 ce mécanisme.

3. « Time Exceeded » le paquet n’a pas une durée de vie suffisante, ce qui se produit si le
champ « Hop Limit » de l’entête IPv6 ne peut plus être décrémenté, étant donné que chaque
routeur qui traite le paquet décrémente cette valeur de un.

champ champ
type code
« Hop limit exceeded in transit » : ce code est montré si la durée de vie initiale du
0 paquet IPv6 est trop basse, s’il existe une boucle de routage ou si l’outil «
traceroute » est utilisé.
3
« Fragment reassembly time exceeded » : ce code peut être aperçu si la
1 destination n’arrive pas à ré-assembler tous les différents fragments d’un paquet
IPv6 dans un temps limité.
4. « Parameter Problem » on ne peut pas identifier un champ de l’entête IPv6 ou l’entête dans
l’extension.
champ champ
type code
« Erroneous header field encountered » : ce code est visible si la destination a
0
détecté une erreur dans un champ de l’entête IPv6.
« Unrecognized next header type encountered » : ce code est généré si la valeur
4 1
du “Next Header” IPv6 n’est pas reconnue.
« Unrecognized IPv6 option encountered » : ce code est généré si une option IPv6
2
n’est pas reconnue.
On a également un champ Pointer qui va s’ajouter dans l’entête ICMPv6 afin d’indiquer la position de
l’erreur détectée.
2.3.2. ICMPv6 Informational Messages
Pour ces messages le champ « Type » sera compris entre 128 et 255. Ces types de message sont utilisés
également pour les technologies « Path MTU Discovery » et « Neighbor Discovery ». Je vais me
concentrer sur les autres types de messages qui ne concernent pas ces deux protocoles, car ceux-ci
seront décrits dans leur chapitre dédié.
1. « Echo Request Message »

champ champ
type code
128 0 « Echo Request »
Tableau 2-6 | ICMP Informational valeur type 128

On a également un champ « Identifier » et « Sequence Number » qui permettent de faire correspondre

une requête avec une réponse. Le champ data sera rempli avec des données aléatoires.
2. « Echo Reply Message » on retrouve la même structure que pour la requête.

champ champ
type code
129 0 « Echo Reply »
Tableau 2-7 | | ICMP Informational valeur type 129
2.4. Path MTU Discovery

Path MTU Discovery (RFC 1981) permet de connaître le plus petit MTU sur le chemin entre la source
et la destination. En fait, on veut savoir la taille maximale à laquelle on peut envoyer les paquets sur le
réseau sans qu’ils soient rejetés par un routeur si le paquet était trop volumineux. Il faut rappeler qu’il
n’est pas possible pour les routeurs de fragmenter les paquets avec IPv6. Il faut également préciser
que la taille minimale des paquets IPv6 sur internet doit être de 1280 octets contre 68 octets pour
IPv4. Cela permet de réduire la fragmentation des paquets.
Voici une illustration de Path MTU Discovery :
12
Figure 2-11 | fonctionnement de Path MTU Discovery
• Le PC A envoie un paquet à R1 de taille 1500 octets (taille MTU carte Ethernet)

• Le routeur R1 peut transmettre le paquet car il y une MTU vers R2 de 1500
• Le routeur R2 ne peut transmettre le paquet plus loin car il a une MTU de 1350 octets vers R3,
il renvoie donc une erreur ICMPv6 « packet too Big » au PC A avec la valeur de MTU vers R3 de
1350 octets
• Le PC A renvoie son paquet avec la MTU à 1350, cette fois le paquet peut atteindre PC B
Le PMTU peut varier, car le chemin entre la source et la destination peut changer, et est donc une
valeur qui peut être changée de manière dynamique.
12
CiscoPress. 2013

2.5. Neighbor Protocol

Neighbor Discovery Protocol (NDP ou ND) est défini dans la RFC 4861. C’est un nouveau protocole
implémenté dans IPv6 qui permet principalement de découvrir les adresses de couche 2 des
équipements qui se trouvent sur le même lien, mais aussi de vérifier la disponibilité de ces
équipements. On peut relever des similitudes avec les protocoles ARP, ICMP et Route Discovery et
redirect qui sont disponibles sur IPv4. Voici ses fonctionnalités :
• Duplicate Address Detection (DAD)

• Neighbor Unreachability Detection (NUD)
Le Protocole NDP est également utilisé pour l’autoconfiguration des adresses IPv6 « SLAAC ».
Voici plus en détail l’utilité de ce nouveau protocole :
• Détection automatique du préfixe du réseau, de la passerelle par défaut et des informations

de configuration afin d’effectuer la configuration automatique sans état (SLAAC)
• Détection d’une adresse « Link-Local » ou « Global Unicast » déjà utilisée sur le réseau (DAD)
• Détection de l’adresse de couche 2 (Data-link address)
• Maintien d’une trace des voisins disponibles et atteignables (NUD)
• Détection d’un chemin alternatif en cas de défaillance de la passerelle ou des routeurs
NDP utilise ICMPv6 pour garantir les fonctions décrites ci-dessus. Voici les messages ICMPv6 utilisés
par NDP :
Router Solicitation message « RS »
Permet l’autoconfiguration de l’adresse IPv6 via SLAAC, le message envoie le préfixe du réseau, sa
longueur, la passerelle par défaut et d’autres paramètres. Il sera émis par l’interface (l’hôte) pour qu’un
routeur puisse lui répondre avec un message RA. Le message est envoyé à l’adresse FF02::2 qui
correspond à l’adresse multicast de tous les routeurs.
Router Advertisement message « RA »
Comme on l’a vu ce message est émis par un routeur en réponse à un message RS, on peut également
configurer le routeur afin qu’il émette périodiquement des messages RS vers les hôtes. Ce message
comprend un champ qui indique si l’hôte doit utiliser un serveur DHCPv6.
Neighbor Solicitation message « NS »
Il permet de découvrir l’adresse de couche 2 d’un équipement sur le même lien, il est également utilisé
pour le mécanisme DAD et NUD
Neighbor Advertisement message « NA »
Il s’agit de la réponse au message NS, on renvoie l’adresse de couche 2 ainsi que l’adresse IPv6.
Redirect message

Il fonctionne de la même manière que sur IPv4, il permet d’informer d’un meilleur routeur du premier
saut « first-hop routeur »
2.6. Stateless Address Autoconfiguration

Stateless Address Autoconfiguration (SLAAC) est décrit dans la RFC 4862. SLAAC et permet à un hôte
une configuration automatique de son adresse Unicast. Il permet de générer une adresse « Link-Local »
ou « Global ». Les informations qui lui sont transmises par le routeur lui permettent de faire son
autoconfiguration. Avec le mécanisme DAD il va contrôler que cette adresse n’est pas déjà attribuée à
un autre équipement.
Voici un schéma qui indique clairement le processus de SLAAC. Dans un premier temps on va attribuer
une adresse Link-Local et ensuite une adresse Global :
Figure 2-12 | Distribution d’une adresse IPv6 via SLAAC
13
On peut constater que l’attribution d’une adresse IPv6 Global doit obligatoirement passer par la
réception d’un message RA provenant du routeur afin de connaître le préfixe et sa longueur. Il peut
13
CiscoPress. 2013

ensuite générer l’interface ID à l’aide de l’algorithme pseudo-aléatoire ou utiliser le processus EUI-64

basé sur l’adresse de couche 2 de l’interface. On utilise également DAD afin de contrôler que l’adresse
ne soit pas déjà attribuée.
Le client peut générer seul une adresse de lien local « Link-Local », soit en utilisant un algorithme
pseudo-aléatoire pour l’interface ID, soit en utilisant le mécanisme EUI-64.
2.7. Méthode de transition vers IPV6

Il existe plusieurs méthodes de transition développées par l’IETF (Internet Engineering Task Force). Il
est possible de transiter vers IPV6 en commençant par une petite partie du réseau (simple machine ou
sous-réseau). D’après mes recherches, je peux conclure que la meilleure méthode de transition est le
mode Dual-Stack, en configurant IPV6 nativement s’il est possible sur un maximum d’interfaces. Je
décris maintenant les méthodes de transition les plus utilisées vu l’importance de les connaître, afin
de faire le choix adapté à nos besoins. Ces différentes méthodes peuvent également être combinées.
On peut les classer en trois catégories :
• Dual-Stack : IPv4 et IPv6 coexistent sur le même réseau.
• Tunneling : permet de transporter des paquets IPv6 sur un réseau IPv4.
• Translation : Network Address Translation 64 (NAT64), permet la communication entre des

interfaces IPv6 et IPv4. Cette méthode de translation est semblable à celle utilisée pour le NAT
sur IPv4.
2.7.1. Dual-Stack IPV4/IPV6
Ce moyen de transition permet la coexistence d’IPV4 et d’IPV6 sur une interface, cela peut être un
simple périphérique réseau, un PC, un routeur ou n’importe quel équipement qui supporte le Dual-
Stack. Il est indispensable que l’application soit compatible IPv4/IPv6 pour bénéficier des avantages du
Dual-Stack. Cela permet à l’interface de communiquer soit via IPV4, soit via IPV6. L’interface doit
contenir au moins une adresse IP pour chaque protocole.
Le DNS doit pouvoir résoudre des requêtes DNS via des type d’enregistrements A pour les requêtes
IPV4 et des types AAAA pour des requêtes IPV6. Dès le moment où le serveur DNS retourne une
adresse IPV6, il faut que l’hôte source puisse atteindre la destination via le protocole IPV6. De ce fait,
tout le chemin réseau parcouru entre l’hôte et la destination doit être configuré également avec le
protocole IPV6. Il faut donc configurer les équipements réseau avec les deux protocoles. On peut dire
que c’est le désavantage de cette méthode de transition, puisqu’il y a une double configuration sur les
équipements, une pour le protocole Ipv4 et l’autre pour le protocole IPv6. Par exemple sur les routeurs
il faudra configurer les tables de routage pour IPV4 et IPV6. Pour l’administration du réseau il faudra
utiliser des commandes différentes en fonction du protocole. Tout cela nécessite plus de mémoire et
ressources processeur sur les équipements.

Si l’application gère IPV4 et IPV6, le DNS va retourner une adresse pour chaque protocole, c’est ensuite
le système d’exploitation qui choisira quelle adresse utiliser, dans la plupart des cas cela sera l’adresse
IPv6, mais peut dépendre des systèmes d’exploitation.
Figure 2-13 | Application utilisant Dual-Stack
14
Voici un schéma pour mieux comprendre les étapes :
1. La machine A envoie une requête au DNS de type AAAA pour www.exemple.com

2. Le Serveur DNS retourne la réponse avec l’adresse de type A et AAAA
3. La machine A utilise l’adresse AAAA pour se connecter sur www.exemple.com
Figure 2-14 | requête DNS IPv6 et IPv4
15
14
CiscoPress. 2013
15
CiscoPress. 2013

2.7.2. Tunneling over IPv4
Il s’agit d’une méthode de transition temporaire à utiliser pour au final avoir une configuration native
en IPv6 sur le réseau. On parle ici d’encapsulation des paquets IPv6 dans IPv4 afin de pouvoir
transmettre ces paquets sur un réseau purement IPv4. Le schéma ci-dessous illustre bien ce
fonctionnement :
16
Figure 2-15 | Tunneling IPv6 over IPv4 détails
Sur l’image ci-dessus, on constate qu’il y a le « Transport Protocol », le protocole IPv4 dans lequel le
tunnel est créé. On voit que le protocole dans l’entête IP est le 41, ce qui indique l’encapsulation d’IPv6.
Dans le « Passanger Protocol » on retrouve le paquet IPv6 encapsulé.
On constate également que de chaque côté du tunnel, l’équipement qui initie la connexion est
configuré en Dual-Stack. D’un côté il recevra les paquets en IPv6 et va ensuite les encapsuler dans IPv4
afin de les transmettre par le réseau IPv4. De l’autre côté du tunnel, l’équipement doit être configuré
en Dual-Stack afin de pouvoir recevoir le paquet encapsulé via IPv4 et le décapsuler afin de l’envoyer
via IPv6 à la bonne destination.
Il est également possible d’établir ce tunnel entre deux machines, ou entre une machine et un routeur
selon le même principe :
17
Figure 2-16 | Tunneling IPv6 over IPv4 scénarios
16
CiscoPress. 2013
17
CiscoPress. 2013

2.7.3. 6to4 Tunnels
Il est possible de configurer le tunnel de manière manuelle pour les petits réseaux. Pour les plus
grandes infrastructures, il est indispensable d’utiliser 6to4 qui permet la création automatique de
tunnels entre les réseaux IPv6 sur une liaison IPv4. La RFC 3056 donne plus de détails sur cette
implémentation.
Pour cette technologie on utilise un préfixe dédié : 2002 ::/16 qu’on complète avec l’adresse IPv4 ce
qui nous donne des adresses en /48 comme on peut le voir ci-dessous :
Figure 2-17 | exemple configuration de tunnel 6to4
18
On constate qu’il y a un tunnel créé pour plusieurs destinations. R1 est capable via son tunnel de
communiquer en IPv6 avec R2, R3 ou les autres routeurs. On appelle cette technologie « point-to-
multipoint connexion ».
18
CiscoPress. 2013

2.7.4. NAT64
Le NAT pour IPv4 était principalement utilisé pour translater une adresse privée en public, le NAT64
lui permet de manière transparente de faire le lien entre une adresse IPv4 et IPv6, afin de pouvoir
communiquer entre un réseau purement IPv4 vers IPv6. Il s’agit d’une méthode de transition à utiliser
à court terme. Elle permet de fournir des ressources en IPv6 aux clients qui sont en configuration IPv4
de manière transparente.
19
Figure 2-18 | NAT64 fonctionnement
NAT64 est le remplaçant de « NAT-PT », CISCO recommande d’utiliser NAT64 et non « NAT-PT ». Dans
notre cas, nous allons utiliser la translation d’IPv4 vers IPv6, ce qui permettra à un client qui se
connecte en IPv4 d’utiliser les services Cloud en IPv6. Voici un exemple de fonctionnement avec la
description pour chaque étape :
20
Figure 2-19 | Exemple complet NAT64
19
CiscoPress. 2013
20
CiscoPress. 2013

Etape 1 : il faut tout d’abord configurer sur le routeur un le lien entre l’adresse IPv4 et IPv6 qu’on
appelle « Static MapPing ». Ici on fait le lien entre l’adresse 2001:DB8:FEED:1::E et 172.16.1.10
Etape 2 : le PC fait une requête au serveur DNS pour résoudre l’adresse www.exemple-v6.com
Etape 3 : le serveur DNS lui retourne l’adresse IPv4 172.16.1.10
Etape 4 : la machine A peut maintenant envoyer son paquet avec l’adresse source 192.0.2.10 et son
adresse de destination 172.16.1.10
Etape 5 : le paquet est reçu par le routeur qui constate qu’une « Static MapPing » est configurée pour
l’adresse 172.16.1.10. Il va donc effectuer les étapes suivantes :
• Traduire l’entête IPv4 en IPv6

• Changer l’adresse IP destination en 2001:DB8:FEED:1::E
• Changer l’adresse IP source en IPv6 avec la technique de NAT64 stateful ou stateless (dans ce
cas on utilise du stateful). L’adresse sera 2001:DB8:CAFE:AAAA::C000:020A (C000:020A est en
hexadécimal l’équivalent de l’adresse source IPv4 192.0.2.10)
Etape 6 : le paquet est routé en utilisant le processus standard de routage IPv6. Il arrive donc
directement sur le serveur 2001:DB8:FEED:1::E
Etape7 : le serveur répond et renvoie en retour en croisant l’adresse IP source et destination
Etape 8 : le routeur effectue cette fois la transition de l’adresse IPv6 en IPv4 selon les étapes suivantes :
• Traduire l’entête IPv6 en IPv4

• Changer l’adresse IP source via NAT64, ce qui donne 172.16.1.10
• Changer l’adresse IP destination en IPv4.
Etape 9 : pour terminer le paquet est routé sur la base IPv4 vers le machine A.
Cela permet donc à une machine configurée en IPv4 d’accéder à des services configurés en IPv6 de
manière transparente pour l’utilisateur. Il y a également la possibilité de faire la translation d’adresse
d’IPv6 vers IPv4, cela nécessite un serveur DNS64.
2.7.5. Autres possibilités
Il y a également ces différentes méthodes de transitions qu’on peut citer, mais que je ne vais pas
développer dans ce document, on peut retrouver plus d’infos dans les RFC :
• ISATAP : RFC 5214

• GRE : RFC 2784
• Teredo : RFC 4380

3.Cahier des charges

3.1. Problématique
L’entreprise arrive à saturation ou en conflit avec la demande d’adresse IPv4 pour ses clients, d’où la
nécessité d’une migration vers la version IPv6. Etant donné que l’entreprise possède une architecture
réseau complexe fournissant de nombreux services, un plan de migration adapté est nécessaire.
Le projet a pour but d’évaluer la charge de travail ainsi que les risques et les différentes solutions à
implémenter pour la migration d’une infrastructure Cloud IPv4 vers IPv6 au sein d’une société de
services informatiques.
3.2. Objectifs
Il est nécessaire d’évaluer les services de base afin de s’assurer qu’ils soient bien compatibles en Dual-
Stack. Il est également important de faire en sorte que la partie NAT64 puisse être configurée sur les
firewalls. Pour cela nous allons donc établir un POC « Proof of Concept » qui regroupe ces différents
services, les équipements qui constituent le POC sont le plus semblable possible à ceux qui sont
actuellement en production afin de procéder ensuite à une intégration simplifiée de la solution. Il est
important de préciser que l’intégration dans le réseau de production ne fait pas partie du travail de
diplôme.
Dans le POC nous aurons donc :
• Routeur (ASR1001)
• IPAM (plateforme Infoblox)
• DNS (plateforme Infoblox)
• DHCP (plateforme Infoblox)
• Firewall (Palo-alto et Fortinet)
• Reverse-Proxy (linux)
Un point important qu’on peut relever est que, pour la partie DNS (interne et public) ainsi que pour
l’IPAM, nous avons opté pour la plateforme Infoblox qui n’est actuellement pas utilisée dans notre
environnement. C’est une version d’évaluation étendue qui nous est mise à disposition par l’un de nos
fournisseurs. L’IPAM permet principalement la gestion des adresses IPv4 et IPv6. Il sera également
possible d’utiliser du DNSsec qui permet de résoudre certains problèmes de sécurité liés au protocole
DNS.
Ce travail a donc également comme objectif de mettre en place, configurer et évaluer cette plateforme
Infoblox. Pour cela je vais pouvoir compter sur le support de notre fournisseur qui va m’apporter de
l’aide pour la mise en place de l’équipement et me fournira une rapide formation. Par la suite c’est moi
qui m’occuperai de sa configuration.

Nous n’avons pas la possibilité d’intégrer nos switch layer 3 dans le POC. Il faudra donc évaluer ces
équipements en fonction de leur modèle et version, afin de s’assurer de leur compatibilité. Dans notre
POC, nos deux firewalls nous permettrons de faire du routage interne.
Nos deux firewalls actuellement en production offrent des possibilités de configuration par rapport à
leurs versions de logiciel embarqué et non par rapport au modèle. En effet, avec le firewall Fortigate
et Palo Alto nous avons le même niveau de fonctionnalité d’un modèle à l’autre. Il faudra cependant
veiller à avoir la même version de logiciel sur les firewalls que nous allons utiliser dans notre POC et
également le même type de licence. Les deux firewalls nous parviendront dans le courant du mois de
juin.
Il faut aussi relever que bien qu’ils ne seront pas utilisés dans notre POC, nos deux serveurs DNS public
doivent être migrés avant de mettre en place IPv6 en production dans l’infrastructure Cisel. En effet,
ils sont actuellement en Windows Serveur 2008 et ne supportent pas les entrées AAAA qui
correspondent aux adresses IPv6. Je ne m’occuperai pas de la migration, mais de l’effectuation de la
demande en interne afin qu’une autre ressource de Cisel informatique puisse s’en occuper.
La mise en place de notre réseau de test « POC » me permettra d’acquérir les compétences afin
d’établir une documentation complète dans le but d’un déploiement futur de la solution. Il me
permettra également d’évaluer la compatibilité des équipements. Le réseau de test pourra également
être par la suite utilisé pour valider la compatibilité d’un service Cloud en mode Dual-Stack avant de
procéder à sa configuration en production.
4.Analyse
4.1. Résumé de la situation
Cisel souhaite intégrer IPv6 pour les services Cloud qu’elle fournit à ses clients. Comme le but du projet
est de migrer vers IPv6 pour les services Cloud, nous allons uniquement nous concentrer sur les
équipements et services utilisés par l’infrastructure Cloud. Voici donc les différents services de base à
prendre en compte :
• Routeur (ASR1001)
• Switch layer 3(Cisco 3750-X et Nexus 5548)
• IPAM (pas encore disponible, à évaluer dans le POC)
• DNS (Windows Serveur)
• DHCP (Windows Serveur)
• Firewall (Palo-Alto et Fortinet)
• Reverse-Proxy (linux)
• Service Cloud
Tous ces services sont actuellement configurés en IPv4 exclusivement. Il faut donc que les équipements
soient compatibles IPv4 et IPv6 afin d’avoir une configuration Dual-Stack. Les switch layer 2 ne seront
pas évalués, car ils ne traitent que la couche 2 (adresse physique) et non la couche 3 avec l’adresse IP.
Il n’y a donc pas d’influence pour ces équipements.

4.2. Concept de migration des services Cloud

4.2.1. Concept réseau
Vu la complexité de l’infrastructure réseau en place chez Cisel informatique, il est important de

planifier cette migration par étape. Le concept consiste donc à mettre en place un réseau
complètement coupé du réseau de production. Il ne doit en aucun cas pouvoir communiquer avec le
réseau de production. Pour cela j’ai également demandé un nom de domaine « cisel-lab.ch » de test
afin de ne pas prendre le moindre risque. Voici un schéma simplifié :
Figure 4-1 | schéma production et réseau de test (POC)

Notre nom de domaine cisel-lab.ch aura comme DNS public notre DNS Infoblox qui se trouvera dans
notre réseau de test.
Nous aurons donc la possibilité d’effectuer les tests nécessaires, afin de valider que nos deux firewalls
ainsi que notre routeur ASR1001 sont compatibles avec IPv6 et nous permettent de faire les
configurations nécessaires, afin de les rendre disponibles aux services-Cloud en IPv6. Il faudra
confirmer que ces services sont accessibles depuis internet, mais également depuis l’interne.
La priorité est de tester, dans un premier temps, l’accès depuis l’externe. Afin de pouvoir simuler la
connexion depuis une machine distante connectée à internet, nous utiliserons pour cela une seconde
ligne internet. Afin d’avoir une adresse IPv6 Global sur notre poste de test, nous effectuerons un tunnel
avec le service « Hurricane Electric Free IPv6 Tunnel Broker ».
Par la suite, il sera possible de tester la disponibilité des ressources Cloud depuis l’interne. Nous allons
utiliser le DHCP de l’Infoblox pour distribuer une adresse IPv4 et IPv6 sur un poste de travail qui se
trouvera dans une zone interne, c’est-à-dire derrière le firewall interne (comme c’est le cas pour la
production).
Voici donc un schéma de notre réseau de tests :
INT_CISEL
IPv6 Tunnel Broker
Poste test interne INTERNET
Firewall Interne Fortigate Firewall Externe Palo Alto Poste test externe
Routeur ASR1001
OUT_DNS_PUB
Palteforme Infoblox
IN_DNS_IPAM_DHCP_PRIV
Figure 4-2 | schéma réseau de test (POC)
4.2.2. Concept service Cloud
Voici la liste des services Cloud que nous proposons à nos clients :
• Exchange as a Service
• Lync as a Service
• Téléphonie VOIP as a Service
• File and Backup as a Service
• Desktop as a Service
• SAP B1 as a Service
• Interface console de gestion

Nous n’allons pas intégrer tous ces services Cloud dans notre POC, cela serait un travail trop
conséquent. Nous allons donc prendre nos deux services principaux qui sont « Exchange as a service »
et « File as a Service ». Il est important de valider que la couche application est compatible avec IPv6.
Voici actuellement le schéma qui représente l’ensemble des services Cloud que nous proposons à nos
clients :
DMZ EXTERNES
INT_GW_RDP (DMZ Comm Externe)
FireWall
INT_DEMO_SAPB1 (DMZ Externe BONE)

Cloud On Demand
RDP B1
SRVRDPSGW001 SRVB1WAS001 SRV Reverse Proxy

• 172.21.61.37 • 172.21.61.39 • Appache Postes Clients
• Serveur Gateway RDP • Ericom Secure Gateway
• Cloud B1
SRVB1ODRDPS001 SRVB1ODRDPS011 SRVB1RSP001 SRVB1DEMO001 SRVB1DEMO003 SRVB1DEMO011 SRVRDPXXX

• 17 2.21.51.176 •
• 172.21.51.174 • 172.21.51.181 172.21.51.17 8 • 172.21.51.180 • 17 2.21.51.182 • RDPS Client B1 HA NA
• Remote Support Plateform
• RDPS Serveur OnDeman d Prod • RDP Serveur OnDemand Test
• WebDav OUT_CLOUD_PUB
• cloudb1
• Rsp.cisel4you.ch
INT_DEMOPUB_SAP Infrastructure commune domaine cisel4you.lan

SRVCISSYNC001
Internet
•
FW Externe
172.21.71.31/32
• CISSYNC SRVMED001 SRVMED002
Lync
federation
SRVB1ODCCC001 SRVB1ODCCC011 SRVPERSAL001 SRVDEMOEC001

• 172.21.51.212 • 172.21.51.233 • 17 2.21.51.231 • 172.21.51.20 4 SRVMAIL001
• Cloud Control Center Prod • Cloud Control Center Test • Demo Persal • Demo High Tech Stack Abap • 172.21.51.206
• BD Template inst clients • HT1 • Serveur Messagerie
SRVMX002 SRVMX001 SRVLB001B SRVLB001A

• 172.xx • 172.xx • 172.xx • 172.xx XMPP
• EDGE Ex change • EDGE Ex ch ange • Reverse PRox y • Reverse PRoxy SRVEDGE002 SRVEDGE001 federation
• Apache • Apache • 172.xx • 172.xx
• EDGE LYNC • EDGE LYNC
SRVB1ODDB001 SRVB1ODDB011 SRVDEMOEC009 SRVDEMOEC008

• 172.21.51.211
• 172.21.51.235 • 172.21.51.23 0 • 172.21.51.22 7 SRVDEMODC002 SRVDEMODC001
• Cloud DB SQL Prod • 172.21.51.200 Skype
• Cloud DB SQL Test • Demo IMC • Demo Watch & Jaw elllery • 172.21.51.20 9 • Serveur Ac tive Direc tory
• IM1 • WJ2 • Serveur Active Directory federation
SRVVSS001A SRVVSS001B
• 172.21.54.4 • 172.21.54.4
• •
Serveur connection serveu rServeur connection serveur
SRVRPROXY001 SRVRPROXY002
• 172.xx • 172.xx
• Reverse PRox y • Reverse PRoxy
OUT_CLOUD_PRIV • Apache • Apache
Firewall Interne
FireWall
INT_CLOUD_RDP
SRV 1 RDP SRV 2 RDP SRV 3 RDP
SRVLB002B SRVLB002A
SRVDC01 SRVDC02 SRVCAIS001 SRVVCS001A SRVVCS001B
... SRVCP001
• Serveur Cloud Panel
•
•
172.21.54.3
Serveur Activ e Directory
•
•
172.21.54.4
Serveur Activ e Directory
•
•
172.21.54.5
Serveur de certif icats
•
•
172.21.54.4
Serveur connection serveur
•
•
172.21.54.4
Serveur con nection serveur
•
•
172.xx
Reverse PRoxy
•
•
172.xx
Reverse PRox y
• A pache • Apache
Les serveurs sont isolés les un des autres

avec VMWare NSX (option futur)
SRVUM001 SRVDB001A SRVPC001

(172.20.xxx.13) SRVFE001
SRVEX001A SRVDB001B (172.20.xxx.14) SRVFE002 SRVMED001
SRVEX001B (172.20.xxx.13) SRVWA001
SRVFE003 SRVMED002
SQL cluster SRVWA002
MBX+CAS (172.20.xxx.13)
Exchange + DFS (172.20.xxx.15)
SRV 1 DB SRV 2 DB SRV 3 DB
...
Les serveurs sont isolés les un des autres

avec VMWare NSX (option futur)
Figure 4-3 | schéma services Cloud production
Dans notre réseau de test nous aurons une zone qui contient les services Cloud configurés en Dual-
Stack. Pour la mise en place d’IPv6 sur la suite de production, il sera possible d’avoir une zone réservée
au service Cloud configuré en IPv4 et une seconde zone contenant uniquement des services Cloud
Dual-Stack. Cela permet, au niveau opérationnel, de distinguer facilement les services disponibles en
Dual-Stack et également de déplacer le serveur d’une DMZ à une autre, une fois la couche application
testée avec IPv6.
Comme c’est le cas en production, un « reverse Proxy» basé sur un OS linux sera utilisé pour terminer
le flux TCP via le port 443 (HTTPS). C’est le « reverse Proxy » qui fait le routage vers le service Cloud et
termine la connexion TCP. Son rôle est de couper le flux qui vient depuis l’externe et d’ouvrir un flux
de la DMZ externe vers l’interne.
Je vais également monter un serveur VMware ESX qui hébergera le « reverse Proxy », le « serveur
exchange » et le « serveur CISsync », afin de se retrouver dans la même configuration que sur le réseau
de production. En effet, tous nos services Cloud sont hébergés sur nos serveurs ESX internes.

Voici le schéma de test complété avec nos deux services Cloud ainsi que notre Proxy linux :
Figure 4-4 | schéma réseau de test avec services Cloud
4.2.3. Conclusion Concept
Notre POC respecte ainsi la configuration que nous avons en production. On retrouve les deux niveaux
de firewall et aussi les services Cloud hébergés sur les ESX. Le POC nous permettra également de nous
familiariser avec les règles firewall à créer pour IPv6 ainsi que le routage. Il pourra par la suite être
utilisé pour valider que la couche application d’un service Cloud est bien compatible avec IPv6.

4.3. Plan d’adressage IPv6

Les Adresses IP sont distribuées par l’IANA à cinq organismes régionaux (RIR) qui sont en charge de
redistribuer ces adresses aux différentes régions du monde :
21
Figure 4-5 | les cinq organismes régionaux (RIR)
Chacun de ces organismes, RIPE pour l’Europe, distribue des adresses à ses LIR (Local Internet
Registries). Les LIR sont en général des fournisseurs d’accès à internet (ISP), comme Swisscom par
exemple mais peut également être une entreprise ou association.
Voici un schéma pour comprendre le découpage des adresses en fonction des différents organismes :
Figure 4-6 | Découpage des adresses IPv6
21
Source : https://www.apnic.net/about-APNIC/organization/history-of-apnic/history-of-the-regional-internet-
registries

On peut voir que les RIR comme RIPE pour l’Europe, reçoivent en général un bloc d’adresses en /23.
Les fournisseurs d’accès à internet (ISP) qui sont, comme décrit juste avant, des LIR, reçoivent un bloc
d’adresses de /32. Pour finir les LIR distribuent un bloc d’adresse aux entreprises en /48.
Il est important de signaler que s’il s’agit du minimum d’allocation, par exemple une entreprise qui
justifie un /37 pourrait bien se voir attribuer ce bloc d’adresse.
Nous avons effectué une demande pour un Bloc d’adresse en /48 (recommandation de l’ISEG et IAB
RFC3177). Le bloc d’adresse sera « provider-independant (PI) », ce qui permettra de changer de
provider sans devoir changer de bloc d’adresse IP.
Les 48 premiers bits seront utilisés pour être routés sur interne, comme la partie réseau de IPv6
concerne les 64 premier bits, il nous reste 16 bits pour faire nos sous-réseaux, ce qui nous fait 65535
sous-réseaux qui peuvent contenir chacun un nombre de 8 quintillions d’adresses. Ce qui est largement
suffisant.
Dans un premier temps nous avions pensé demander un bloc d’adresse en /37, afin de pouvoir
proposer nous-même différents bloc /48 à nos clients. Malheureusement, il n’est pas possible de le
faire avec un bloc d’adresse PI (provider-independant). En effet, RIPE refuse de le faire pour éviter de
fragmenter le réseau et de remplir les tables de routages internet.
La seule possibilité aurait été de devenir un membre de RIPE. Les coûts sont de 2000 euros pour la
mise en service et de 1400 euros pour se positionner en tant que LIR (+50 par assignement de PI) par
année.
Dans le cas où il serait possible de bénéficier d’un bloc d’adresse IP en /37, nous pourrions établir 2048
sous-réseaux routables sur internet (2^11). Imaginons que nous recevions le bloc d’adresse suivant :
2001:BEEF::0/37
Nous aurions donc la possibilité d’avoir les plages d’adresses routables sur internet suivantes :
2001:BEEF::/48 – 2001 :BEEF :3e8::/48
Nous aurions par exemple pour Cisel le réseau suivant :
2001:BEEF:1::/48 pour Cisel
Et ce réseau pour un de nos clients :
2001:BEEF:2::/48

4.3.1. Concept d’adressage
Ripe met à disposition un fichier pdf22 qui permet de donner des « best practices » sur le concept
d’adressage IPv6. Suite à la lecture de ce document j’ai pu établir le concept suivant :
Nous avons à disposition un bloc d’adresse IPv6 avec un préfixe /48. Ce qui nous laisse 16 bits pour
faire nos sous-réseaux. Il faut donc répartir ces 16 bits de manière réfléchie, afin d’avoir une logique
d’adressage qui permet de localiser ou d’identifier un équipement rapidement. Nous avons la
possibilité de définir trois groupes :
Le type d’équipement (T), on peut réserver un digit pour le type d’équipement, voici une liste de type
d’équipement possible :
• Backbone et autres infrastructures

• Serveur
• Management
• Poste de travail
• Guest
• VPN
La localisation de l’équipement (L) qui représente les différents bâtiments
Le numéro de VLAN où se trouve l’équipement (V)
Voici donc les 16 bits disponibles pour établir le sous-réseau :
D D D D D D D D D D D D D D D D
1ère possibilité :
Intégrer le type et numéro de VLAN en décimal
T T T T V V V V V V V V V V V V
Ce qui nous donnerait par exemple le sous réseau suivant :
2001:DEAD:BEEF:1100::/64
1 correspondrait par exemple au type backbone, on retrouve également le VLAN 100. L’avantage est
qu’on obtient facilement notre sous-réseau en connaissant le VLAN et le type d’équipement. Connaître
le type peut être intéressant d’un point de vue opérationnel. Par contre, le désavantage est qu’on ne
peut pas avoir des vlan plus grands que 999 si on veut pouvoir les entrer en décimal dans l’adresse
hexadécimale.
22
Source : https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-
Addressing-Plan.pdf

2ème possibilité :
Intégrer la location et le type
L L L L T T T T D D D D D D D D
Ce qui nous donnerait par exemple le sous réseau suivant :
2001:DEAD:1101:/64
1 correspondrait au premier bâtiment de l’entreprise, 1 correspondrait par exemple au type backbone.

Avec les derniers 8 bits on peut faire 28 sous-réseaux pour chaque location et type. L’avantage est
qu’on peut facilement identifier une adresse géographiquement. Cependant, il peut y avoir des choix
ambigus, si par exemple on veut créer un sous-réseau entre deux routeurs qui se trouvent dans deux
locations différentes, on ne pourra pas respecter cette logique. On peut également citer comme
désavantage que l’on doit à chaque fois encore découper notre sous-réseau.
La première possibilité reste la plus intéressante. Nous avons déjà une logique de vlan qui correspond
à définir des numéros de VLAN entre 301 et 550 pour les zones internes et entre 551 et 700 pour les
zones externes. Nous allons donc utiliser ce concept d’adressage dans notre POC.
Voici le plan d’adressage IPv4 pour notre réseau de test :
INT_CLOUD_CISEL 172.20.70.16/28
INT_CISEL 172.20.70.32/28
OUT_DNS_PUB 172.20.70.48/28
INT_DNS_IPAM_DHCP_PRIV 172.20.70.64/28
OUT_CLOUD_PUB 172.20.70.80/28
OUT_CLOUD_PRIV 172.20.70.96/28
MANAGEMENT 172.20.70.0/28 VLAN 420
OUTSIDE FORTIGATE / INSIDE PALO ALTO 172.20.70.112/28
172.20.70.113 OUTSIDE FORTIGATE
172.20.70.114 INSIDE PALO ALTO
OUTSIDE PALO ALTO 195.141.249.249
Tableau 4-1 | plan d'adressage IPv4
Les cinq adresses IPv4 public suivantes ont été réservées :
• 195.141.249.249 (Firewall Externe Palo Alto)

• 195.141.249.224 (Reverse Proxy Exchange)
• 195.141.249.159, 195.141.249.231 (Cissync, syncfile)
• 195.141.249.198 (DNS public)
Plan d’adressage IPv6
Nous n’avons pas encore reçu notre bloc d’adresse IPv6, mais j’ai fait le nécessaire pour que le bloc
soit à notre disposition dans le courant du mois de juin. Dans notre plan d’adressage nous allons donc
prendre le bloc d’adresse 2001:DEAD:BEEF::/64. Ainsi je peux déjà concevoir mon plan d’adressage et
remplacer les trois premiers hextet une fois que nous aurons le bloc à disposition. Voici donc le plan
d’adressage IPv6 :

INT_CLOUD_CISEL 2001:678:204:2390::/64 (VLAN 390) (2 = serveurs)

INT_CISEL 2001:678:204:4400::/64 (VLAN 400) (4 = poste de travail)
OUT_DNS_PUB 2001:678:204:2670::/64 (VLAN 670)
INT_DNS_IPAM_DHCP_PRIV 2001:678:204:2410::/64 (VLAN 410)
OUT_CLOUD_PUB 2001:678:204:2680::/64 (VLAN 680)
OUT_CLOUD_PRIV 2001:678:204:2690::/64 (VLAN 690)
OUTSIDE FORTIGATE / INSIDE 2001:678:204:1430::/64
PALO ALTO 2001:678:204:1430::1 OUTSIDE FORTIGATE
2001:678:204:1430::2 INSIDE PALO ALTO
OUTSIDE PALO ALTO 2001:678:204:1001::2/64
Tableau 4-2 | plan d'adressage IPv6
4.4. Stratégie de tests

Afin d’effectuer nos tests pour valider le bon fonctionnement des services Cloud, nous avons à
disposition une deuxième liaison internet qui nous permettra de simuler la partie client. Il faut préciser
que le but du service Cloud est d’être disponible depuis n’importe où sur internet, il est en général
accessible depuis un navigateur internet ou un client et ne nécessite pas de connexion VPN.
Nous pourrons donc tester l’accès à notre service Cloud depuis notre deuxième ligne internet. Il sera
possible de tester l’accès depuis une configuration IPv4 et une configuration Dual-Stack en établissant
un tunnel IPv6 vers « Hurricane Tunnel Broker ».
Voici donc les différents cas de figure que nous pourrons tester :
• Une machine distante configurée en IPv4 veut utiliser une ressource Cloud IPv6 (méthode
NAT64 configuré sur Firewall)
• Une machine distante configurée en Dual-Stack (via Hurrican Tunnel Broker) veut se connecter
sur une ressource Cloud Cisel configurée en IPv6.
Nous pourrons également valider la distribution d’une adresse IPv6 et IPv4 via le DHCP de la
plateforme Infoblox sur un poste en interne afin de confirmer l’utilisation du service Cloud depuis
l’interne.
5.Analyse de risque
Afin d’assurer la réussite du projet en général et de mener à bien la configuration du réseau de test, il
est important d’évaluer les risques afin de préparer une solution en cas de problème. Voici donc la liste
des problèmes potentiels :
Problème 1 : Retard dans la livraison des équipements du réseau de test
Solution : relancer le fournisseur afin de nous livrer les équipements dans les plus brefs délais.

Problème 2 : Retard dans la mise en place du block IPv6 sur notre ligne internet Sunrise.
Solution : relancer Sunrise afin de leur demander de traiter cette demande au plus vite
Problème 3 : panne d’un équipement du réseau de test
Solution : faire régulièrement des backups de configuration
Problème 4 : Incompatibilité d’un des services Cloud avec le monde de fonctionnement Dual-Stack
Solution : Le réseau de test a justement comme but de vérifier la compatibilité des services Cloud. Il
faudra donc en tenir compte pour le futur déploiement en production et vérifier auprès du support s’il
y a une solution prévue.
Problème 5 : Incompatibilité du Reverse Proxy linux avec le monde de fonctionnement Dual-Stack
Solution : Chercher une version linux compatible avec le monde de fonctionnement Dual-Stack
Problème 6 : Perturbation sur le réseau de production due à une configuration sur notre réseau de
test
Solution : Déconnecter immédiatement les équipements et chercher la source du problème

6.Réalisation de la maquette
Nous pouvons donc commencer la mise en place de notre réseau de simulation. Il permettra de
confirmer la compatibilité de nos différents services de base ainsi que nos deux principaux services
cloud. Il pourra par la suite être utilisé pour tester d’autres services Cloud avant leur configuration en
IPv6. En effet ce réseau de simulation a pour principal but de valider le concept établi lors de la pré-
étude afin de pouvoir par la suite le mettre en pratique dans le réseau de production de CISEL. Je vais
détailler avec précision les différentes configurations que je vais effectuer afin d’avoir une
documentation complète pour faciliter le travail des personnes qui s’occuperont des configurations
sur le réseau de production. Voici donc le schéma mis à jour avec les adresses IP et les NAT :
Figure 6-1 | Schéma complet
6.1. Configuration du routeur ASR1001

Voilà précisément la configuration que nous devons obtenir afin de pouvoir configurer l’interface WAN
du firewall PALO ALTO avec les adresses IP 195.141.249.249 et 2001:678:204:1001:2/64 et ainsi avoir
une configuration Dual-Stack :

Figure 6-2 | Schéma BGP
La configuration des interfaces ainsi que le routage BGP en IPv4 est déjà effectuée car il s’agit de notre
routeur de production. Il faut donc effectuer les modifications très prudemment. En cas de problème
nous avons un outil qui permet de revenir à une configuration précédente sur notre routeur.
6.1.1. Configuration du routage BGP
Voici les différentes lignes de commande pour effectuer la configuration :
r-matran-198-7-ASR1001#conf t
r-matran-198-7-ASR10(config)#ipv6 prefix-list sunrise-out_v6 seq 5 permit 2001:678:204::/48
r-matran-198-7-ASR10(config)#ipv6 unicast-routing
r-matran-198-7-ASR10(config)#router bgp 200173
r-matran-198-7-ASR10(config-router)#no bgp default ipv4-unicast
r-matran-198-7-ASR10(config-router)#neighbor 2001:678:204::3 remote-as 200173
r-matran-198-7-ASR10(config-router)#neighbor 2001:1700:2200:6::1 remote-as 6730
r-matran-198-7-ASR10(config-router)#neighbor 2001:1700:2200:6::1 description Connexion vers
Sunrise (IPV6)
r-matran-198-7-ASR10(config-router)#neighbor 2001:1700:2200:6::1 password 7 XXXXXX
r-matran-198-7-ASR10(config-router)#address-family ipv6
r-matran-198-7-ASR10(config-router-af)#network 2001:678:204::/48
r-matran-198-7-ASR10(config-router-af)#neighbor 2001:1700:2200:6::1 activate
r-matran-198-7-ASR10(config-router-af)# neighbor 2001:1700:2200:6::1 prefix-list sunrise-out_v6 out
r-matran-198-7-ASR10(config-router-af)#end
r-matran-198-7-ASR1001#wr
6.1.2. Configuration de l’interface 0/0/0
Il s’agit de l’interface connectée à Sunrise, il faut donc activer IPv6 sur cette interface et lui fixer
l’adresse IP fournit pas Sunrise :

r-matran-198-7-ASR10(config)#interface giga 0/0/0

r-matran-198-7-ASR10(config-if)#ipv6 enable
r-matran-198-7-ASR10(config-if)# ipv6 address 2001:1700:2200:6::2/124
r-matran-198-7-ASR10(config-if)#end
6.1.3. Configuration de l’interface 0/0/1
Il faut maintenant configurer l’interface qui sera connectée sur notre PALO ALTO. On va également
ajouter une route static pour que les paquets arrivent sur notre firewall.
r-matran-198-7-ASR10(config)# ipv6 route 2001:678:204::/48 2001:678:204:1001::2
r-matran-198-7-ASR10(config)#interface giga 0/0/1
r-matran-198-7-ASR10(config-if)#ipv6 enable
r-matran-198-7-ASR10(config-if)# ipv6 address 2001:678:204:1001::1/64
r-matran-198-7-ASR10(config-if)#end
6.1.4. Contrôle de la configuration
Avec la commande suivante on peut vérifier que les adresses IPv6 soient correctement configurées
Figure 6-3 | vérification adresses IPv6 routeur ASR1001
On peut faire un Ping sur le DNS Google pour valider la configuration en IPv6 :
Figure 6-4 | Test Ping IPv6 routeur ASR1001
On peut également s’assurer que la route static a bien été ajoutée :

Figure 6-5 | Vérification route static routeur ASR1001
6.1.5. Connexion entre le routeur et firewall
Comme notre routeur est connecté sur un switch Cisco 3560, nous pouvons utiliser un port de ce
switch afin de connecter le routeur et le firewall, les deux ports devant être sur le même vlan. J’ai donc
configuré notre switch c-matr-21.198.5-3560 :
c-matr-21.198.5-3560#conf t
c-matr-21.198.5-3560(config)#interface gigabitEthernet 0/2
c-matr-21.198.5-3560(config-if)#no shutdown
c-matr-21.198.5-3560(config-if)#switchport mode access
c-matr-21.198.5-3560(config-if)#switchport access vlan 696
c-matr-21.198.5-3560(config-if)#description *** PALO 200 LAB IPV6 CAN eth4 ***
c-matr-21.198.5-3560(config-if)#end
c-matr-21.198.5-3560#wr
Avec la commande suivante on peut afficher les interfaces et leur description, on retrouve donc
l’interface connectée sur notre firewall et l’interface connectée sur le routeur :
Figure 6-6 | Vérification interfaces routeur ASR1001
On peut donc vérifier que l’interface Gi0/2 et Gi/27 soit dans le même vlan
Figure 6-7 | Vérification VLAN routeur ASR1001

6.2. Configuration du firewall Externe en Dual-Stack

Comme indiqué lors de la pré-étude, nous allons utiliser comme firewall externe un PALO ALTO pour
respecter l’architecture réseau que nous avons en production.
PA-200
1 2 3 4 MGT USB CONSOLE
POWER STATUS
FAN HA
ALARM TEMP
Figure 6-8 | Firewall PAL ALTO
6.2.1. Configuration de base
J’ai procédé au reset de firewall avant de le configurer. Par défaut l’interface de MGT est configurée
avec l’adresse IP 192.168.1.1. Il faut donc configurer par exemple l’adresse 192.168.1.2 sur le poste
depuis lequel on veut se connecter au PALO ALTO et ensuite on peut se connecter via l’adresse
https://192.168.1.1. Le user et mot de passe par défaut sont admin/admin.
6.2.2. Création des zones
Nous pouvons maintenant créer les zones sur notre firewall :
Figure 6-9 | PALO ALTO création des zones
La zone outside sera utilisée pour le réseau d’interconnexion entre le PALO ALTO et le routeur, inside
avec le firewall interne Fortigate. Enfin, il y a trois zones pour les DMZ externes :

Figure 6-10 | PALO ALTO zones
6.2.3. Configuration des interfaces outside et inside
Nous pouvons maintenant passer à la configuration des interfaces physiques. Afin de pouvoir faire un
Ping ou se connecter sur une interface pour l’administration du firewall, il est nécessaire de créer des
profils de management que nous allons par la suite appliquer aux interfaces. Voici comment créer des
profils de management :
Pour autoriser les Ping :
Figure 6-11 | PALO ALTO profile management ping
Pour autoriser le management du firewall :
Figure 6-12 | PALO ALTO profile management accès
Par la suite nous procèderons à la configuration des interfaces (une interface par zone). Dans un
premier temps nous allons configurer l’interface Ethernet1/1 qui sera l’interface inside, elle sera
directement connectée sur l’interface outside du Fortigate. On peut constater qu’on sélectionne le
« default virtual Router » : il serait possible d’en créer plusieurs mais ça ne sera pas utile dans notre
cas.

Figure 6-13 | PALO ALTO configuration inside
Configuration de l’adresse IPv4 :
Figure 6-14 | PALO ALTO configuration inside IPv4
Pour la configuration de l’adresse IPv6 nous n’activons pas les messages RA ni la détection de
duplication d’adresse. En effet nous n’allons pas utiliser de DHCP sur les zones externes ni la
configuration SLAAC. Nous allons fixer les adresses IPv6 sur les serveurs manuellement.
Figure 6-15 | PALO ALTO configuration inside IPv6
On va également sélectionner le profil, ici on choisit allow-MGMT car on veut pouvoir se connecter
depuis le réseau interne qui se trouvera sur le Fortigate.
Figure 6-16 | PALO ALTO configuration inside profil

Même principe pour la configuration de l’interface ehternet1/4 qui est connectée sur le routeur via le
switch 3560. Pour l’adresse IPv4 on lui fixe l’adresse public 195.141.249.249, le routeur, lui, possède
l’adresse IP 195.141.249.27 comme on l’a déjà vu dans le précédent schéma.
Figure 6-17 | PALO ALTO configuration outside IPv4
On configure également l’adresse IPv6 :
Figure 6-18 | PALO ALTO configuration outside IPv6
On ajouter également le profil qui permet le « Ping » sur l’interface :
Figure 6-19 | PALO ALTO configuration outside profil
6.2.4. Configuration des interfaces pour les DMZ
Comme c’est le cas en production sur notre PALO ALTO, nous allons créer trois sous-interfaces pour
nos DMZ. Ces sous interfaces se trouveront toutes sur le même port physique qui sera connecté sur
notre switch SW01. Il faudra donc configurer le port du switch en mode trunk et accepter ces trois
vlan. Nos Serveurs sont installés sur l’ESX qui est directement connecté à un switch, nous pourrons
ainsi connecter le switch ESX à notre switch pour transmettre le flux au PALO ALTO. Ceci permet
également de n’utiliser qu’un seul port physique sur le PALO ALTO.
Pour créer les sous-interfaces, aller dans « Network », « Intefaces », sélectionner l’interface
ethernet1/2 et cliquer sur « Add Subinterface », ensuite la configuration s’effectue comme une
interface physique à l’exception du TAG qu’il faut renseigner, il s’agit du numéro VLAN :

Figure 6-20 | PALO ALTO création sous-interface
Voilà donc le résultat après la création de nos trois DMZ :
Figure 6-21 | PALO ALTO DMZ
6.2.5. Création des objets
Il faut maintenant créer nos objets, pour pouvoir créer nos règles. Pour cela j’ai mis en place une
nomenclature à respecter afin de faciliter la lecture des règles. Cette nomenclature ne se base pas sur
ce qui est en place sur le réseau de production. Elle pourrait éventuellement être mise en place par la
suite.
Type d’objet Structure Exemple

Adresse Zone.typeIP.nom.type ext.v4.dnspub.net
Règle Source_2_destination DNS_2_outside
Tableau 6-1| nomenclature
On peut donc maintenant créer les objets correspondant comme par exemple ext.v4.dnspub.net :
Figure 6-22 | PALO ALTO création objet
6.2.6. Création des règles
Dans un premier temps nous allons ouvrir tout le flux depuis et vers toutes les zones afin de ne pas
perdre de temps pour la mise en place de nos services. Par la suite nous allons restreindre au strict
nécessaire. On peut donc voir ci-dessous qu’on autorise le flux depuis toutes nos zones vers toutes les

zones. Attention nous ne mettons pas la zone Outside dans les zones source, sinon cela voudrait dire
que tout le monde pourrait se connecter depuis l’externe. De plus, nous spécifions tout de même en
IP source nos blocs d’adresse IPv4 et IPv6, soit 172.20.70.0/24 et 2001:678:204:/64
Figure 6-23 | PALO ALTO règle de base
Il faut également créer une règle de NAT afin de pouvoir accéder à internet. Pour l’instant nous allons
limiter cette règle de NAT à notre zone cisel-lab. C’est la plage qui sera attribuée au PC de test connecté
sur le Fortigate.
Figure 6-24 | PALO ALTO règle de NAT
6.2.7. Configuration du routage static
Tout d’abord nous allons configurer la route pour notre réseau IPv4. Elle sera utilisée si le routeur ne
connait pas le réseau de destination. Il va donc transmettre au « Next Hop » qui est, dans notre cas, le
routeur ASR1001. Voici donc la configuration de la route par défaut:
Figure 6-25 | PALO ALTO routage static IPv4 default
Il faut ensuite créer une route pour les zones internes qui se trouvent sur le Fortigate. On indique tout
le bloc 172.20.70.0/24. De cette manière, s’il ne s’agit pas d’un sous-réseau connecté directement sur

le PALO ALTO, mais qui fait partie du bloc 172.20.70.0/24. Dans ce cas le firewall va envoyer le paquet
sur le « NEXT HOP » 172.20.70.113 qui est l’adresse outside du Fortigate :
Figure 6-26 | PALO ALTO routage static IPv4 bloc interne
On effectue la même configuration pour IPv6, créer la route par défaut avec le « Next Hop » l’adresse
du routeur :
Figure 6-27 | PALO ALTO routage static IPv6 default
Également pour les zones internes sur le Fortigate :
Figure 6-28 | PALO ALTO routage static IPv6 bloc interne

6.3. Configuration du firewall Interne en Dual-Stack

Comme indiqué lors de la pré-étude, nous allons utiliser comme firewall interne un Fortigate pour
respecter l’architecture réseau que nous avons en production.
RESET
USB
DC + 12V MGMT USB W AN2 W AN1 DMZ 7 6 5 4 3 2 1
Figure 6-29 | Firewall Fortigate

Comme il s’agit d’un équipement neuf il faut procéder à la mise à jour du Firmware. Par défaut le port1
est configuré avec l’adresse IP 192.168.1.99 et le DHCP est activé. Il faut donc se connecter sur le port1
et on peut se connecter via l’adresse https://192.168.1.99 sur l’interface web d’administration. Le user
et le mot de passe par défaut sont admin/sans mot de passe.
La version du Firmware préinstallée est la 5.2.5, il faut vérifier l’ « upgrade path » dans la
documentation Fortigate, ceci indique les étapes à respecter afin de procéder à une mise à jour de
Firmware propre. Voici donc le chemin de version à respecter :
Figure 6-30 | Fortigate upgrade path
J’ai donc effectué dans un premier temps la mise à jour vers la version 5.4.0 pour ensuite passer vers
la version 5.4.1. Une fois la version 5.4.0 installée, on peut cliquer sur update et lancer la mise à jour.
Figure 6-31 | Fortigate mise à jour
J’ai rencontré un problème lors de la mise à jour vers la version 5.4.1. Ce problème est connu et
documenté chez Fortinet. Il concerne bien notre modèle 60D. Pour résoudre le problème, j’ai dû
connecter un câble console sur l’équipement, le redémarrer et restaurer le Firmware précédent :

Figure 6-32 | Fortigate restore Firmware
6.3.2. Configuration des zones
Nous n’allons pas configurer de zone sur le Fortigate. Il est possible de le faire mais comme nous ne le
faisons pas en production. Je vais rester sur le même principe de configuration. Nous allons donc
appeler nos interfaces avec le nom des zones que nous avions défini.
6.3.3. Configuration de l’interface outside
Afin de pouvoir configurer des adresse IPv6 il faut activer la fonctionnalité suivante :
Figure 6-33 | Fortigate activation IPv6
Par la suite on peut configurer l’interface de la façon suivante : aller dans « Network », « Interfaces »,
et double cliquer sur internal3 (qui correspond au port numéro 3), ensuite entrer les infos comme ci-
dessous :
Figure 6-34 | Fortigate configuration interface outside

L’interface outside du Fortigate et l’interface inside du PALO ALTO peuvent maintenant communiquer
en Dual-Stack IPv4/IPv6.
6.3.4. Configuration des sous-interfaces
Comme c’est le cas en production sur notre Fortigate, nous allons créer 4 sous-interfaces pour nos
réseaux internes. Ces sous interfaces se trouveront toutes sur le même port physique (internal2) qui
sera connecté sur notre switch. Il faudra donc configurer le port du switch en mode trunk et accepter
ces quatre vlan. Nous pourrons ainsi connecter le switch ESX à notre switch pour transmettre le flux
au Fortigate. Comme nous l’avons vu précédemment dans la configuration du PALO ALTO, il y aura des
VLAN internes et externes qui seront gérés sur le même switch, il faudra donc bien définir quel VLAN
est accepté dans chaque trunk configuré sur le switch. Dans notre réseau de production nous avons
un switch pour l’externe et un pour l’interne. Pour des raisons de matériel nous n’allons utiliser qu’un
seul switch.
Il faut donc sélectionner « internal2 » et créer une sous interface :
Figure 6-35 | Fortigate création sous-interface
Voici donc la configuration de notre réseau INT_CISEL, on sélectionne les accès à l’interface, dans notre
cas on veut accéder à l’administration du firewall via https et SSH et pouvoir également faire des Ping
sur l’interface :
Figure 6-36 | Fortigate Interface INT_CISEL

Voici donc nos trois sous interface une fois configurées :
Figure 6-37 | Fortigate sous-interfaces
6.3.5. Création des objets
La nomenclature a déjà été définie lors de la configuration du PALO ALTO. Pour le Fortigate il est plus
simple de créer les objets en exportant la configuration, ensuite on peut modifier le ficher de
configuration et l’importer à nouveau :
Figure 6-38 | Fortigate création d'objets
Après le backup on peut éditer le fichier avec notepad++
Figure 6-39 | Fortigate exemple objet fichier de configuration
On peut ainsi ajouter facilement des objets sans renseigner le UUID car il sera généré
automatiquement à l’importation du fichier de configuration.

6.3.6. Configuration des règles
Comme c’est le cas pour notre PALO ALTO nous allons dans un premier temps ouvrir tout le flux et par
la suite restreindre au strict nécessaire. Contrairement au PALO ALTO la configuration des règles pour
IPv6 et IPv4 ne se fait pas au même endroit.
Pour IPv4 il faut suivre la procédure suivante :
Figure 6-40 | Fortigate création de règle IPv4
Sur le Fortigate on peut se permettre d’accepter dans un premier temps ce qui vient de l’outside car
le flux qui vient d’internet est bloqué par le PALO ALTO, mais par la suite bien évidement il faudra
restreindre les accès sinon il n’est pas utile d’avoir deux niveaux de firewall. On désactive le NAT dans
toutes nos règles car nous n’avons pas besoin de NAT sur le Fortigate.
Figure 6-41 | Fortigate règle IPv4 de base
Même chose pour IPv6 mais cette fois depuis « IPv6 Policy » comme on peut le voir ci-dessous :
Figure 6-42 | Fortigate règle IPv6 de base

6.3.7. Configuration du routage

Comme pour les règles la configuration du routage IPv4 et IPv6 ne s’effectue pas au même endroit
comme on peut le voir :
Figure 6-43 | Fortigate configuration routage
Voici donc les deux routes à créer. Il s’agit de la route par défaut en IPv4 et IPv6. Elle indique à quelle
IP « gateway » transmettre les paquets si la destination n’est pas connue par le Fortigate.
Figure 6-44 | Fortigate routage static
On peut voir ci-dessous toutes les « route », on retrouve bien nos deux « route » static plus les
réseaux directement connectés sur le Fortigate.
Figure 6-45 | Fortigate table de routage
6.3.8. Test de connexion

On peut donc maintenant tester la sortie sur internet depuis notre firewall Fortigate. On peut par
exemple effectuer un Ping 8.8.8.8 pour valider la configuration en IPv4 ou 2001:4860:4860::8844
pour IPv6. Avant cela il faut modifier notre règle de NAT, en effet dans le PALO ALTO uniquement le
subnet INT_CISEL est configuré en NAT, il faut donc ajouter l’adresse IPv4 de l’interface outside du
Fortigate par exemple.

Voici donc la modification :
Figure 6-46 | PALO ALTO modification règle
Depuis le menu Dashboard du Fortigate, on peut détacher la console web afin de faire nos tests.
Ensuite entrer les commandes suivantes :
Figure 6-47 | Fortigate test ping IPv4
On peut également faire le test en IPv6
Figure 6-48 | Fortigate test ping IPv6

6.4. Configuration du switch Cisco Catalyst 2960

Le switch va permettre de connecter nos serveurs et autres périphériques sur les firewalls. Il sera
important de configurer les trunk correctement afin de ne pas laisser passer tous les VLAN.
Figure 6-49 | switch Cisco Catalyst 2960
Dans un premier temps j’ai effectué un reset du switch via le câble console. Voici les commandes à
exécuter :
Write erase
Confirm
Dir flash
delete flash:vlan.dat
relad
Par la suite il faut configurer un nom pour le switch :
conf t
hostname SW01
Afin de pouvoir se connecter en telnet, on va définir un mot de passe, activer l’encryption des mots de
passe et également définir un mot de passe pour le mode privilégié (enable).
SW01#conf t
SW01(config)#service password-encryption
Switch(config)#line vty 0 15
Switch(config-line)#password ***
Switch(config-line)#login
Switch(config-line)#exit
Switch(config)#enable password ***
Switch(config)#exit
SW01#wr

6.4.2. Configuration des VLAN et adresse IP du switch

On peut maintenant créer les vlan pour chaque sous-réseau :
SW01(config)#vtp mode transparent

SW01(config)#vlan 390
SW01(config-vlan)#name CLOUD_CISEL
SW01(config-vlan)#ex
SW01(config-vlan)#name PC_CISEL
SW01(config-vlan)#name DNS_PUB
SW01(config-vlan)#name SERVICES
SW01(config-vlan)#name CLOUD_PUB
SW01(config-vlan)#name CLOUD_PRIV
SW01(config-vlan)#name MANAGEMENT
SW01(config-vlan)#end
SW01#wr
Configuration de l’adresse IP du switch et sa passerelle par défaut :
SW01(config)#interface vlan420
SW01(config-if)#ip address 172.20.70.3 255.255.255.240
SW01(config-if)#exit
SW01(config)#ip default-gateway 172.20.70.1
SW01(config)#exit
SW01#wr
6.4.3. Configuration des interfaces 1 et 2

Les interfaces 1 et 2 seront utilisées pour connecter les switch ESX. L’interface 1 sera connectée sur le
port 24 du switch c-matran-34.220-3020 (switch vlan interne) et l’interface 2 sera connectée sur le
port 24 du switch c-matran-4.52.3020 (switch vlan externe).
Il faut donc configurer le port 1 en trunk et accepter les vlan 390 (cloud_cisel) et 420 (management) :
SW01(config)#interface fastEthernet 0/1

SW01(config-if)#description ***UPLINK C-MATR-34.220-3020 CLOUD CISEL***
SW01(config-if)#switchport mode trunk
SW01(config-if)#switchport trunk allowed vlan 390,420

SW01(config-if)#end
SW01#wr
Le port 2 doit être configuré en trunk et accepter les vlan 680 (cloud_pub), 690 (cloud_priv) :

SW01(config-if)#description ***UPLINK C-MATR-4.52.3020 PROXY***
SW01(config-if)#switchport trunk allowed vlan 680,690
SW01(config-if)#end
SW01#wr
Il faudra par la suite configurer les switch c-matran-34.220-3020 et c-matran-4.52.3020, ceci est
développé dans le chapitre « configuration de l’environnement VMware ».
6.4.4. Configuration de l’interface 3
L’interface 3 sera connectée directement sur le port 2 du Fortigate et permettra de transporter tous
les vlan configurés sur le Fortigate. Voici donc la configuration à effectuer sur le port 3 :

SW01(config-if)#description ***UPLINK FORTIGATE DMZ INTERNES***
SW01(config-if)#switchport trunk allowed vlan 390,400,410,420
SW01(config-if)#end
SW01#wr
6.4.5. Configuration des interfaces 4, 5 et 6

Ces interfaces sont utilisées pour connecter l’Infoblox, l’interface 4 sera connectée sur l’interface LAN1
de l’Infoblox qui sera configurée pour le DNS interne ainsi que les services IPAM et DHCP. L’interface
5 sera connectée sur l’interface LAN2 de l’Infoblox qui sera configurée pour la partie DNS public. Pour
finir l’interface 6 sera connectée sur l’interface MGMT de l’Infoblox et permettra donc d’accéder à son
administration.
Les trois ports doivent donc être en mode access avec le bon vlan taggé :

SW01(config-if)#description ***UPLINK INFOBLOX LAN1 DNS INTERNE***
SW01(config-if)#switchport mode access
SW01(config-if)#switchport access vlan 410
SW01(config-if)#ex
SW01(config-if)#description ***UPLINK INFOBLOX LAN2 DNS EXTERNE***


SW01(config-if)#ex
SW01(config-if)#description ***UPLINK INFOBLOX MGMT***
SW01(config-if)#end
SW01#wr
6.4.6. Configuration des interfaces 7 et 8
L’interface 7 sera connectée directement sur le port 2 du PALO ALTO et permettra de transporter tous
les vlan configurés sur le PALO ALTO. Voici donc la configuration à effectuer sur le port 7 :

SW01(config-if)#description ***UPLINK PALO DMZ EXTERNE***
SW01(config-if)#switchport trunk allowed vlan 670,680,690
SW01(config-if)#end
SW01#wr
Le port 8 peut être désactivé car il ne sera pas utilisé :
SW01(config)#interface f0/8
SW01(config-if)#shutdown
6.4.7. Configuration de l’interface gigabit
L’interface gigabit sera utilisée pour connecter le poste de test dans le réseau cisel-lab. Il faut donc
tagger le vlan 400 sur l’interface.
SW01(config)#interface gigabitEthernet 0/1

SW01(config-if)#description ***poste de test***
SW01(config-if)#end
SW01#wr
6.4.8. Connexion câbles
Pour des raisons de confort, j’ai placé le Fortigate, le PALO ALTO, l’Infoblox et le switch dans une
armoire qui se trouve dans notre DataCenter. Par la suite j’ai pu connecter un câble sur l’interface
gigabit du switch vers l’armoire de patch qui possède une liaison sur l’armoire de patch à l’étage où se

trouvent nos bureaux. J’ai ainsi pu « patcher » ce renvoi à ma boite de sol afin d’avoir une connectivité
depuis mon bureau sur le résau cisel-lab. À ce stade je peux donc fixer une adresse IP (v4 et v6)
manuellement sur mon PC et accéder à tous mes équipements depuis mon bureau. Je peux également
accéder à internet en IPv4 et IPv6.
6.5. Configuration de la plateforme Infoblox

Afin de pouvoir bénéficier des services IPAM, DNS et DHCP nous allons configurer notre plateforme
Infoblox. Nous verrons que lors de sa configuration le boitier Infoblox porte le nom de « GRID » dans
les menus de l’interface web.
Figure 6-50 | plateforme Infoblox

Pour accéder à l’Infoblox avec la configuration par défaut il faut configurer l’adresse IPv4 fixe sur son
pc en 192.168.1.1 ensuite connecter un câble réseau sur l’interface 1 de l’Infoblox (l’adresse IP par
défaut est la 192.168.1.2), puis ouvrir une page web, aller sur https://192.168.1.2 et se connecter
avec le user et mot de passe par défaut admin/Infoblox.
Dans le menu « Grid » et son sous onglet « Grid Manager » dans l’onglet « Visualization » se trouve
l’option « Grid Prorpieties ». On peut y définir le nom de notre Grid :
Figure 6-51 | Infoblox configuation Grid

On peut ensuite donner un nom de domaine à notre Grid en cliquant sur edit :
Figure 6-52 | Infoblox configuation Grid FQDN
6.5.2. Configuration lan1, lan2 et MGMT

Dans le menu « Grid » et son sous onglet « Grid Manager » dans l’onglet « Visualization », faire un
clic sur « Edit » et ensuite dans l’onglet « Basic » sur l’option « network » se trouvent toutes les
interfaces :
Figure 6-53 | Infoblox configuation Interface
Nous allons donc configurer notre interface LAN1 comme suit :
Figure 6-54 | Infoblox configuation LAN1 IPv4
Ensuite il faut configurer LAN2 de la manière suivante :
Figure 6-55 | Infoblox configuation LAN2 IPv4
Pour finir configurer l’interface de management
Figure 6-56 | Infoblox configuation MGMT IPv4

Il faut également configurer les adresses IPv6 sur les deux interfaces LAN :
Figure 6-57 | Infoblox configuation LAN1 et LAN2 IPv6
Nous pouvons maintenant connecter chaque interface de l’Infoblox sur le port du switch défini lors
de sa configuration et ainsi pouvoir accéder à Infoblox via l’url https://172.20.70.4 depuis notre PC
de test.
6.5.3. Configuration DHCPv6
Nous allons maintenant créer un pool DHCPv6 pour le subnet INT_CISEL afin de recevoir une adresse
ipv6 automatiquement sur les PC de test. Il faut tout d'abord configurer le « DHCP RELAY » sur le
Fortigate avec les commandes suivantes:
config system interface

edit INT_CISEL
set dhcp6-relay-service enable
set dhcp6-relay-ip 2001:678:204:2410::2
Ensuite on peut configurer Grid. Il faut ajouter la plage réseau qu'on veut administrer:
Figure 6-58 | Infoblox configuation Réseau cisel-lab IPv6
On ajoute donc le subnet et son préfixe:
Figure 6-59 | Infoblox configuation cisel-lab préfixe

On active ce réseau sur le Grid en le sélectionnant, sinon on ne pourra pas l'administrer :
Figure 6-60 | Infoblox configuation cisel-lab Grid
Ici on ajoute les adresses DNS, dans notre cas on va donc entrer l’adresse IP de l’interface LAN1 de
notre Infoblox et le DNS de google :
Figure 6-61 | Infoblox configuation cisel-lab DNS
Maintenant on peut créer la plage d'adresse qu'on veut distribuer par DHCP :
Figure 6-62 | Infoblox configuation cisel-lab plage DHCPv6
On donne la plage d’adresse IPv6 :
Figure 6-63| Infoblox configuation cisel-lab plage DHCPv6
Il faut ensuite activer la plage sur le Grid :
Figure 6-64| Infoblox configuation cisel-lab Grid

La communication pour le DHCPv6 se fait via le port udp 546 et 547. Il faut donc créer la règle comme
ci-dessous. Le service DHCP6 comprend le port UDP 546 et 547 :
Figure 6-65| Fortigate règle DHCPv6
On peut maintenant tester la distribution d’adresse. Ci-dessous on peut voir que l'adresse n'est pas à
jour, le PC a conservé l'adresse qui avait été définie dans une précédente configuration de test. On
peut voir en première ligne que le poste envoie un message « confirm » à tous les serveurs DHCP
(adresse multicast ff02::1:2) pour savoir si son adresse est encore valide :
Figure 6-66| erreur DHCPv6 Wireshark
Dans un premier temps je pensais que l’adresse ne se mettait pas à jour car elle existait toujours
dans le neighbor-cache du Fortigate. Comme on peut le voir ci-dessous :
Figure 6-67 | Fortigate neighbor-cache
Cependant même avec la commande flush pour supprimer toutes les entrées du cache, l'adresse IPv6
n'est toujours pas mise à jour.
Figure 6-68 | Fortigate neighbor-cache flush

Pour corriger ce problème, j’ai effectué la commande suivante qui va libérer l’adresse IP et demander
une nouvelle adresse au serveur DHCPv6:
ipconfig /release6 && ipconfig /renew6
Après un certain temps d’investigation, j’ai pu trouver la source du problème. Il s’agissait d’une
configuration sur le Grid qui conserve les adresses attribuées jusqu’à une semaine après la
suppression de la plage d’adresse:
Figure 6-69 | Infoblox configuration DHCPv6 conserve l'attribution d'adresse
On peut donc analyser maintenant l’attribution de notre nouvelle adresse IPv6 dans wireshark:
Figure 6-70 | Confirmation DHCPv6 Wireshark
Cette fois l'adresse obtenue est bien dans le range du DHCP. On constate dans la capture Wirehsark
que l'adresse Link-Local client envoie une requête « solicit » à l'adresse mulitcast ff02::1:2. Cette
adresse correspond à tous les serveurs DHCP. Comme le dhcp relay est configuré sur le Fortigate, c'est
bien son adresse link-local qu'on voit dans les captures wireshark, en effet c'est le Fortigate qui va
questionner le DHCPv6 et renvoyer les informations au PC, comme on peut le voir dans le schéma ci-
dessous :

23
Figure 6-71 | fonctionnement DHCPv6 relay
6.5.4. Configuration DHCPv4

Comme le but est d’avoir une configuration en Dual-stack sur notre poste de travail, il faut configurer
également le DHCP pour les adresses IPv4. Il est possible de configurer le « DHCP relay » directement
depuis l’interface web du Fortigate. Nous allons donc éditer l’interface « INT_CISEL » et entrer
l’adresse de l’interface lan1 de l’Infoblox :
Figure 6-72 | Fortigate DHCPv4
La création du réseau et de la plage d’adresse s’effectue selon le même principe que pour IPv6. J’ai
donc créé le réseau et la plage d’adresse suivants :
Figure 6-73 | Infoblox réseau cisel-lab IPv4
23
CiscoPress. 2013.

Il y a tout de même une différence importante avec le DHCPv4 : il faut lui fournir la passerelle par
défaut qui permet de transférer les paquets vers les autres réseaux. Avec IPv6 nous n’avons pas besoin
de la définir car c’est l’adresse Link-Local qui doit communiquer avec les équipements qui se trouvent
sur le même segment réseau.
Il faut également créer la règle dans le Fortigate :
Figure 6-74 | Fortigate règle DHCPv4
Comme on peut le voir ci-dessous nous avons bien tous les paramètres qui remontent en IPv4 et IPv6
sur notre carte réseau. On peut voir également que la passerelle par défaut est l’adresse Link-Local
de notre Fortigate :
Figure 6-75 | PC de test validation Dual-Stack
6.5.5. Utilisation de l’IPAM Infoblox
Comme expliqué précédemment la plateforme Infoblox permet également la gestion des adresses IP
via IPAM. L’avantage est que la gestion du DNS du DHCP et IPAM se fait sur la même plateforme. Quand
nous avons créé notre réseau et range dans le DHCP ceci a automatiquement créé la vue de notre
réseau dans l’IPAM :

Figure 6-76 | Infoblox IPAM
Nous pouvons donc créer tous nos réseaux dans l’IPAM :
Figure 6-77 | Infoblox IPAM vue globale
On retrouve notre poste de test dans le préfixe 2001:678:204::4400:/64. Comme on peut le voir ci-
dessous :
Figure 6-78 | Infoblox IPAM pc de test
L’IPAM nous permet donc d’avoir un affichage centralisé de toutes nos adresses configurées et
d’afficher si un enregistrement DNS est lié à l’adresse IP. Nous avons également la possibilité de
réserver une adresse pour une machine. Sur IPv4 la réservation d’adresse se fait avec l’adresse
physique de la carte réseau « MAC ADDRESS », avec IPv6 la réservation se fait via le DUID (DHCP
Unique IDentifier). Voici comment j’ai pu créer une réservation :
• On effectue la commande ipconfig /release6 sur le poste de test

• On supprime le « Lease » et l’entrée DNS dans Infoblox
• On ajoute l’adresse IPv6 fixe :

Figure 6-79 | Infoblox IPAM ajout IPv6 fixe
• On récupère le DUID avec la commande « ipconfig /all » sur le poste de test et on copie sa
valeur dans l’assistant de création :
Figure 6-80| Infoblox IPAM ajout IPv6 configuration
• Il faut ensuite redémarrer le service Infoblox

• Effectuer la commande ipconfig /renew6
• L’adresse IP réservée est correctement attribuée au poste :
Figure 6-81| Infoblox IPAM IPv6 fixe validation sur pc de test
On peut ensuite facilement créer une entrée DNS après avoir sélectionné l’adresse IPv6, puis en
ajoutant une entrée « AAAA Record » :
Figure 6-82| Infoblox IPAM ajout AAAA record
Ensuite en sélectionnant le nom FQDN :
Figure 6-83| Infoblox IPAM ajout AAAA record configuration

6.5.6. Configuration du DNS
Nous allons maintenant configurer les deux vues DNS dans l'Infoblox, une vue « default » qui sera notre
vue pour l'interne (DNS_PRIV) et une vue « External » qui sera pour l'externe (DNS_PUB). La vue
« default » est celle par défaut elle est donc déjà créée.
Création de la vue External :
Il faut donc créer la vue « External » :
Figure 6-84 | Infoblox création vue External
Tout le monde depuis l'externe doit pouvoir résoudre des noms sur cette zone car il s'agit de notre
DNS Public :
Figure 6-85 | Infoblox configuration vue External
On peut maintenant créer la zone cisel-lab.ch :
Figure 6-86 | Infoblox création de la zone cisel-lab.ch
Entrer les informations sur le nom de la zone :

Figure 6-87 | Infoblox configuration de la zone cisel-lab.ch
Ajouter la zone au Grid :
Figure 6-88 | Infoblox ajout zone cisel-lab.ch sur le Grid
Il faut maintenant définir quelle interface de l’Infoblox correspond à quelle zone :
Figure 6-89 | Infoblox configuration de la zone cisel-lab.ch
On doit entrer l'adresse IP de l'interface LAN2 pour la vue external. Il n'y a pas besoin de spécifier
l'adresse IPv6, elle est automatiquement activée. LAN1 sera donc pour notre DNS privé comme
expliqué précédemment :
Figure 6-90 | Infoblox configuration zone cisel-lab.ch avec interfaces

Un « restart » des services est nécessaire pour que les modifications soient appliquées :
Figure 6-91 | Infoblox redémarrage du service
Nous pouvons maintenant configurer notre nom de domaine acheté chez switch. Il est nécessaire de
créer l'entrée ns1 avec l'adresse IP public IPv4 et IPv6, pour l'adresse IPv6 il s'agit de l'IP attribué sur
l'interface LAN2 de l'Infoblox, pour l'adresse IPv4 il va falloir créer par la suite une règle de NAT sur le
firewall externe. Dans un premier temps on configure donc notre entrée ns1 :
Figure 6-92 | Configuration ns1 pour le nom de domaine cisel-lab.ch
Par la suite il faut compléter dans l'onglet serveur de nom l'entrée ns1 qu'on vient de créer. Il est
obligatoire de spécifier deux serveurs de nom. Pour le deuxième serveur de nom nous allons utiliser
un serveur DNS mis gratuitement à disposition par Hurricane Electric. Les entrées nous permettent de
spécifier quelle est l'adresse du serveur de nom qui fait autorité pour ce nom de domaine. Voici donc
les deux entrées NS configurées.
Figure 6-93 | Configuration du nom de domaine cisel-lab.ch ns1 et ns2
Reste à configurer notre serveur DNS « slave » sur lequel toutes les entrées DNS seront répliquées.
Depuis dns.he.net il faut sélectionner l’option suivante :
Figure 6-94 | DNS Hurricane Electric configuration du DNS slave

Ensuite, on entre les information sur la zone et on spécifie le « Master » DNS :
Figure 6-95 | DNS Hurricane Electric configuration du DNS master
On ajoute les deux adresses IP comme indiqué dans la capture d'écran précédente afin de pouvoir
autoriser le transfert de zone de notre DNS public Infoblox vers notre DNS public he.net:
Figure 6-96 | Infoblox configuration du transfert de zone
On ajoute donc les deux adresses IP :
Figure 6-97 | Infoblox configuration du transfert de zone vers le DNS slave
Nous devons donc encore configurer le NAT dans le PALO ALTO :
Figure 6-98 | PALOT ALTO configuration du NAT pour le DNS public
Ainsi qu'une règle pour autoriser le flux de l'externe vers l'interne pour les requêtes DNS. Attention,
dans la règle on spécifie bien l'adresse IP public pour IPv4 et non l'adresse privée.
Figure 6-99 | PALO ALTO règle pour le DNS public
On peut voir sur le site de dns.he.com comme notre DNS « slave » est bien connecté à notre Infoblox:

Figure 6-100 | DNS Hurricane Electric contrôle de transfert de zone
Configuration de la vue Default
On peut donc passer maintenant à la configuration de la vue « Default » pour la résolution en

interne :
Figure 6-101 | Infoblox configuration vue default
On active la récursivité pour pouvoir résoudre des noms de domaines extérieurs :
Figure 6-102 | Infoblox activation de la récursivité vue default
Il faut spécifier les clients qui peuvent effectuer des requêtes sur cette vue. Dans ce cas,
comme il s’agit du DNS interne, on va donc spécifier la plage IPv4 et IPv6 qui englobe toutes
nos adresses internes.
Figure 6-103 | Infoblox configuration vue default configuration des clients

On spécifie « any » pour la destination car on aimerait pouvoir résoudre n’importe quel nom depuis
l’interne.
Figure 6-104 | Infoblox configuration vue default destination
On va spécifier les adresses IP de nos « forwarders ». Quand notre serveur DNS ne sera pas capable de
résoudre des noms de domaine, il va transmettre la requête aux « forwarders ». On spécifie ici les
adresses des serveurs DNS de Google.
Figure 6-105 | Infoblox configuration vue default Forwarders
On peut maintenant créer notre zone interne cisel-lab.lan :
Figure 6-106 | Infoblox création de la zone cisel-lab.lan
Spécifier le nom de la zone :
Figure 6-107 | Infoblox configuration de la zone cisel-lab.lan

Activer la zone sur notre Grid :
Figure 6-108 | Infoblox activation de la zone cisel-lab.lan sur le Grid
Ensuite sélectionner la zone et cliquer sur « edit ». Nous avons déjà défini l’adresse IPv6 et v4 de notre
contrôleur de domaine, il faut donc spécifier qu’il sera possible de mettre à jour cette zone depuis les
adresses IPv6 et v4 de celui-ci, afin que les entrées DNS soient automatiquement créées lorsqu’on
ajoute une machine dans le domaine par exemple.
Figure 6-109 | Infoblox configuration pour Active Directory
Nous avons terminé avec la configuration de notre zone mais il faut cependant encore créer une règle
sur notre Fortigate et sur notre PALO ALTO qui permet l’utilisation des « forwarder » pour résoudre
les noms de domaines externes.
Création de la règle IPv6 sur Fortigate :
Figure 6-110 | Fortigate règle pour Forwarders IPv6
Création de la règle IPv4 sur Fortigate :
Figure 6-111 | Fortigate règle pour Forwarders IPv4

Création de la règle sur le PALO ALTO :
Figure 6-112 | PALO ALTO règle pour Forwarders
Il faut également créer une règle pour autoriser le flux depuis notre réseau cisel-lab vers l’outside.
Création de la règle sur le Fortigate :
Figure 6-113 | Fortigate règle cisel-lab vers outside IPv4
Pour IPv6 :
Figure 6-114| Fortigate règle cisel-lab vers outside IPv6
Création de la règle dans le PALO ALTO
Figure 6-115| PALO ALTO règle cisel-lab vers outside IPv4
Nous pouvons donc maintenant tester la résolution de nom depuis l’interne sur notre poste de test :
Figure 6-116 | poste de test contrôle DNS IPv4
On retrouve bien dans les log du PALO ALTO la connexion depuis notre DNS Infoblox vers le
«forwarder » qui est le DNS de google afin de pouvoir résoudre le nom de domaine test.ch
Figure 6-117 | PALO ALTO log Forwarders IPv4

Et également par la suite, le Ping vers l’adresse IP public du serveur où est hébergé le site internet
www.test.ch:
Figure 6-118 | PALO ALTO log ping test IPv4
On peut effectuer le même test en IPv6 :
Figure 6-119 | poste de test contrôle DNS IPv6
La requête DNS de l’Infoblox vers le DNS google :
Figure 6-120 | PALO ALTO log Forwarders IPv6
Et également par la suite le Ping vers l’adresse IP public d’un des serveurs où est hébergé
youtube.com :
Figure 6-121 | PALO ALTO log ping IPv6

6.6. Configuration de l’environnement Vmware

J’ai à disposition pour installer mes machines virtuelles un serveur blade ProLiant BL465c G6 connecté
dans notre HP bladesystem c7000. J’ai un accès pour me connecter sur notre blade avec une vue
restreinte à mon serveur connecté sur l’enclosure numéro 4. Voici donc la face avant vue depuis
l’interface web de management:
Figure 6-122 | Bladesystem c7000 face avant
Voici la face arrière du boitier qui contient 4 switch Cisco 3020 ainsi que deux switch Brocade pour la
partie SAN
Figure 6-123 | Bladesystem c7000 face arrière
6.6.1. Configuration des switch
Les switch 3020 possèdent 24 ports Gigabit, les 16 enclosures sont connectées directement sur les 16
premiers ports de chaque switch en respectant la logique (numéro enclosure = numéro port du
switch). Ce sont des ports internes connectés directement sur le blade, on ne les voit pas sur la face
arrière du châssis. Les deux premiers switch du haut sont utilisés pour les VLAN internes et les deux
switch du bas pour les VLAN externes. Les deux switch sont doublés pour la redondance. Dans mon
réseau de simulation je n’ai pas besoin de redondance, car dans le pire des cas, si un switch tombe en
panne, je peux connecter mon câble sur le port du deuxième switch. Je dois donc configurer le port 4
connecté sur mon serveur blade ainsi que le port 24 qui sera utilisé pour connecter mon switch de lab.
Tout d’abord je vais effectuer la configuration sur les switch internes c-matran-34.220-3020 et c-
matran-34.221-3020 :

Création des vlan :
c-matran-34.220-3020#conf t
c-matran-34.220-3020(config)#vlan 390
c-matran-34.220-3020(config-vlan)#name IPV6CAN_INT_CLOUD_CISEL
c-matran-34.220-3020(config-vlan)#ex
c-matran-34.220-3020(config)#vlan 420
c-matran-34.220-3020(config-vlan)#name IPV6CAN_MANAGEMENT
c-matran-34.220-3020(config-vlan)#end
c-matran-34.220-3020#wr
VTP est activé sur les deux switch je n’ai donc pas besoin de créer les vlan sur le deuxième switch
interne.
Configuration des interfaces :
c-matran-34.220-3020#conf t
c-matran-34.220-3020(config)#interface gigabitEthernet 0/4
c-matran-34.220-3020(config-if)#switchport mode trunk
c-matran-34.220-3020(config-if)#description ***** Lame de test pour CAN / PROJET IPV6 / DMZ
Internes ****
c-matran-34.220-3020(config-if)#switchport trunk allowed vlan 390,420
c-matran-34.220-3020(config-if)#end
c-matran-34.220-3020#wr
c-matran-34.220-3020(config)#interface gigabitEthernet 0/24

c-matran-34.220-3020(config-if)#switchport mode trunk
c-matran-34.220-3020(config-if)#description ***** UPLINK SWWITCH CAN / PROJET IPV6 / DMZ
Internes ****
c-matran-34.220-3020(config-if)#switchport trunk allowed vlan 390,420
c-matran-34.220-3020(config-if)#end
c-matran-34.220-3020#wr
J’effectue les mêmes commandes sur le switch c-matran-34.221-3020.
Nous pouvons maintenant configurer les switch externes c-matran-4.52.3020 et c-matran-4.53.3020:
Création des vlan :
c-matran-4.52.3020#conf t
c-matran-4.52.3020(config)#vlan 680
c-matran-4.52.3020(config-vlan)#name IPV6CAN_OUT_CLOUD_PUB
c-matran-4.52.3020(config-vlan)#ex
c-matran-4.52.3020(config)#vlan 690
c-matran-4.52.3020(config-vlan)#name IPV6CAN_OUT_CLOUD_PRIV
c-matran-4.52.3020(config-vlan)#end
c-matran-4.52.3020#wr
VTP est également activé sur ce switch.
Configuration des interfaces :

c-matran-4.52.3020#conf t
c-matran-4.52.3020(config)#interface gigabitEthernet 0/4
c-matran-4.52.3020(config-if)#switchport mode trunk
c-matran-4.52.3020(config-if)#description ***** Lame de test pour CAN / PROJET IPV6 / DMZ
Externes ****
c-matran-4.52.3020(config-if)#switchport trunk allowed vlan 680,690
c-matran-4.52.3020(config-if)#end
c-matran-4.52.3020(config)#interface gigabitEthernet 0/24

c-matran-4.52.3020(config-if)#switchport mode trunk
c-matran-4.52.3020(config-if)#description ***** UPLINK SWWITCH CAN / PROJET IPV6 / DMZ
Externes ****
c-matran-4.52.3020(config-if)#switchport trunk allowed vlan 680,690
c-matran-4.52.3020(config-if)#end
J’effectue les mêmes configurations sur le deuxième switch c-matran-4.53.3020.
On peut maintenant connecter les deux switch c-matran-34.220-3020 (port 24) et c-matran-4.52.3020
(port 24) sur notre switch SW01, respectivement port 1 et 2.
6.6.2. Contrôle de la configuration
La commande show cdp neighbors permet d’afficher les switch connectés. J’effectue cette commande
sur notre switch SW01 afin de contrôler que les switch soient connectés correctement.
Figure 6-124 | contrôle configuration switch ESX
Avec la commande show interfaces trunk on peut s’assurer qu’on permet les même vlan dans le
trunk que sur les configurations des switch c-matran :
Figure 6-125 | contrôle configuration switch SW01 trunk

6.6.3. Configuration du serveur
Le serveur possède deux disques durs de 300 GB chacun que j’ai configurés en raid0. Nous avons donc
une capacité de 600GB. Pour installer vmware ESXi 6.0, j’ai connecté une clé USB dans le serveur afin
d’effectuer l’installation sur cette clé. Une fois installée j’ai configuré l’interface de management afin
de pouvoir me connecter via le client vSphere. Voici donc la configuration effectuée :
Aller dans « configure Management Network »
Figure 6-126 | ESX configuration inerface management
Configuration du VLAN (vlan de management)
Figure 6-127 | ESX configuration VLAN

Configuration de l’adresse IP
Figure 6-128 | ESX configuration IPv4
6.6.4. Configuration du Virtual switch VMware
Notre Virtual switch VMware doit être configuré afin de connecter les cartes réseau de nos machines
virtuelles sur les bons vlan. Après installation du client vsphere sur notre machine de test, on peut se
connecter à l’ESX via l’adresse IP de management 172.20.70.8 que nous avons configurée
précédemment. Une fois connecté il faut se rendre dans les menus suivants :

Figure 6-129 | ESX configuration mise en réseau
Cliquer sur « ajouter » et entrer les informations sur le VLAN à créer :
Figure 6-130 | ESX configuration VLAN
Voilà donc le résultat une fois tous les VLAN’s configurés :
Figure 6-131 | ESX VLAN's configurés
Nous pouvons maintenant installer nos machine virtuelles et sélectionner les bon vlan pour nos carte
réseaux.
6.6.5. Création du volume de stockage
Pour configurer l’espace de stockage sur l’ESX il faut se rendre dans « Configuration » et dans
« stockage » :
Figure 6-132 | ESX configuration du volume de stockage

Sélectionner « Ajouter stockage » et sélectionner le volume disponible et cliquer sur « terminer ». Le

volume à bien été créé et est disponible pour les machines virtuelles à créer :
Figure 6-133 | ESX volume configuré
6.7. Installation serveur Active Directory

Nous avons besoin d'un serveur AD pour faire fonctionner notre serveur Exchange. J’ai donc installé la
machine virtuelle SVAD01 avec une installation standard de Windows serveur 2012 R2 ainsi que les
dernières mises à jour Windows. J’ai effectué les configurations basiques et copié cette machine
virtuelle afin de l’utiliser pour notre serveur Exchange.
6.7.1. Configuration réseau
Il est important de sélectionner le bon vlan pour notre carte réseau :
Figure 6-134 | AD configuration VLAN
Il faut également créer les règles pour autoriser le flux de la machine virtuelle vers l’externe. Nous
allons également configurer les règles pour le serveur exchange SVEXCLOUD02.
Modifier la règle de Nat sur le PALO ALTO pour avoir accès à internet en IPv4 :
Figure 6-135 | PALO ALTO règle de NAT serveur AD

Ajouter une règle pour autoriser l’accès vers l’externe via les ports utilisés :
Figure 6-136 | PALO ALTO règle service cloud vers outside
Ajouter une règle sur le Fortigate pour IPv4
Figure 6-137 | Fortigate règle service cloud vers outside IPv4
Et pour IPv6 :
Figure 6-138 | Fortigate règle service cloud vers outside IPv6
Il est également nécessaire de créer une règle sur le Fortigate pour accéder via le bureau à distance
sur les serveurs. Nous pouvons donc par la suite configurer les adresses IP du serveur depuis la console
VMware :
Configuration de l'adresse IPv4
Figure 6-139 | AD configuration IPv4

Configuration de l'adresse IPv6
Figure 6-140 | AD configuration IPv6
Test de résolution
Figure 6-141 | AD test résolution DNS IPv6
Test de résolution en ipv4
Figure 6-142 | AD test résolution DNS IPv4
6.7.2. Installation Active Directory
Maintenant que la configuration réseau est effectuée, on peut se connecter à distance sur le serveur
et ajouter le rôle Active directory :
Figure 6-143 | AD installation du rôle Active Directory

Il faut créer une nouvelle forêt cisel-lab.lan:
Figure 6-144 | AD création forêt cisel-lab.lan
Décocher le DNS car nous allons utiliser le DNS Infoblox :
Figure 6-145 | AD configuration nouvelle forêt
Il faut ensuite redémarrer le serveur. On peut vérifier que les entrées soient bien créées dans Infoblox :
Figure 6-146 | Infoblox zone cisel-lab.lan connectée à l'AD
Comme nous allons ajouter notre domaine public cisel-lab.ch il faut l’ajouter dans nos suffixes afin de
pouvoir se connecter avec les comptes au format compte@cisel-lab.ch :

Figure 6-147 | AD ajout suffixe cisel-lab.ch
Ensuite on peut créer une structure de base dans notre Active Directory ainsi que des utilisateurs pour
effectuer des tests par la suite. On voit ci-dessous que j’ai créé une OU Cisel, avec trois OU; Computers
pour les postes de travail, Servers pour les serveurs et Users pour les utilisateurs. Je vais utiliser le
compte admincan pour me connecter sur les serveurs et gérer le serveur exchange par la suite. Voici
donc la vue de notre Active Directory:
Figure 6-148 | AD création de la structure
6.8. Installation du serveur Exchange

J’ai donc créé un nouveau serveur virtuel en reprenant la copie de base du serveur SVAD01.
L’installation du serveur Exchange m’a posé beaucoup de problèmes. En effet dans un premier temps,
j’ai installé le serveur SVEXCLOUD01. J’ai dû par la suite installer un nouveau serveur virtuel
SVEXCLOUD02 car je n’arrivais pas à faire fonctionner Exchange.

6.8.1. Configuration réseau
Comme pour le serveur SVAD01, on sélectionne le bon vlan pour notre carte réseau :
Figure 6-149 | Exchange configuration VLAN
Nous avons déjà configuré précédemment les règles sur le Fortigate et le PALO ALTO. Nous pouvons
donc passer directement à la configuration de la carte réseau :
Figure 6-150 | Exchange configuration IPv4
Configuration de l'adresse IPv6 :
Figure 6-151 | Exchange configuration IPv6

Test de résolution
Figure 6-152 | Exchange test résolution IPv6
Test de résolution en ipv4
Figure 6-153 | Exchange test résolution ipv4
6.8.2. Ajout de du serveur dans le domaine
Avant d’installer Exchange il faut ajouter le serveur dans le domaine :
Figure 6-154 | Exchange ajout du serveur dans le domaine cisel-lab.lan
Après avoir redémarré le serveur, Il faut vérifier que les entrées AAAA pour IPv6 et A pour IPv4 ont
bien été créées dans Infoblox :

Figure 6-155 | Infoblox création des entrées dans le DNS
On peut donc faire un Ping de svad01 depuis le serveur exchange :
Figure 6-156 | Exchange test ping SVAD01
Et également un Ping depuis le serveur svad01 sur le serveur exchange :
Figure 6-157 | AD ping SVEXCLOUD02
6.8.3. Installation d’Exchange
Avant tout, il faut préparer notre AD. Pour cela il faut exécuter le setup d’exchange 2013 cu12 avec les
paramètres suivants depuis une fenêtre PowerShell démarrée en administrateur :
.\Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

.\Setup.exe /PrepareAD /ON:ExchangeCloud /IAcceptExchangeServerLicenseTerms
.\setup /PrepareAllDomains /IAcceptExchangeServerLicenseTerms
Import-Module ServerManager
Install-WindowsFeature rsat-adds
Ceci est indispensable afin de préparer le schéma d’Active Directory ainsi que les différents groupes
de sécurité et autres. Après l’installation, il faut redémarrer le serveur. Ensuite nous pouvons effectuer
l’installation des différents prérequis à télécharger et à installer :

• Microsoft Unified Communications Managed API 4.0

• Filter Pack de Microsoft Office 2010 x64
• Service Pack pour Filter Pack de Microsoft Office 2010 x64
Et pour finir les modules nécessaires sur notre serveur exchange, il faut également faire l’installation
via une fenêtre PowerShell démarrée en administrateur :
Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-

over-HTTP-Proxy, RSAT-ADDS, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-
Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-
Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter,
Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45,
Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-
Auth, Web-WMI, Windows-Identity-Foundation
Après redémarrage on peut exécuter le setup d’exchange 2013 cu12, mais, attention ! Il faut
l’exécuter en administrateur. À l’étape suivante il faut sélectionner ce qu’on veut installer :
Figure 6-158 | Exchange séléction des rôles à installer
6.8.4. Configuration d’exchange

Après redémarrage du serveur, il faut exécuter depuis la console « Exchange Management Shell »
une commande qui permettra de se connecter depuis le domaine cisel-lab.ch
Figure 6-159 | Exchange démarrer Management Shell en administrateur
Ensuite taper la commande :
New-AcceptedDomain -Name 'cisel-lab.ch' -DomainName 'cisel-lab.ch'
On peut aussi le configurer depuis l’interface web de management du serveur. L’adresse est
https://localhost/ecp. Par défaut le compte « admincan » possède un accès administrateur à

exchange car c’est avec ce compte que j’ai effectué l’installation d’exchange. Voici comment
configurer l’autorisation sur le domaine cisel-lab.ch depuis l’interface web de management :
Figure 6-160 | accepter domaine cisel-lab.ch via interface web
Il faut également modifier le format des adresses de messagerie par défaut au format
prenom.nom@cisel-lab.ch pour tous les comptes mail créés dans notre serveur Exchange :
Figure 6-161 | Exchange format adresse de messagerie
On peut maintenant créer une boite aux lettres pour notre compte admin :
Figure 6-162 | Exchange créer une boite au lettre
Une fois créée on voit que notre adresse de messagerie est bien au format voulu, admin@cisel-lab.ch
Figure 6-163 | Exchange validation format adresse de messagerie

Pour que notre serveur exchange soit atteignable depuis l’interne comme depuis l’externe, on va lui
donner le FQDN mail.cisel-lab.ch. Il faudra donc configurer notre DNS interne et public. Dans un
premier temps nous allons déjà nous assurer que tous les répertoires virtuels d’exchange soient
atteignables depuis l’interne. Pour cela on crée la zone cisel-lab.ch sur notre Infoblox avec les entrées
A et AAAA mail.cisel-lab.ch, avec les adresses IP du serveur Exchange :
Figure 6-164 | Infoblox création entrées A et AAAA pour serveur Exchange
On peut donc tester maintenant de faire un Ping de mail.cisel-lab.ch depuis notre poste de test. On
constate ci-dessous que mail.cisel-lab.ch répond en IPv4 et en IPv6 :
Figure 6-165 | test résolution mail.cisel-lab.ch
Nous pouvons donc maintenant configurer les adresses interne et externe de nos répertoires virtuels
avec notre nom FQDN mail.cisel-lab.ch. On peut le faire depuis la console d’administration mais il est
plus rapide de le faire depuis la console Exchange :
Get-OABVirtualDirectory|Set-OABVirtualDirectory -InternalUrl https://mail.cisel-lab.ch/OAB ExternalUrl https://mail.cisel-lab.ch/OAB
Get-WebServicesVirtualDirectory|Set-WebServicesVirtualDirectory -InternalUrl https://mail.cisel-lab.ch/EWS/Exchange.asmx -ExternalUrl

https://mail.cisel-lab.ch/EWS/Exchange.asmx
Get-EcpVirtualDirectory|Set-EcpVirtualDirectory -InternalUrl https://mail.cisel-lab.ch/ecp -ExternalUrl https://mail.cisel-lab.ch/ecp
Get-OwaVirtualDirectory|Set-OwaVirtualDirectory -InternalUrl https://mail.cisel-lab.ch/owa -ExternalUrl https://mail.cisel-lab.ch/owa
Get-ActiveSyncVirtualDirectory|Set-ActiveSyncVirtualDirectory -InternalUrl https://mail.cisel-lab.ch/Microsoft-Server-ActiveSync -

ExternalUrl https://mail.cisel-lab.ch/Microsoft-Server-ActiveSync
Get-ClientAccessServer|Set-ClientAccessServer -AutodiscoverServiceInternalUri https://mail.cisel-lab.ch/Autodiscover/Autodiscover.xml

Voici le rôle de différents répertoires virtuels qui sont tous accessible en HTTPS :
• Autodiscover permet la configuration automatique d’Outlook

• Outlook Anywhere permet la synchronisation d’Outlook (y compris à l’extérieur du LAN)
• ActiveSync permet la synchronisation des Smartphones
• ECP permet la configuration du serveur Exchange
• OWA permet l’accès à la messagerie via un navigateur web
Il faut également créer un enregistrement sur notre DNS public afin que l’autodiscover fonctionne
depuis l’externe. Lors de l’utilisation d’Outlook depuis le réseau interne, Outlook va se connecter au
contrôleur de domaine pour obtenir les informations sur l’autodiscover et ainsi se connecter au
serveur Exchange. Depuis l’externe, Outlook va envoyer une requête DNS sur le nom de domaine mail-
cisel-lab.ch et grâce à l’enregistrement « SRV » ci-dessous, il aura les informations pour joindre
l’autodiscover.
Voici donc l’entrée qu’il faut ajouter dans le DNS public :
Figure 6-166 | Infoblox entrée DNS pour autodiscover
6.8.5. Création du certificat
Nous avons besoin d’un certificat délivré par une autorité de certification afin de pouvoir utiliser nos
services Exchange depuis l’externe. Nous allons donc faire une demande de certificat chez Comodo qui
délivre gratuitement un certificat pour 90 jours. Pour la demande de certificat, il faut générer un
« certifcat request » via Exchange. Ci-dessous la ligne de commander à exécuter depuis la console
Powershell Exchange, la ligne permettant de générer une clé privée et un crt pour le FQDN mail.cisel-
lab.ch :
Set-Content -path "C:\svexcloud02.csr" -Value (New-ExchangeCertificate -GenerateRequest -KeySize

2048 -SubjectName "c=CH, s=Fribourg, l=Matran, o=cisel-lab, cn=mail.cisel-lab.ch" -
PrivateKeyExportable $True)
Ensuite il faut copier-coller la chaine de caractères que contient le fichier csr dans le formulaire de
comodo :
Figure 6-167 | Certificat SSL demande chez Comodo

Pour vérifier par la suite que le nom de domaine est bien légitime, il faut choisir une adresse email
sur laquelle Comodo va envoyer un mail avec un lien pour valider que nous gérons bien ce nom de
domaine. J’ai indiqué l’adresse admin@cisel-lab.ch comme adresse email de vérification. Cependant
nous n’avons pas encore créé de connecteur de réception sur notre serveur exchange afin de
recevoir des mails depuis l’externe.
6.8.6. Configuration du connecteur de réception
Nous allons utiliser Le Default frontend écoute sur le port 25 pour recevoir nos emails. Il faut donc
sélectionner et éditer les paramètres :
Figure 6-168 | Exchange création connecteur de réception
Il faut supprimer l’option ci-dessous dans les paramètres du « Default Frontend »
Figure 6-169 | Exchange configuration connecteur de réception

On peut ainsi spécifier notre FQDN mail.cisel-lab.ch pour notre connecteur de réception :
Figure 6-170 | Exchange configuration adresse FQDN du connecteur de réception
Il faut maintenant configurer nos entrées A et AAAA sur notre DNS public. Pour cela, nous allons
temporairement utiliser l’adresse IPv4 public 195.141.249.224 qui était réservée pour notre Proxy. En
effet par la suite, pour des raisons de sécurité, le flux va passer par le Proxy mais comme il n’est pas
encore configuré, nous allons déjà effectuer le test sans passer par le Proxy.
Figure 6-171 | Infoblox DNS public création entrées A et AAAA pour serveur Exchange
Pour configurer notre connecteur de réception, il faut également définir l’entrée MX (Mail
eXchanger). Cette entrée permet le routage des emails sur internet. Voici donc notre entrée MX:
Figure 6-172 | Infoblox DNS public création du MX pour le routage d’email

Il faut maintenant configurer le NAT de l’adresse public 195.141.249.224 vers l’adresse IPv4 privée du
serveur exchange :
Figure 6-173 | PALO ALTO règle de NAT pour mail.cisel-lab.ch
Et supprimer l’adresse du serveur exchange dans le NAT que nous avions configurée pour l’accès à
Internet :
Figure 6-174 | PALO ALTO modification règle de NAT pour accès vers l’externe
Également ajouter une règle pour accepter le port 25 de l’externe vers notre serveur Exchange
Figure 6-175 | PALO ALTO règle pour port 25 SMTP
Il faut également créer la règle sur le Fortigate pour IPv4 et IPv6 :
Figure 6-176 | Fortigate règle pour port 25 SMTP
Figure 6-177 | Fortigate règle pour port 25 SMTP
Voici donc le mail reçu pour confirmation de notre FQDN mail.cisel-lab.ch après configuration du
connecteur de réception :

Figure 6-178 | Certificat SSL réception de la validation du certificat
6.8.7. Installation du certificat
Après réception du mail de Comodo, j’ai pu télécharger le certificat. Il est nécessaire d’installer le
certificat sur notre serveur exchange. Pour cela il faut le copier dans un répertoire et lancer la
commande depuis la console PowerShell du serveur Exchange :
Figure 6-179 | Exchange installation du certificat
Ensuite il faut activer le certificat pour nos services exchange :
Figure 6-180 | Exchange activation du certificat
Il est maintenant possible de tester la connexion au serveur exchange en Dual-Stack. Les données
entre le client et le serveur seront cryptées par le certificat.

6.9. Installation du réseau client de test

Hurricane Electric permet de configurer un tunnel ipv6 à partir d’un accès IPv4. Il est donc possible
d’avoir une configuration Dual-Stack grâce à ce service. Voici donc notre réseau client de test :
Figure 6-181 | Test client schéma réseau

6.9.1. Création du Tunnel
Une fois connecté sur le site de tunnelbroker, créer le tunnel de la manière suivante : entrer l’adresse
IP public et cliquer sur « Create Tunnel » :
Figure 6-182 | HE création du tunnel
Nous avons ensuite les informations pour configurer notre firewall :
Figure 6-183 | HE informations tunnel
6.9.2. Configuration du firewall
Il s’agit d’un firewall SonicWALL TZ 215 qui est configuré sur l’accès internet de test pour CISEL. Le
firewall est donc déjà configuré en IPv4. Il faut donc maintenant configurer la partie IPv6 sur le firewall.
Il faut configurer l’interface « Tunnel » pour la connexion vers TunnelBroker :
Figure 6-184 | SonicWALL configuration tunnel

Figure 6-185 | SonicWALL configuration interface tunnel
Il faut entrer l’adresse fournie par TunnelBroker :
Figure 6-186 | SonicWALL configuration des paramètres pour l’interface tunnel
Il faut également configurer notre port X0 sur lequel sera notre poste de test :
Figure 6-187 | SonicWALL configuration de l’interface LAN
Nous activons l’écoute des messages « Routeur Advertisement » afin de répondre aux requêtes qui
proviennent des équipements connectés sur le réseau lan :
Figure 6-188 | SonicWALL configuration Routeur Advertisement

On active donc les messages « Router Advertisement »
Figure 6-189 | SonicWALL configuration Routeur Advertisement
Il faut également spécifier le préfixe afin que le poste de travail de test puisse recevoir une adresse
IPv6 automatiquement :
Figure 6-190 | SonicWALL configuration du préfixe
Pour finir, il faut créer les règles afin de permettre le flux IPv6 :
Figure 6-191 | SonicWALL configuration des règles

6.9.3. Validation sur poste de test client
On peut maintenant valider que notre poste de test soit bien configuré en Dual-Stack et qu’il puisse
bien résoudre des noms de domaines en IPv6. Tout d’abord on peut vérifier sa configuration réseau :
Figure 6-192 | Réseau client vérification configuration Dual-Stack
On constate que nous avons deux adresses IPv6, une temporaire et une adresse préférée. Elle sont
bien les deux le block fourni par TunelBroker, c’est à dire 2001:470:26:16d::/64. L’adresse temporaire
est utilisée pour attribuer une adresse préférée aléatoire. Elle ne se base donc pas sur l’adresse MAC
et ceci pour garder l’anonymat sur internet, voir RFC 3041.
Test de Ping en IPv4 et en IPv6
Figure 6-193 | Réseau client vérification ping IPv4 et IPv6

6.10. Installation du « Reverse-Proxy » pour Exchange

Nous pouvons maintenant passer à l’installation et la configuration du Proxy pour le serveur Exchange.
Ceci nous permettra de valider le fonctionnement de notre Proxy de production qui tourne sur Ubuntu
16.04 LTS avec HAPROXY version 1.6.3. Pour cela j’ai à disposition une machine virtuelle déjà
préconfigurée en format ova, avec la bonne version des logiciels. Il faut donc, dans un premier temps,
importer la machine virtuelle sur notre ESX. Pour cela il faut aller dans le menu suivant :
Figure 6-194 | Reverse-Proxy dépoiment
Puise renseigner sur la location du fichier ova :
Figure 6-195 | Reverse-Proxy installation
Et donner un nom à notre serveur :
I
Figure 6-196 | Reverse-Proxy installation

Il faut également définir les cartes réseau que l’on veut utiliser. Dans notre cas, nous aurons besoin
d’une carte réseau dans la zone PROXY_PUB et une autre dans la zone PROXY_PRIV qui fera le lien vers
le serveur Exchange. Je vais également définir une interface sur le vlan de management afin de pouvoir
me connecter au serveur en ssh.
Figure 6-197 | Reverse-Proxy configuration VLAN
Une fois la machine démarrée, on peut y accéder via la console depuis Vsphere. Il est également
possible d’y accéder en ssh en éditant le fichier de configuration de ssh. Pour cela il faut taper la
commande « nano /etc/ssh/sshd_config ».
Il faut ensuite spécifier sur quelle adresse IP on veut se connecter :
ListenAddress 172.20.70.9
Après avoir configuré les interfaces réseau, on peut se connecter au serveur depuis un client ssh
comme putty par exemple.
6.10.1. Configuration des interfaces
Il faut ensuite procéder à la configuration des interfaces réseau. Pour afficher le nom des interfaces
réseau sur notre serveur linux, on peut taper la commande « ifconfig ». La commande nous retourne
le nom des interfaces :
Ens192 Management
Ens224 Proxy_pub
Ens256 Proxy_priv
Tableau 6-2 | Reverse-Proxy interfaces
On peut donc passer à la configuration des interfaces en éditant le fichier « interfaces » :
nano /etc/network/interfaces
6.10.2. Configuration de l’interface de management

Dans un premier temps, on configure l’adresse de management afin de pouvoir se connecter en ssh
sur le Proxy depuis notre poste de test qui se trouve dans le réseau cisel-lab. On configure donc
l’adresse IPv4 et le masque. Ensuite, à l’aide de la commande post-up qui permet d’exécuter une

commande après démarrage du serveur, on ajoute une route qui définit la passerelle de réseau
management. On ajoute également une route pour le réseau cisel-lab.
auto ens192
iface ens192 inet static
address 172.20.70.9
netmask 255.255.255.240
post-up route add -net 172.20.70.0 netmask 255.255.255.240 gw 172.20.70.1
6.10.3. Configuration de l’interface Proxy_pub

Pour notre interface réseau dans Proxy_pub on va définir l’adresse, le masque et la gateway en IPv4.
Sur cette interface on peut définir directement la gateway car il s’agit de la carte réseau qui va
communiquer avec Internet. Avec les commandes post-up, on configure l’adresse IPv6 ainsi que son
préfixe, on ajoute une route par défaut pour définir sa Gateway. Enfin, on ajoute une route pour
définissant que pour atteindre le réseau cisel-cloud en IPv4, il faut passer par l’interface Proxy_priv du
PALO ALTO.
auto ens224
address 172.20.70.82
netmask 255.255.255.240
gateway 172.20.70.81
post-up ip -6 addr add 2001:678:204:2680::5/64 dev ens224
post-up ip -6 route add default via 2001:678:204:2680::1
6.10.4. Configuration de l’interface Proxy_priv

Pour notre interface réseau dans Proxy_priv, on va définir l’adresse et le masque en IPv4. Avec la
commande post-up, on configure l’adresse IPv6 ainsi que son préfixe. On configure ensuite une route
par défaut pour définir sa Gateway qui est l’interface Proxy_priv du PALO ALTO. On déclare également
une table101, ceci permettant de définir à l’aide des deux règles que si le paquet provient ou est
destiné au réseau Cisel_cloud en IPv6, il sera traité par la default gateway du réseau Proxy_priv.
auto ens256
address 172.20.70.98
netmask 255.255.255.240
post-up ip -6 addr add 2001:678:204:2690::5/64 dev ens256
post-up ip -6 route add default via 2001:678:204:2690::1 dev ens256 table 101
post-up ip -6 rule add from 2001:678:204:2390::/64 lookup 101
post-up ip -6 rule add to 2001:678:204:2390::/64 lookup 101

6.10.5. Configuration du HAPROXY
Le Proxy est utilisé pour terminer le flux TCP via le port 443 (HTTPS). On peut dire qu’il s’agit d’un
« reverse Proxy » car il configuré pour établir un lien entre le réseau externe (internet) et le réseau
local. C’est donc lui qui va rediriger le flux TCP vers le service cloud. Il est important de comprendre
qu’il ne redirige pas seulement le flux. En effet, il établit une connexion TCP depuis son interface
Proxy_pub avec l’externe et crée un nouveau flux TCP depuis son interface Proxy_priv vers le serveur
exchange. Comme la communication est cryptée, il faut importer le certificat ainsi que la clé primaire
sur le Proxy pour qu’il puisse crypter lui aussi la communication avec le serveur exchange, sans quoi la
connexion sera rejetée par le serveur. Voici donc un schéma qui représente le fonctionnement de notre
Proxy :
Figure 6-198 | HAPROXY schéma de fonctionnement
Il est important de signaler que pour des raisons de sécurité, nous avons sur le réseau de production,
un serveur Exchange qui fait relais dans une DMZ externe. Ceci pour éviter les connexions depuis
l’externe sur le serveur Exchange. Pour notre labo cet aspect n’est pas important car nous voulons
uniquement valider la compatibilité d’une configuration Dual-Stack. Cependant, Il ne faudrait pas avoir
ce type de configuration pour une installation à long terme.

Voici la commande pour accéder à la configuration de HAPROXY :
nano /etc/haProxy/haProxy.cfg
Ci-dessous la configuration à effectuer afin d’écouter sur le port 443 en IPv4 et IPv6. On donne
également le chemin du certificat en format pem. Celui-ci doit contenir le certificat délivré par Comodo
ainsi que le certificat intermédiaire et la clé privée. Dans la dernière ligne, on renseigne l’adresse IPv4,
IPv6 du serveur exchange afin d’ouvrir le flux TCP.
listen CLOUD_MAIL_HTTP_V6
bind 2001:678:204:2680::5:443 defer-accept ssl crt /etc/haProxy/ssl/mail.cisel-lab.ch.full.pem
mode http
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
server SRVEX002Adiscoverv6 2001:678:204:2390::7:443 ssl
listen CLOUD_MAIL_HTTP_V4
bind 172.20.70.82:443 defer-accept ssl crt /etc/haProxy/ssl/mail.cisel-lab.ch.full.pem
mode http
server SRVEX002Adiscoverv4 172.20.70.20:443 ssl
6.10.6. Génération du certificat au format pem

Il faut récupérer la clé primaire que nous avions générée depuis le serveur Exchange. Pour cela il faut
créer une console MMC et ajouter le « snap-in » « certificates » et sélectionner « Computer Account ».
Ensuite exporter le certificat :
Figure 6-199 | Exchange récupération clé privée

Exporter également la clé privée :
Figure 6-200 | Exchange exportation clé privée
Pour finir, il faut définir un mot de passe et sélectionner l’endroit où on veut stocker le fichier exporté
au format pfx. On peut maintenant transférer ce fichier ainsi que le certificat et également le certificat
intermédiaire fourni par COMDO. Voici donc les trois fichiers sur le Proxy :
Figure 6-201 | Reverse-Proxy copie certificats
La première commande ci-dessous permet de générer le certificat. Comme nous l’avons déjà, nous
n’avons pas besoin d’exécuter cette commande. La deuxième commande permet d’extraire la clé
privée. C’est donc cette commande que nous allons exécuter. Il faut également entrer le mot de passe
que nous avions défini lors de l’export.
openssl pkcs12 -in key.pfx -out newfile.crt.pem -clcerts -nokeys

openssl pkcs12 -in key.pfx -out newfile.key.pem -nocerts -nodes
Figure 6-202| Reverse-Proxy extraction clé privée
On peut maintenant générer notre certificat mail.cisel-lab.ch.full.pem avec la commande cat qui
permet de concaténer des fichiers :
cat mail_cisel-lab.crt INtermediaire.crt newfile.key.pem > mail.cisel-lab.ch.full.pem
Figure 6-203| Reverse-Proxy création du certificat .pem
Une fois le certificat placé dans le répertoire /etc/haProxy/ssl/ on peut redémarrer le serveur. La
configuration du Proxy est terminée.

6.11. Installation du Serveur CISSYNC

Le service CISSYNC permet la synchronisation de fichiers depuis son poste de travail sur un serveur
distant. Le service repose principalement sur un client à installer, on peut ensuite sélectionner les
répertoires qu’on veut synchroniser sur le serveur distant. On peut le comparer au service cloud
Dropbox. Il a cependant l’avantage d’avoir son stockage centralisé sur des serveurs locaux et non à
l’étranger. Dans notre réseau de production, le stockage repose sur nos SAN. Dans notre POC le
stockage sera effectué en local sur le serveur. Signalons également un point important : lors de la pré-
étude, j’avais placé le serveur dans la zone Cisel-cloud. Après avoir approfondi mes recherches, j’ai pu
remarquer que le service Cissync de production se trouve dans une zone externe, c’est-à-dire sur notre
PALO ALTO. Je vais donc corriger cela dans mon travail de diplôme et placer le serveur dans la zone
Proxy_pub. En effet pour des raisons de sécurité, il est impératif de placer le serveur sur une DMZ
externe car il y aura un accès direct depuis l’externe. Le service intègre également une interface web
d’administration et de gestion du stockage pour les utilisateurs. Il faudra donc une adresse public IPv4
pour l’accès du logiciel client de synchronisation et une autre adresse pour l’accès web.
Une commande auprès de notre fournisseur Numvision a été nécessaire pour obtenir la configuration
d’un nouveau serveur CISSYNC. Le fournisseur n’a jamais eu de projet en IPv6, c’est donc également
intéressant pour lui de connaître sa compatibilité avec le mode Dual-Stack.
6.11.1. Préparation du serveur Linux
J’ai tout d’abord dû installer un serveur linux « SVCISSYNC » et configurer un accès SSH afin de
permettre au support Numvision de paramétrer le serveur CISSYNC. J’ai donc repris mon linux de base
contenu dans mon fichier ova et j’ai ajouté la machine virtuelle sur mon Server ESX. J’ai ajouté deux
cartes réseau sur le serveur, une pour l’accès web et l’autre pour le client de synchronisation :
Figure 6-204 | CISSYNC configuration VLAN
Il faut ensuite créer deux entrées sur notre DNS public, pour le serveur WEB : cissync.cisel-lab.ch et
pour le logiciel de synchronisation : syncfile.cisel-lab.ch :

Figure 6-205 | Infoblox DNS public entrées CISSYNC
Il est nécessaire de configurer notre Firewall PALO ALTO afin d’effectuer le NAT pour les adresses
IPv4 et les règles pour l’accès au serveur depuis l’externe. Voici donc le premier NAT pour l’accès
web :
Figure 6-206 | PALO ALTO configuration NAT cissync
Voici le Nat pour l’accès logiciel de synchronisation :
Figure 6-207 | PALO ALTO configuration NAT syncfile
Le support Numvision m’a également demandé d’ouvrir un certain nombre de ports pour l’accès au
serveur Cissync. J’ai donc créé une règle pour autoriser les adresses IPv4 publics de Numvision ainsi
que les adresses IPv4 publics et IPv6 de notre réseau de test client vers le serveur Cissync avec les
ports demandés par Numvision. Voici donc la règle :
Figure 6-208 | PALO ALTO règle pour CISSYNC
6.11.2. Configuration des interfaces réseaux

Voici donc la configuration des deux interfaces :
auto ens192
address 172.20.70.83
netmask 255.255.255.240
gateway 172.20.70.81
iface ens192 inet6 static

address 2001:678:204:2680::10
netmask 64
gateway 2001:678:204:2680::1

post-up ip -6 addr add 2001:678:204:2680::11/64 dev $IFACE
auto ens256:0
iface ens256:0 inet static
address 172.20.70.84
netmask 255.255.255.240
gateway 172.20.70.81
Après avoir configuré l’accès SSH pour écouter sur l’adresse 172.20.70.83, le support NumVision a pu
se connecter au serveur et établir les configurations nécessaires.
6.11.3. Création du certificat
Il faut également créer un certificat pour la connexion sur l’accès web cissync-cisel-lab.ch. L’accès pour
le client syncfile.cisel-lab.ch se base également sur ce certificat afin de crypter la connexion. J’ai donc
créé une clé privée et une une requête de signature depuis le site internet www.trustico.fr :
Figure 6-209| Certificat SSL pour CISSYNC
Par la suite, à l’aide de la requête, j’ai pu effectuer une demande de certificat pour une durée de 30
jours sur le site www.geotrust.com. Une fois l’adresse email admin@cisel-lab.ch validée, j’ai reçu le
certificat ainsi que le certificat intermédiaire par email. J’ai donc fourni ces deux certificats ainsi que la
clé privée à Numvision pour qu’il puisse l’installer sur le serveur CISSYNC.
Figure 6-210| Certificat SSL pour CISSYNC validé

7.Validation du service Cloud Exchange

7.1. Ajustement de la configuration
Il nous manque encore quelques configurations afin de pouvoir exécuter nos tests. Dans un premier
temps, il faut corriger l’entrée DNS mail.cisel-lab.ch pour l’entrée AAAA que nous avions définie avec
l’adresse du serveur Exchange. Comme nous voulons faire passer le flux par le Proxy, il faut définir
l’adresse du Proxy_pub pour l’enregistrement DNS :
Figure 7-1 | Infoblox DNS public modification entrée mail.cisel-lab.ch IPv6
Il faut par la suite modifier notre règle de NAT sur le PALO ALTO ; en effet l’adresse IP public
195.141.249.224 qui correspond à notre entrée A pour mail.cisel-lab.ch sur notre DNS est configurée
en « NAT » avec l’IP de notre serveur exchange. Il faut donc effectuer le NAT sur le Proxy_pub :
Voici l’entrée DNS :
Figure 7-2| Infoblox DNS public entrée mail.cisel-lab.ch IPv4
La règle de Nat sur le PALO ALTO :
Figure 7-3 | PALO ALTO modification NAT pour mail.cisel-lab.ch
Il faut également configurer les règles sur le PALO ALTO et le Fortigate. Comme nous l’avons vu
précédemment, Exchange utilise le port 443 pour la connexion entre le client et le serveur Exchange.
Sur le PALO ALTO on doit donc créer une règle qui accepte le flux https ou ssl (port TCP 443) depuis
l’externe vers les adresses IPv4 et IPv6 du Proxy :
Figure 7-4 | PALO ALTO règle Proxy_pub
Nous devons encore ajouter une règle qui permet le flux entre Proxy_priv et inside. En effet le Reverse-
Proxy ouvre un nouveau flux TCP depuis l’interface Proxy_priv :
Figure 7-5 | PALO ALTO règle Proxy_priv

Il faut également créer une règle sur le Fortigate qui accepte le flux ssl de l’adresse IP du Proxy_priv
vers le serveur Exchange :
Figure 7-6 | Fortigate règle accès serveur Exchange IPv4
Même chose pour IPv6 :
Figure 7-7 | Fortigate règle accès serveur Exchange IPv6
7.2. Test d’accès configuration Dual-Stack

Nous effectuons donc le test depuis un poste qui se trouve connecté sur le réseau de test client. Voici
donc la configuration de sa carte réseau :
Figure 7-8 | PC client configuration
Configuration d’Outlook :
Figure 7-9 | PC client configuration Outlook

La configuration a bien été effectuée sur le client Outlook
Figure 7-10 | PC client validation Outlook
Notre client Outlook est donc configuré :
Figure 7-11 | PC client validation affichage Outlook
On peut afficher les logs sur le Proxy afin de s’assurer que le flux a bien été reçu en IPv6. Ci-dessous on
retrouve bien l’adresse IPv6 de notre poste de test :
Figure 7-12 | Proxy validation flux IPv6
En capturant les paquets à l’aide de wireshark sur le serveur Exchange, on peut confirmer que la
communication se fait bien en IPv6. On constate que l'adresse IPv6 source est bien celle de l'interface
Proxy_priv. On peut également constater que l'échange de clé pour crypter la communication ne se
fait pas car il a déjà été fait auparavant. C’est le mécanisme « Resume » (RFC5246) qui permet de ne
pas échanger la clé pour chaque connexion. On inclut un identifiant de session qui sera envoyé avec le
"client Hello".

Figure 7-13 | Validation service exchange WireShark
On peut retrouver le numéro de session dans WireShark :
Figure 7-14 | numéro de session dans Wireshark
Nous avons donc pu nous connecter sur notre service cloud depuis une configuration Dual-Stack. On
constate que le protocole IPv6 a été privilégié par la couche application.
7.3. Test d’accès configuration IPv4

Pour ce test je vais simplement désactiver IPv6 sur ma carte réseau et contrôler si la connexion au
serveur exchange est maintenue. On peut valider l’accès via le Webmail par exemple, ce qui nous
permettra également de nous assurer que le certificat est bien reconnu par le navigateur web.
On peut valider en effet que l’accès sur notre serveur Exchange est maintenu et qu’il n’y a plus de
message d’alerte sur le certificat :
Figure 7-15 | Exchange Validation accès IPv4 et certificat

On constate également que dans les logs du Proxy on retrouve l’IPv4 public de notre réseau test client :
Figure 7-16 | Proxy validation accès IPv4 sur service Exchange
7.4. Test d’accès configuration IPv4 avec NAT64

Nous allons maintenant configurer le NAT64 sur notre firewall PALO ALTO afin de confirmer que si IPv4
est désactivée sur le Service Cloud, il est possible depuis un poste client possédant une connexion IPv4
de pouvoir s’y connecter. NAT64 permet grâce à la translation d’adresse IPv4 vers IPv6, de se connecter
sur une ressource configurée uniquement en IPv6 depuis une machine configurée en IPv4. Il faut donc
créer la règle NAT64 sur notre PALO ALTO :
Figure 7-17 | PALO ALTO NAT64 création
Notre entrée « A record » sur notre DNS public pour l’accès à notre service exchange mail.cisel-lab.ch
pointe sur l’IP 195.141.249.224. C’est donc cette adresse IPv4 qu’il faut convertir en IPv6. Sur notre
PALO on spécifie donc que tout paquet qui provient de l’externe avec l’adresse IP de destination
195.141.249.224 doit être converti avec l’adresse IPv6 de notre Proxy_pub, autrement dit
195.141.249.224 est convertie en 2001:678:204:2680::5. Pour compléter le paquet il faut également
convertir l’adresse IP source. La RFC 6052 stipule qu’il faut utiliser le préfixe 64:ff9b::/96 pour effectuer
la translation d’adresse IPv4 vers IPv6.
Figure 7-18 | PALO ALTO configuration du NAT64
Il faut ensuite supprimer la règle de NAT que nous avions créée pour notre service exchange en IPv4.
Figure 7-19 | PALO ALTO suppression règle de NAT

Il faut également ajouter une route pour que le PALO ALTO redirige les paquets vers le NAT64
Figure 7-20 | PALO ALTO route static pour NAT64
On peut donc maintenant désactiver IPv4 sur notre serveur exchange et désactiver IPv6 sur notre poste
de test qui se trouve sur notre réseau de test client. Voici donc le résultat dans les logs du Proxy quand
on se connecte sur Outlook avec succès :
Figure 7-21 | Validation NAT64 sur log PROXY
On peut confirmer que l’adresse source à bien été convertie avec le préfixe 64:ff9b::/96. Le dernier
32 bits de l’adresse 555a:418 correspondent donc à l’adresse IPv4 du public de notre réseau de test
qui est 85.90.4.24. Voici donc comment la conversion est effectuée :
• 85 décimal -> 55 hexadécimal

• 90 décimal -> 5a hexadécimal
On peut également voir dans le log du PALO ALTO que le NAT64 est bien effectué :
Figure 7-22 | PALO ALTO validation NAT64
7.5. Transfert flux IPv4 vers IPv6 depuis HAPROXY

L’application HAPROXY permet également d’assurer une connexion sur une ressource configurée en
IPv6 depuis un poste client configuré en IPv4 sans configurer de NAT64. Voici donc un exemple : dans
un premier temps on désactive le NAT64, on réactive la règle de NAT pour notre serveur exchange et
on peut également supprimer la route vers l’adresse 195.141.249.224.
On laisse IPv6 désactivé sur le poste de test et on réactive IPv4 sur notre serveur Exchange. Ensuite si
on se reconnecte sur Outlook depuis le poste de test, on peut confirmer avec les logs du Proxy que la
connexion se fait bien en IPv4 :

Figure 7-23 | Validation connexion IPv4 depuis PC client
On va donc maintenant modifier la configuration de notre Proxy pour rediriger le flux provenant
d’adresses IPv4 vers l’adresse du serveur en IPv6 :
listen CLOUD_MAIL_HTTP_V4_REDIRECTV6
bind 172.20.70.82:443 defer-accept ssl crt /etc/haProxy/ssl/mail.cisel-lab.ch.full.pem
mode http
server SRVEX002Adiscover_IPv6 2001:678:204:2390::7:443 ssl
Après le redémarrage sur Proxy, on désactive IPv4 sur le serveur Exchange afin de s’assurer que la
communication se fait bien en IPv6 entre le Proxy et le serveur Exchange. Voici donc les logs du Proxy
après s’être connecté sur exchange avec succès :
Figure 7-24 | Validation communication IPv6 entre Proxy et serveur Exchange
Le flux arrive donc bien en IPv4 et il est redirigé en IPv6 sur le serveur Exchange. Cela fonctionne car le
flux est fermé et ré-ouvert depuis l’interface Proxy_priv qui possède une adresse Dual-Stack. La
communication entre le Proxy et le serveur sera donc faite entre l’adresse IPv6 de l’interface Porxy-
priv du Proxy et l’adresse IPv6 sur Serveur exchange.
7.6. Conclusion des tests

Pour conclure on peut confirmer que notre service cloud Exchange est accessible en Dual-Stack. J’ai
également effectué les tests de connexion depuis le poste interne et je n’ai pas rencontré de problème.
Le NAT64 a également été validé ainsi que le transfert de flux IPv4 vers IPv6 depuis HAPROXY. Ceci
nous offre la possibilité à terme de n’avoir qu’une configuration uniquement en IPv6 sur notre service
cloud. Si des clients se connectent depuis une adresse IPv4 la conversion IPv4/IPv6 sera assurée par le
PALO ALTO. Il sera par contre toujours nécessaire de conserver notre entrée de type « A record » dans
notre DNS afin d’être redirigé sur notre PALO ALTO. Cela veut donc dire qu’une adresse publique IPv4
sera nécessaire tant qu’on désire assurer l’accès depuis des clients connectés en IPv4.

8.Validation du service CISSYNC

Comme ça a été le cas pour la validation du service Exchange, nous allons effectuer les tests depuis
notre poste qui se trouve dans le réseau test client.
8.1. Test d’accès configuration Dual-Stack
8.1.1. Accès au service web
On peut donc valider l’accès à l’interface web de management du service cloud en IPv6 ; comme on
peut le voir ci-dessous, on arrive bien à afficher la page web :
Figure 8-1 | CISSYNC validation accès web IPv6
Pour s’assurer que la connexion est bien établie en IPv6, dans le menu on peut afficher les adresses
IPv6 connectées :
Figure 8-2 | CISSYNC confirmation accès web IPv6
On constate donc que l’adresse est bien au format IPv6 et qu’elle appartient à notre bloc IPv6 attribué
à notre réseau client qui est le 2001:470:26:16d::/64. Cela valide donc que la connexion au serveur
CISSYNC s’effectue bien en IPv6.
On peut également voir sur la capture wirehsark ci-dessous que la communication entre le serveur et
le poste de travail s’effectue bien en IPv6. On retrouve également l’adresse IPv6 du serveur
2001:678:204:2680::10. La capture a été effectuée sur le poste client :

Figure 8-3 | CISSYNC validation accès IPv6 WireShark
8.1.1. Accès à la synchronisation de fichier
Une fois le client installé, on peut contrôler dans l’onglet « Activités » que les synchronisations se sont
déroulées correctement :
Figure 8-4 | CISSYNC validation client accès IPv6
Comme on peut le voir, la synchronisation s’effectue, on peut donc valider avec les captures wireshark
que la communication se fait bien en IPv6 :
Figure 8-5 | CISSYNC validation client accès IPv6 WireShark
On retrouve donc bien notre bloc IPv6 client ainsi que l’adresse 2001:678:204:2680::10 qui correspond
bien à l’adresse de synchronisation cissync.cisel-lab.ch.

On peut également voir en se connectant en ssh sur le serveur CISSYNC, dans les logs de
synchronisation, l’adresse IP du client :
Figure 8-6 | CISSYNC validation client accès IPv6 log syncfile
8.2. Test d’accès configuration IPv4

Il faut maintenant également valider que les deux services soient accessibles en IPv4.
8.2.1. Accès au service web
Comme on peut le voir ci-dessous, on accède bien à l’interface web en IPv4, on retrouve l’adresse IPv4
public dans les logs du serveur :
Figure 8-7 | CISSYNC validation accès IPv4 interface web
8.2.2. Accès au service de synchronisation
On valide également la connexion au serveur de synchronisation comme on peut le voir ci-dessous :
Figure 8-8 | CISSYNC validation client accès IPv4 log syncfile

8.3. Conclusion des tests

Pour conclure on peut confirmer que notre service Cloud CISSYNC est accessible en Dual-Stack. J’ai
également effectué les tests de connexion depuis le poste interne et je n’ai pas rencontré de problème.
Le NAT64 avait déjà été validé avec sur le service Exchange. Je ne l’ai donc pas testé pour ce service
Cloud car c’était le PALO ALTO qui devait être validé pour cette technologie. En effet, côté serveur s’il
est accessible en IPv6, le nat64 ne pose aucun problème.
9.Validation des switch layer 3

Comme précisé lors de la pré-étude, nous n’avons pas pu intégrer nos switch layer 3 dans notre réseau
de simulations. Il est donc important de valider qu’ils soient compatibles avec IPv6 en effectuant des
recherches sur le site du fabricant en fonction de la version d’os installé. Nos deux switch layer 3 sont
connectés sur nos ESX afin de transmettre notamment le flux de nos services Cloud. On peut dire qu’ils
ont le même rôle que notre switch SW01, c’est-à-dire transmettre le flux sur notre PALO ALTO pour
les zones externes et sur le Fortigate pour les zones internes.
9.1. Nexus 5548

Il s’agit du switch qui transmet le flux des vlan internes, il est donc connecté sur le Fortigate. Il est
installé avec la version OS 5.1(3)N2(1a). Après investigation, ce switch est utilisé avec un mode de
fonctionnement layer 2 pour la partie ESX. Il n’y a pas de routage. Dans un premier temps il n’y aurait
donc pas de problème à faire passer du flux IPv6 sur ce switch. Il faudrait cependant passer à la dernière
version de l’OS pour bénéficier des dernières implémentations liées à IPv6.
9.2. Cisco 3750-X

Il s’agit du switch qui transmet le flux des vlan externes, il est donc connecté sur le PALO ALTO. Il est
installé avec la version OS 15.0(2)SE4. Comme c’est le cas pour le Nexus, ce switch est utilisé dans un
mode de fonctionnement layer 2 pour la partie ESX, il n’y a pas de routage. On peut cependant sans
problème activer IPv6 sur les interfaces et configurer du routage IPv6 dans la version actuelle. J’ai
constaté que certaines personnes avaient remonté des problèmes avec le MLD snooping24 actif sur les
switch layer 2. Ce qui bloc certaines communications multicast. Il faudra donc faire attention à ce point
car le multicast est indispensable avec IPv6.
24
Source: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-
2_53_se/configuration/guide/3750xscg/swv6mld.html

10. Evaluation de la plateforme Infoblox

Comme on a pu le voir la plateforme Infoblox apporte une gestion centralisée des services DNS, DHCP
et IPAM. J’ai trouvé l’interface difficile à prendre en main et pas très intuitif au début, comme par
exemple le fait que nous devions ajouter le « grid master » à chaque création sous-réseau. Par la suite,
une fois l’outil maitrisé, il devient plus clair à gérer et offre beaucoup de fonctionnalités. Je n’ai pas eu
le temps de tester toutes les fonctionnalités mais dans l’ensemble il me parait être un outil abouti avec
lequel je n’ai pas spécialement rencontré de problème. J’ai tout de même eu un souci avec le lien entre
le serveur Active Directory et le DNS car il y avait un décalage entre le moment où la machine était
jointe au domaine et la création des entrées A et AAAA dans le DNS. Il faudra également faire attention
à l’aspect sécurité si Infoblox est intégré au réseau de production, avec en priorité la mise en place de
l’authentification GSS-TSIG pour effectuer des mises à jour DNS et ne pas accepter des mises à jour
non signées.
Le service IPAM est à mon avis indispensable pour gérer les adresses IPv6. La solution proposée pour
Infoblox est conviviale, on retrouve rapidement nos adresses. On peut également générer directement
des entrées DNS ou des réservations sur celle-ci sans devoir taper toute l’adresse. Il faut cependant
connaitre DUID de la carte réseau pour établir une réservation d’adresse, ce qui peut être contraignant
pour les imprimantes par exemple. Ceci n’est cependant pas lié à l’utilisation d’Infoblox mais au
protocole IPv6.
Nous avons aussi pu constater que la plateforme permet de gérer à la fois un DNS privé et un DNS
public. Cela se configure via les vue DNS et permet de définir une carte réseau par vue. La mise en
place de ces vues n’a également pas été facile, j’ai dû avoir recours aux supports qui ont également
passé du temps sur ce problème pour finalement se rendre compte que les vues n’avaient pas été
déclarées sur le Grid Master. Cela montre qu’il faut une certaine expérience pour maitriser cette
plateforme.
J’ai également pu valider le fonctionnement du DHCP pour les adresses IPv6 et IPv4. Avec le seul
problème déjà développé lors du chapitre « configuration DHCPv6 ». Il s’agit d’une option qui conserve
les attributions d’adresse même après avoir supprimé la plage d’adresse.
Au vu d’une éventuelle implémentation dans le réseau de production, il serait dans un premier temps
possible d’intégrer le DNS Infoblox en transférant les zones sur celui-ci. C’est-à-dire qu’on garderait le
DNS microsoft et Infoblox en parallèle. Afin de pouvoir évaluer plus précisément la plateforme et par
la suite préparer une migration complète vers Infoblox, également pour la partie DHCP et IPAM.
11. Prochaines étapes

Actuellement les serveurs DNS public de CISEL ne permettent pas d’ajouter des entrées de type IPv6
« AAAA ». Il faudra donc d’abord remplacer ces serveurs. A ce sujet une discussion est en cours en
interne qui devrait certainement déboucher sur une solution DNS cloud chez un provider. Il faudra
donc vérifier qu’il est possible d’ajouter des entrées pour IPv6. Si cette solution n’est pas retenue il y
a également la possibilité de migrer vers la plateforme Infoblox.

Ensuite le plan de mise en place en production suivant pourrait être suivi :
o Activation de la configuration Dual-Stack sur notre PALO ALTO

o Activation de la configuration Dual-Stack sur le service CISSYNC
o Ajout de l’enregistrement AAAA sur le DNS public pour l’adresse IPv6
o Test et validation du fonctionnement du service CISSYNC
o Validation de la compatibilité des switch Nexus 5548 et Cisco 3750x
o Eventuellement activation du NAT64 en vue d’une future désactivation de la configuration
IPV4 sur le service, attention cependant à l’accès depuis l’interne.
o Point de situation et décision de continuer ou non la migration
o Activation du Dual-Stack sur le Fortigate
o Configuration du HAPROXY sur les Proxys pour une communication Dual-Stack
o Configuration des serveurs exchange en Dual-Stack
o Ajout de l’enregistrement AAAA sur le DNS public pour l’adresse IPv6
o Test et validation du fonctionnement du service Exchange
o Test des services cloud
o Intégration des services cloud en Dual-Stack
Le plan d’action est décrit dans les grandes lignes, il faudra donc une planification plus précise. Il est
également important en parallèle de conserver le réseau de test ainsi que le réseau de test client afin
de pouvoir continuer à tester nos services Cloud en IPv6 et valider leur fonctionnement avant de passer
à leur intégration en production.
12. Conclusion
J’ai eu beaucoup de plaisir à découvrir le protocole IPv6 ainsi que les nombreux points positif liés aux
nouveautés qu’il apporte. Ce projet m’a permis de mettre en pratique ce que j’ai pu voir pendant mes
4 années de cours. En effet j’ai pu toucher à la partie système avec linux pour le Reverse Proxy et
Windows Serveur pour la partie exchange. J’ai également pu mettre en place un serveur ESX et
découvrir la plateforme Infoblox. La partie réseau m’a beaucoup intéressé avec la configuration de
deux firewalls et du routage, la création de VLAN, la création des règles de filtrage, l’utilisation du
NAT64 et tout ce qui est lié à la configuration du Dual-Stack.
La partie concept a également été une partie très intéressante. J’ai d’abord dû recueillir un maximum
d’informations sur l’infrastructure en place. Par la suite, j’ai pu établir les concepts de réseau et
d’adressage IPv6 sur la base de la configuration déjà en place chez CISEL et grâce au document fourni
par RIPE. J’ai également dû réfléchir aux besoins pour la mise en place du réseau de test, comme la
demande du bloc IPv6 ou encore le nom de domaine de test.
Le réseau de test « POC » a permis de confirmer la compatibilité des services de base (routage, DNS,
IPAM, filtrage IP, reverse Proxy) ainsi que deux des principaux services Cloud proposés par CISEL
Informatique. Le principal attrait d’IPv6 pour le mandant est de résoudre son problème de manque
d’adresse public IPv4. Il ne faut cependant pas perdre de vue que si un service doit être disponible en
Dual-Stack sur internet, il doit avoir une adresse publique IPv4. Pour Cisel, il ne serait pas envisageable
dans l’immédiat de rendre disponible un service uniquement en IPv6. En effet, cela impliquerait que
tous les clients qui si connectent devraient avoir également une configuration en IPv6. En effet, même
avec une configuration NAT64 il faut que les postes client puissent résoudre une entrée DNS en IPv4

avant d'être redirigés vers l'équipement qui va effectuer le NAT64. Il faut aussi mentionner que IPv6
permet d'éliminer le NAT, ce qui permet également une simplification pour les administrateurs réseau
et une connexion directe du client au serveur.
La mise en place d’IPv6 pour ses services Cloud permettra à Cisel d'anticiper et de montrer une image
de société dynamique et proactive. Cela nous permettra également d’avoir des connaissances
nécessaires pour établir des concepts de configuration Dual-Stack chez nos clients. Le but est donc,
dans cette logique, d’être porté vers l’avenir et montrer l’exemple à nos clients, afin qu’ils puissent
eux aussi profiter des avantage d’IPv6. Dans ce sens nous pouvons donc imaginer supprimer la
configuration en IPv4 sur nos services cloud d’ici quelques années et ainsi nous débarrasser de ce
problème récurrent de manque d’adresse.
Notre Proxy Linux permet d’apporter une solution au manque d’adresse Cisel. Il permet de ne définir
qu'une seule adresse IPv4 publique pour plusieurs entrées DNS différentes. On effectue un NAT avec
cette adresse publique et l'adresse privée de l'interface du Proxy qui se trouve dans la zone Proxy_pub.
Ensuite le flux est ré-ouvert depuis l'interface qui se trouve dans la zone Proxy_priv en fonction de l'url,
par exemple:
A-> test1.cisel-lab.ch -> 195.141.249.12
A-> test2.cisel-lab.ch -> 195.141.249.12
Si ces deux services sont accessibles via le port 443, il est possible de configurer le Proxy pour écouter
sur ce port, et en fonction du FQDN, rediriger vers une adresse IP et un port spécifique. Par exemple :
Test1.cisel-lab.ch-> redirigé vers 172.20.70.21:443
Test1.cisel-lab.ch-> redirigé vers 172.20.70.22:443
Dans mon réseau de tests, j'ai pu valider le fonctionnement du Proxy (HAPROXY) en dual-Stack. Il est
donc tout à fait envisageable d'appliquer ce mode de fonctionnement et d'économiser des adresses
IPv4 publiques tout en activant la configuration IPv6 sur nos services Cloud.
Il est également important de relever que nous n’avons pas parlé de l’aspect sécurité autour de
l’intégration d’IPv6 dans ce travail. Il faudra donc prendre en compte cet aspect important lors de la
mise en place en production afin d’éviter par exemple des attaques de type MITM (Man-In-The-
Middle).
13. Remerciements
Je souhaite dans un premier temps remercier Javier Pose de CISEL Informatique qui m’a permis
d’effectuer ce travail de Bachelor sur un sujet très intéressant et porteur pour l’avenir.
Je remercie également mes collègues Victor Torrent et Etienne Brodard qui ont pu répondre à mes
questions sur la partie réseau. Je remercie également mes collègues Frédéric Marchand pour la partie
Linux, Richard Déglise pour la partie Cloud et Yaroslaw Dafflon pour la configuration ESX.
Je remercie Sebastien Chacon de la société Eb-Qual qui m’a donné une rapide formation et du support
sur la plateforme Infoblox.

Je souhaite également remercier mon conseiller et professeur Pierre Füllemann pour m’avoir guidé et
accompagné durant les différentes parties de ce travail.
Pour conclure je remercie Catherine Seydoux pour ses corrections d’orthographe et de grammaire.
Également je remercie les personnes de mon entourage, qui m’ont épaulé dans cette période intense.

14. Listes des figures

Figure 1-1 | Logo de CISEL Informatique................................................................................................. 7
Figure 2-1 | Statistiques de l’utilisation d’IPV6 en suisse ....................................................................... 9
Figure 2-2 | entête IPv4 ........................................................................................................................ 10
Figure 2-3 | Entête IPv6......................................................................................................................... 10
Figure 2-4 | Next Header IPv6 ............................................................................................................... 11
Figure 2-5 | Format adresse IPv6 .......................................................................................................... 12
Figure 2-6 | Types d’adresses IPv6 ........................................................................................................ 13
Figure 2-7 | Structure adresse IPv6 ....................................................................................................... 14
Figure 2-8 | Exemple de plan d’adressage IPv6 .................................................................................... 15
Figure 2-9 | Options de configuration d’adresse Global Unicast .......................................................... 15
Figure 2-10 | Entête ICMPv6 ................................................................................................................. 18
Figure 2-11 | fonctionnement de Path MTU Discovery ........................................................................ 21
Figure 2-12 | Distribution d’une adresse IPv6 via SLAAC ...................................................................... 23
Figure 2-13 | Application utilisant Dual-Stack....................................................................................... 25
Figure 2-14 | requête DNS IPv6 et IPv4................................................................................................. 25
Figure 2-15 | Tunneling IPv6 over IPv4 détails...................................................................................... 26
Figure 2-16 | Tunneling IPv6 over IPv4 scénarios ................................................................................. 26
Figure 2-17 | exemple configuration de tunnel 6to4 ............................................................................ 27
Figure 2-18 | NAT64 fonctionnement ................................................................................................... 28
Figure 2-19 | Exemple complet NAT64 ................................................................................................. 28
Figure 4-1 | schéma production et réseau de test (POC) ..................................................................... 32
Figure 4-2 | schéma réseau de test (POC)............................................................................................. 33
Figure 4-3 | schéma services Cloud production .................................................................................... 34
Figure 4-4 | schéma réseau de test avec services Cloud ...................................................................... 35
Figure 4-5 | les cinq organismes régionaux (RIR) .................................................................................. 36
Figure 4-6 | Découpage des adresses IPv6............................................................................................ 36
Figure 6-1 | Schéma complet ................................................................................................................ 42
Figure 6-2 | Schéma BGP....................................................................................................................... 43
Figure 6-3 | vérification adresses IPv6 routeur ASR1001 ..................................................................... 44
Figure 6-4 | Test Ping IPv6 routeur ASR1001 ........................................................................................ 44
Figure 6-5 | Vérification route static routeur ASR1001 ........................................................................ 45
Figure 6-6 | Vérification interfaces routeur ASR1001 ........................................................................... 45
Figure 6-7 | Vérification VLAN routeur ASR1001 .................................................................................. 45
Figure 6-8 | Firewall PAL ALTO .............................................................................................................. 46
Figure 6-9 | PALO ALTO création des zones .......................................................................................... 46
Figure 6-10 | PALO ALTO zones............................................................................................................. 47
Figure 6-11 | PALO ALTO profile management ping ............................................................................. 47
Figure 6-12 | PALO ALTO profile management accès .......................................................................... 47
Figure 6-13 | PALO ALTO configuration inside ...................................................................................... 48
Figure 6-14 | PALO ALTO configuration inside IPv4 .............................................................................. 48
Figure 6-15 | PALO ALTO configuration inside IPv6 .............................................................................. 48
Figure 6-16 | PALO ALTO configuration inside profil ............................................................................ 48

Figure 6-17 | PALO ALTO configuration outside IPv4........................................................................... 49

Figure 6-18 | PALO ALTO configuration outside IPv6........................................................................... 49
Figure 6-19 | PALO ALTO configuration outside profil.......................................................................... 49
Figure 6-20 | PALO ALTO création sous-interface................................................................................. 50
Figure 6-21 | PALO ALTO DMZ .............................................................................................................. 50
Figure 6-22 | PALO ALTO création objet ............................................................................................... 50
Figure 6-23 | PALO ALTO règle de base ................................................................................................ 51
Figure 6-24 | PALO ALTO règle de NAT ................................................................................................. 51
Figure 6-25 | PALO ALTO routage static IPv4 default ........................................................................... 51
Figure 6-26 | PALO ALTO routage static IPv4 bloc interne .................................................................. 52
Figure 6-27 | PALO ALTO routage static IPv6 default ........................................................................... 52
Figure 6-28 | PALO ALTO routage static IPv6 bloc interne ................................................................... 52
Figure 6-29 | Firewall Fortigate ............................................................................................................. 53
Figure 6-30 | Fortigate upgrade path.................................................................................................... 53
Figure 6-31 | Fortigate mise à jour........................................................................................................ 53
Figure 6-32 | Fortigate restore Firmware ............................................................................................. 54
Figure 6-33 | Fortigate activation IPv6.................................................................................................. 54
Figure 6-34 | Fortigate configuration interface outside ....................................................................... 54
Figure 6-35 | Fortigate création sous-interface .................................................................................... 55
Figure 6-36 | Fortigate Interface INT_CISEL .......................................................................................... 55
Figure 6-37 | Fortigate sous-interfaces ................................................................................................. 56
Figure 6-38 | Fortigate création d'objets .............................................................................................. 56
Figure 6-39 | Fortigate exemple objet fichier de configuration ........................................................... 56
Figure 6-40 | Fortigate création de règle IPv4 ...................................................................................... 57
Figure 6-41 | Fortigate règle IPv4 de base ............................................................................................ 57
Figure 6-42 | Fortigate règle IPv6 de base ............................................................................................ 57
Figure 6-43 | Fortigate configuration routage ...................................................................................... 58
Figure 6-44 | Fortigate routage static ................................................................................................... 58
Figure 6-45 | Fortigate table de routage.............................................................................................. 58
Figure 6-46 | PALO ALTO modification règle ........................................................................................ 59
Figure 6-47 | Fortigate test ping IPv4.................................................................................................... 59
Figure 6-48 | Fortigate test ping IPv6.................................................................................................... 59
Figure 6-49 | switch Cisco Catalyst 2960 .............................................................................................. 60
Figure 6-50 | plateforme Infoblox ......................................................................................................... 64
Figure 6-51 | Infoblox configuation Grid............................................................................................... 64
Figure 6-52 | Infoblox configuation Grid FQDN ................................................................................... 65
Figure 6-53 | Infoblox configuation Interface ....................................................................................... 65
Figure 6-54 | Infoblox configuation LAN1 IPv4 ..................................................................................... 65
Figure 6-55 | Infoblox configuation LAN2 IPv4 ..................................................................................... 65
Figure 6-56 | Infoblox configuation MGMT IPv4 .................................................................................. 65
Figure 6-57 | Infoblox configuation LAN1 et LAN2 IPv6........................................................................ 66
Figure 6-58 | Infoblox configuation Réseau cisel-lab IPv6 .................................................................... 66
Figure 6-59 | Infoblox configuation cisel-lab préfixe ............................................................................ 66
Figure 6-60 | Infoblox configuation cisel-lab Grid................................................................................. 67
Figure 6-61 | Infoblox configuation cisel-lab DNS................................................................................. 67
Figure 6-62 | Infoblox configuation cisel-lab plage DHCPv6 ................................................................. 67

Figure 6-63| Infoblox configuation cisel-lab plage DHCPv6 .................................................................. 67

Figure 6-64| Infoblox configuation cisel-lab Grid ................................................................................. 67
Figure 6-65| Fortigate règle DHCPv6 .................................................................................................... 68
Figure 6-66| erreur DHCPv6 Wireshark ................................................................................................ 68
Figure 6-67 | Fortigate neighbor-cache ................................................................................................ 68
Figure 6-68 | Fortigate neighbor-cache flush ....................................................................................... 68
Figure 6-69 | Infoblox configuration DHCPv6 conserve l'attribution d'adresse ................................... 69
Figure 6-70 | Confirmation DHCPv6 Wireshark .................................................................................... 69
Figure 6-71 | fonctionnement DHCPv6 relay ........................................................................................ 70
Figure 6-72 | Fortigate DHCPv4 ............................................................................................................ 70
Figure 6-73 | Infoblox réseau cisel-lab IPv4 .......................................................................................... 70
Figure 6-74 | Fortigate règle DHCPv4 ................................................................................................... 71
Figure 6-75 | PC de test validation Dual-Stack ...................................................................................... 71
Figure 6-76 | Infoblox IPAM .................................................................................................................. 72
Figure 6-77 | Infoblox IPAM vue globale............................................................................................... 72
Figure 6-78 | Infoblox IPAM pc de test ................................................................................................ 72
Figure 6-79 | Infoblox IPAM ajout IPv6 fixe .......................................................................................... 73
Figure 6-80| Infoblox IPAM ajout IPv6 configuration ........................................................................... 73
Figure 6-81| Infoblox IPAM IPv6 fixe validation sur pc de test ............................................................. 73
Figure 6-82| Infoblox IPAM ajout AAAA record .................................................................................... 73
Figure 6-83| Infoblox IPAM ajout AAAA record configuration ............................................................. 73
Figure 6-84 | Infoblox création vue External ........................................................................................ 74
Figure 6-85 | Infoblox configuration vue External ................................................................................ 74
Figure 6-86 | Infoblox création de la zone cisel-lab.ch ......................................................................... 74
Figure 6-87 | Infoblox configuration de la zone cisel-lab.ch ................................................................. 75
Figure 6-88 | Infoblox ajout zone cisel-lab.ch sur le Grid ..................................................................... 75
Figure 6-89 | Infoblox configuration de la zone cisel-lab.ch ................................................................. 75
Figure 6-90 | Infoblox configuration zone cisel-lab.ch avec interfaces ................................................ 75
Figure 6-91 | Infoblox redémarrage du service .................................................................................... 76
Figure 6-92 | Configuration ns1 pour le nom de domaine cisel-lab.ch................................................. 76
Figure 6-93 | Configuration du nom de domaine cisel-lab.ch ns1 et ns2 ............................................. 76
Figure 6-94 | DNS Hurricane Electric configuration du DNS slave ........................................................ 76
Figure 6-95 | DNS Hurricane Electric configuration du DNS master ..................................................... 77
Figure 6-96 | Infoblox configuration du transfert de zone ................................................................... 77
Figure 6-97 | Infoblox configuration du transfert de zone vers le DNS slave ....................................... 77
Figure 6-98 | PALOT ALTO configuration du NAT pour le DNS public................................................... 77
Figure 6-99 | PALO ALTO règle pour le DNS public ............................................................................... 77
Figure 6-100 | DNS Hurricane Electric contrôle de transfert de zone .................................................. 78
Figure 6-101 | Infoblox configuration vue default ................................................................................ 78
Figure 6-102 | Infoblox activation de la récursivité vue default ........................................................... 78
Figure 6-103 | Infoblox configuration vue default configuration des clients ....................................... 78
Figure 6-104 | Infoblox configuration vue default destination............................................................. 79
Figure 6-105 | Infoblox configuration vue default Forwarders ............................................................ 79
Figure 6-106 | Infoblox création de la zone cisel-lab.lan ...................................................................... 79
Figure 6-107 | Infoblox configuration de la zone cisel-lab.lan .............................................................. 79
Figure 6-108 | Infoblox activation de la zone cisel-lab.lan sur le Grid .................................................. 80

Figure 6-109 | Infoblox configuration pour Active Directory................................................................ 80

Figure 6-110 | Fortigate règle pour Forwarders IPv6 ........................................................................... 80
Figure 6-111 | Fortigate règle pour Forwarders IPv4........................................................................... 80
Figure 6-112 | PALO ALTO règle pour Forwarders ................................................................................ 81
Figure 6-113 | Fortigate règle cisel-lab vers outside IPv4 ..................................................................... 81
Figure 6-114| Fortigate règle cisel-lab vers outside IPv6...................................................................... 81
Figure 6-115| PALO ALTO règle cisel-lab vers outside IPv4 .................................................................. 81
Figure 6-116 | poste de test contrôle DNS IPv4 .................................................................................... 81
Figure 6-117 | PALO ALTO log Forwarders IPv4 .................................................................................... 81
Figure 6-118 | PALO ALTO log ping test IPv4 ........................................................................................ 82
Figure 6-119 | poste de test contrôle DNS IPv6 .................................................................................... 82
Figure 6-120 | PALO ALTO log Forwarders IPv6 .................................................................................... 82
Figure 6-121 | PALO ALTO log ping IPv6 ............................................................................................... 82
Figure 6-122 | Bladesystem c7000 face avant ...................................................................................... 83
Figure 6-123 | Bladesystem c7000 face arrière .................................................................................... 83
Figure 6-124 | contrôle configuration switch ESX................................................................................. 85
Figure 6-125 | contrôle configuration switch SW01 trunk ................................................................... 85
Figure 6-126 | ESX configuration inerface management ...................................................................... 86
Figure 6-127 | ESX configuration VLAN ................................................................................................. 86
Figure 6-128 | ESX configuration IPv4 ................................................................................................... 86
Figure 6-129 | ESX configuration mise en réseau ................................................................................. 87
Figure 6-130 | ESX configuration VLAN ................................................................................................. 87
Figure 6-131 | ESX VLAN's configurés ................................................................................................... 87
Figure 6-132 | ESX configuration du volume de stockage .................................................................... 87
Figure 6-133 | ESX volume configuré .................................................................................................... 88
Figure 6-134 | AD configuration VLAN .................................................................................................. 88
Figure 6-135 | PALO ALTO règle de NAT serveur AD ............................................................................ 88
Figure 6-136 | PALO ALTO règle service cloud vers outside ................................................................. 89
Figure 6-137 | Fortigate règle service cloud vers outside IPv4 ............................................................. 89
Figure 6-138 | Fortigate règle service cloud vers outside IPv6 ............................................................. 89
Figure 6-139 | AD configuration IPv4 .................................................................................................... 89
Figure 6-140 | AD configuration IPv6 .................................................................................................... 90
Figure 6-141 | AD test résolution DNS IPv6 .......................................................................................... 90
Figure 6-142 | AD test résolution DNS IPv4 .......................................................................................... 90
Figure 6-143 | AD installation du rôle Active Directory ........................................................................ 90
Figure 6-144 | AD création forêt cisel-lab.lan ....................................................................................... 91
Figure 6-145 | AD configuration nouvelle forêt .................................................................................... 91
Figure 6-146 | Infoblox zone cisel-lab.lan connectée à l'AD ................................................................. 91
Figure 6-147 | AD ajout suffixe cisel-lab.ch .......................................................................................... 92
Figure 6-148 | AD création de la structure ........................................................................................... 92
Figure 6-149 | Exchange configuration VLAN ....................................................................................... 93
Figure 6-150 | Exchange configuration IPv4 ......................................................................................... 93
Figure 6-151 | Exchange configuration IPv6 ......................................................................................... 93
Figure 6-152 | Exchange test résolution IPv6 ....................................................................................... 94
Figure 6-153 | Exchange test résolution ipv4 ....................................................................................... 94
Figure 6-154 | Exchange ajout du serveur dans le domaine cisel-lab.lan............................................. 94

Figure 6-155 | Infoblox création des entrées dans le DNS.................................................................... 95

Figure 6-156 | Exchange test ping SVAD01 ........................................................................................... 95
Figure 6-157 | AD ping SVEXCLOUD02 .................................................................................................. 95
Figure 6-158 | Exchange séléction des rôles à installer ...................................................................... 96
Figure 6-159 | Exchange démarrer Management Shell en administrateur .......................................... 96
Figure 6-160 | accepter domaine cisel-lab.ch via interface web .......................................................... 97
Figure 6-161 | Exchange format adresse de messagerie ...................................................................... 97
Figure 6-162 | Exchange créer une boite au lettre ............................................................................... 97
Figure 6-163 | Exchange validation format adresse de messagerie ..................................................... 97
Figure 6-164 | Infoblox création entrées A et AAAA pour serveur Exchange ....................................... 98
Figure 6-165 | test résolution mail.cisel-lab.ch..................................................................................... 98
Figure 6-166 | Infoblox entrée DNS pour autodiscover ........................................................................ 99
Figure 6-167 | Certificat SSL demande chez Comodo ........................................................................... 99
Figure 6-168 | Exchange création connecteur de réception............................................................... 100
Figure 6-169 | Exchange configuration connecteur de réception ...................................................... 100
Figure 6-170 | Exchange configuration adresse FQDN du connecteur de réception ......................... 101
Figure 6-171 | Infoblox DNS public création entrées A et AAAA pour serveur Exchange .................. 101
Figure 6-172 | Infoblox DNS public création du MX pour le routage d’email..................................... 101
Figure 6-173 | PALO ALTO règle de NAT pour mail.cisel-lab.ch .......................................................... 102
Figure 6-174 | PALO ALTO modification règle de NAT pour accès vers l’externe .............................. 102
Figure 6-175 | PALO ALTO règle pour port 25 SMTP .......................................................................... 102
Figure 6-176 | Fortigate règle pour port 25 SMTP .............................................................................. 102
Figure 6-177 | Fortigate règle pour port 25 SMTP .............................................................................. 102
Figure 6-178 | Certificat SSL réception de la validation du certificat ................................................. 103
Figure 6-179 | Exchange installation du certificat .............................................................................. 103
Figure 6-180 | Exchange activation du certificat ................................................................................ 103
Figure 6-181 | Test client schéma réseau ........................................................................................... 104
Figure 6-182 | HE création du tunnel .................................................................................................. 105
Figure 6-183 | HE informations tunnel ............................................................................................... 105
Figure 6-184 | SonicWALL configuration tunnel ................................................................................. 105
Figure 6-185 | SonicWALL configuration interface tunnel .................................................................. 106
Figure 6-186 | SonicWALL configuration des paramètres pour l’interface tunnel ............................. 106
Figure 6-187 | SonicWALL configuration de l’interface LAN ............................................................... 106
Figure 6-188 | SonicWALL configuration Routeur Advertisement...................................................... 106
Figure 6-189 | SonicWALL configuration Routeur Advertisement...................................................... 107
Figure 6-190 | SonicWALL configuration du préfixe ........................................................................... 107
Figure 6-191 | SonicWALL configuration des règles ........................................................................... 107
Figure 6-192 | Réseau client vérification configuration Dual-Stack.................................................... 108
Figure 6-193 | Réseau client vérification ping IPv4 et IPv6................................................................. 108
Figure 6-194 | Reverse-Proxy dépoiment ........................................................................................... 109
Figure 6-195 | Reverse-Proxy installation ........................................................................................... 109
Figure 6-196 | Reverse-Proxy installation ........................................................................................... 109
Figure 6-197 | Reverse-Proxy configuration VLAN ............................................................................. 110
Figure 6-198 | HAPROXY schéma de fonctionnement ........................................................................ 112
Figure 6-199 | Exchange récupération clé privée ............................................................................... 113
Figure 6-200 | Exchange exportation clé privée ................................................................................. 114

Figure 6-201 | Reverse-Proxy copie certificats ................................................................................... 114

Figure 6-202| Reverse-Proxy extraction clé privée ............................................................................. 114
Figure 6-203| Reverse-Proxy création du certificat .pem ................................................................... 114
Figure 6-204 | CISSYNC configuration VLAN ....................................................................................... 115
Figure 6-205 | Infoblox DNS public entrées CISSYNC .......................................................................... 116
Figure 6-206 | PALO ALTO configuration NAT cissync ........................................................................ 116
Figure 6-207 | PALO ALTO configuration NAT syncfile ....................................................................... 116
Figure 6-208 | PALO ALTO règle pour CISSYNC .................................................................................. 116
Figure 6-209| Certificat SSL pour CISSYNC .......................................................................................... 117
Figure 6-210| Certificat SSL pour CISSYNC validé ............................................................................... 117
Figure 7-1 | Infoblox DNS public modification entrée mail.cisel-lab.ch IPv6...................................... 118
Figure 7-2| Infoblox DNS public entrée mail.cisel-lab.ch IPv4 ............................................................ 118
Figure 7-3 | PALO ALTO modification NAT pour mail.cisel-lab.ch ...................................................... 118
Figure 7-4 | PALO ALTO règle Proxy_pub............................................................................................ 118
Figure 7-5 | PALO ALTO règle Proxy_priv............................................................................................ 118
Figure 7-6 | Fortigate règle accès serveur Exchange IPv4 .................................................................. 119
Figure 7-7 | Fortigate règle accès serveur Exchange IPv6 .................................................................. 119
Figure 7-8 | PC client configuration .................................................................................................... 119
Figure 7-9 | PC client configuration Outlook ...................................................................................... 119
Figure 7-10 | PC client validation Outlook .......................................................................................... 120
Figure 7-11 | PC client validation affichage Outlook .......................................................................... 120
Figure 7-12 | Proxy validation flux IPv6 .............................................................................................. 120
Figure 7-13 | Validation service exchange WireShark ........................................................................ 121
Figure 7-14 | numéro de session dans Wireshark .............................................................................. 121
Figure 7-15 | Exchange Validation accès IPv4 et certificat ................................................................. 121
Figure 7-16 | Proxy validation accès IPv4 sur service Exchange ......................................................... 122
Figure 7-17 | PALO ALTO NAT64 création ........................................................................................... 122
Figure 7-18 | PALO ALTO configuration du NAT64 ............................................................................. 122
Figure 7-19 | PALO ALTO suppression règle de NAT ........................................................................... 122
Figure 7-20 | PALO ALTO route static pour NAT64 ............................................................................. 123
Figure 7-21 | Validation NAT64 sur log PROXY ................................................................................... 123
Figure 7-22 | PALO ALTO validation NAT64 ........................................................................................ 123
Figure 7-23 | Validation connexion IPv4 depuis PC client .................................................................. 124
Figure 7-24 | Validation communication IPv6 entre Proxy et serveur Exchange ............................... 124
Figure 8-1 | CISSYNC validation accès web IPv6 ................................................................................. 125
Figure 8-2 | CISSYNC confirmation accès web IPv6 ............................................................................ 125
Figure 8-3 | CISSYNC validation accès IPv6 WireShark ....................................................................... 126
Figure 8-4 | CISSYNC validation client accès IPv6 ............................................................................... 126
Figure 8-5 | CISSYNC validation client accès IPv6 WireShark.............................................................. 126
Figure 8-6 | CISSYNC validation client accès IPv6 log syncfile ............................................................ 127
Figure 8-7 | CISSYNC validation accès IPv4 interface web .................................................................. 127
Figure 8-8 | CISSYNC validation client accès IPv4 log syncfile ............................................................ 127

15. Listes des tableaux

Tableau 2-1 | correspondances IPv4/IPv6 ............................................................................................ 11
Tableau 2-2 | ICMP error valeur type 1 ................................................................................................ 19
Tableau 2-6 | ICMP Informational valeur type 128 .............................................................................. 20
Tableau 2-7 | | ICMP Informational valeur type 129 ............................................................................ 21
Tableau 4-1 | plan d'adressage IPv4 ..................................................................................................... 39
Tableau 4-2 | plan d'adressage IPv6 ..................................................................................................... 40
Tableau 6-1| nomenclature .................................................................................................................. 50
Tableau 6-2 | Reverse-Proxy interfaces .............................................................................................. 110

16. Annexes
16.1. Planification
16.2. Journal de travail
Jour 6 juillet 2016 8

Intervenant Action
Création du plan d’adresse complet avec schéma
Christophe Andres
Temps 4 heures
Jour 6 juillet 2016 8

Intervenant Action
Confirmation du bloc IPv6 par Sunrise, recherche information et
configuration du routeur ASR1001 selon la documentation fournit par
Christophe Andres
Cisco.
Temps 4 heures

Jour 7 juillet 2016

Intervenant Action
Routeur ASR1001, Configuration des interfaces en dual-Stack. Validation
du fonctionnement avec la commande Ping.
Christophe Andres Configuration du switch Cisco 3560, configuration des interfaces dans le
bon VLAN.
Temps 8 heures
Jour 8 juillet 2016

Intervenant Action
Mise à jour de la documentation. Configuration du firewall PALO ALTO,
Christophe Andres configuration de base, création des zones
Temps 8 heures
Jour 13 juillet 2016

Intervenant Action
Configuration du PALO ALTO, configuration des interfaces, création d’une
Christophe Andres nomenclature pour les objets et règles, Création des règles de base
Temps 8 heures
Intervenant Action
Configuration du Foritgate, Mise à jour du Firmware, configuration des
interfaces, configuration des sous-interfaces, configuration des règles
Christophe Andres de base, test de connexion
Temps 8 heures

Intervenant Action
Configuration du Foritgate, Mise à jour du Firmware, configuration des
interfaces, configuration des sous-interfaces, configuration des règles
Christophe Andres de base, test de connexion
Temps 8 heures


Intervenant Action
Configuration du switch SW01, activation du telnet, configuration des
VLAN, configuration des interfaces
Christophe Andres
Temps 8 heures

Intervenant Action
Mise à jour de la documentation.
Christophe Andres
Temps 8 heures

Intervenant Action
Installation de la plateforme infoblox, rapide formation et configuration
Christophe Andres
de base. Mise à jour de la documentation
Sebastien Chacon
Temps 8 heures

Intervenant Action
Infoblox, configuration du DHCPv6 et test de fonctionnement,
Christophe Andres configuration du DHCPv4 et test de fonctionnement, adaptation des
règles sur Fortigate et PALO ALTO
Temps 8 heures

Intervenant Action
Installation et configuration du server ESX, Yaroslaw Dafflond m’a
Christophe Andres apporté de l’aide pour la connexion de l’ESX dans le blade et m’a
Yaroslaw Dafflon donner une rapide explication sur le fonctionnement de base. Ensuite
j’ai configuré l’adresse sur L’ILO afin de me connecter à distance sur le
serveur. J’ai ensuite pu installer VMware ESXi 6.
Temps 8 heures


Intervenant Action
configuration des switch ESX, configuration des Virtual switch, création
Christophe Andres
du volume de stockage
Temps 8 heures

Intervenant Action
Christophe Andres Mise à jour de la documentation. Installation du serveur Exchange
Temps 8 heures

Intervenant Action
Installation du serveur AD, installation d’exchange. Impossible de faire
Christophe Andres
fonctionner Exchange.
Temps 8 heures

Intervenant Action
Installation nouveau serveur Exchange, installation d’exchange,
Christophe Andres
adaptation des règles sur Fortigate et PALO ALTO
Temps 8 heures
Jour 3 août 2016

Intervenant Action
Christophe Andres Installation du réseau de test client, configuration du firewall SonicWALL,
Victor Torrent validation sur poste de test
Temps 8 heures
Jour 4 août 2016

Intervenant Action
Christophe Andres Configuration d’un accès direct depuis mon bureau sur les équipements.
Javier Pose Mise à jour de la documentation. Point de situation sur le projet.
Temps 8 heures

Jour 5 août 2016

Intervenant Action
Christophe Andres Frédéric a pu répondre à mes questions sur l’environnement linux.
Frédéric Marchand Ensuite j’ai pu effectuer l’installation du Proxy .
Temps 8 heures
Jour 9 août 2016

Intervenant Action
Christophe Andres Proxy, configuration des interfaces et configuration du HAPROXY,
Temps 8 heures
Jour 10 août 2016

Intervenant Action
Christophe Andres Proxy, configuration des interfaces et configuration du HAPROXY,
Temps 8 heures
Jour 11 août 2016

Intervenant Action
Christophe Andres Mise à jour de la documentation
Temps 8 heures
Jour 12 août 2016

Intervenant Action
Commande du bon travail pour la configuration du serveur CISSYNC
Christophe Andres chez Numvision. Contact et envoie formulaire. Mise à jour
documentation
Temps 8 heures
Jour 17 août 2016

Intervenant Action
Christophe Andre Infoblox, évaluation de l’IPAM, configuration du DNS public et interne
Temps 8 heures

Jour 18 août 2016

Intervenant Action
Création d’un certificat pour le FQDN mail.cisel-lab.ch. configuration d’un
Christophe Andres
connecteur de réception pour la confirmation du certificat.
Temps 8 heures
Jour 19 août 2016

Intervenant Action
Christophe Andres Installation du certificat sur le serveur Exchange. Adaptation des règles
sur Fortigate et PALO ALTO
Temps 8 heures
Jour 25 août 2016

Intervenant Action
Exportation de la clé privé, Ajout du certificat et de la clé sur le Proxy,
Christophe Andres
configuration du certificat.pem
Temps 8 heures
Jour 31 août 2016

Intervenant Action
Installation et configuration du serveur SVCISSYNC, création du certificat
pour le FQDN cissync.cisel-lab.ch. Le support rencontre des problèmes
Christophe Andres
de configuration avec le certificat. La clé primaire semble ne pas
Support numvision
correspondre. Après avoir renvoyer les informations ca a fonctionné.
Temps 8 heures
Jour 2 septembre 2016

Intervenant Action
Validation du serveur Exchange en Dual-Stack et avec une configuration
Christophe Andres NAT64, adaptation des règles sur Fortigate et PALO ALTO, configuration
du HAPROXY.
Temps 8 heures


Intervenant Action
du HAPROXY.
Temps 8 heures

Intervenant Action
du HAPROXY.
Temps 8 heures

Intervenant Action
Christophe Andres Validation du serveur CISSYNC en Dual-Stack, adaptation des règles sur
Support numvision Fortigate et PALO ALTO, configuration du HAPROXY.
Temps 8 heures

Intervenant Action
Validation du serveur CISSYNC en Dual-Stack, adaptation des règles sur
Christophe Andres
Fortigate et PALO ALTO, configuration du HAPROXY.
Temps 8 heures

Intervenant Action
Validation du serveur CISSYNC en Dual-Stack, adaptation des règles sur
Christophe Andres
Fortigate et PALO ALTO, configuration du HAPROXY.
Temps 8 heures
jour 12 septembre 2016

Intervenant Action
Mise à jour de la documentation
Christophe Andres
Temps 8 heures


Intervenant Action
Christophe Andres
Temps 8 heures

Intervenant Action
Christophe Andres
Temps 8 heures

Intervenant Action
Christophe Andres
Temps 8 heures

Intervenant Action
Christophe Andres Mise à jour de la documentation
Pierre Fûllman Point de situation avec Pierre.
Temps 8 heures

Intervenant Action
Christophe Andres
Temps 8 heures

Intervenant Action
Christophe Andres
Temps 8 heures

Intervenant Action
Christophe Andres
Temps 8 heures


Intervenant Action
Mise en page du document
Christophe Andres
Temps 8 heures

Intervenant Action
Relecture et impression des documents
Christophe Andres
Temps 8 heures
16.3. Listes des symboles et abréviations

AD : Active Directory
ARP : Address Resolution Protocol
BGP : Border Gateway Protocol
DAD : Duplicate Address Detection
DHCP : Dynamic Host Configuration Protocol
DMZ : Demilitarized Zone
DNS : Domain Name System
IANA : Internet Assigned Numbers Authority
ICMP : Internet Control Message Protocol
IPAM : Internet Protocol Address Management
LAN : Local Area Network
LIR : Local Internet Registry
MLD : Multicast Listener Discovery
MTU : Maximum Transmission Unit
NAT : Network Address Translation
NUD : Neighbor Unreachability Detection
PA : Provider-aggregatable
PI : Provider Independent
PING : Packet InterNet Groper
RFC : Request For Comments
RIPE NCC : Réseaux IP Européens Network Coordination Centre
RIR : Regional Internet Registry
SIK : Schweizerische Informatikkonferenz
SLAAC : Stateless Address Autoconfiguration
SMTP : Simple Mail Transfer Protocol
SSH : Secure Shell
TCP : Transmission Control Protocol
UDP : User Datagram Protocol

16.4. Liste des références

RFC 791, « Internet Protocol », 1981
RFC 2460, « Internet Protocol, Version 6 (IPv6) Specification », 1998
RFC 1981, « Path MTU Discovery for IP version 6 », 1996
RFC 4861, « Neighbor Discovery for IP version 6 (IPv6) », 2007
RFC 4862, « IPv6 Stateless Address Autoconfiguration », 2007
RFC 3056, « Connection of IPv6 Domains via IPv4 Clouds », 2001
RFC 3041, « Privacy Extensions for Stateless Address Autoconfiguration in IPv6 », 2001
RFC 5246, « The Transport Layer Security (TLS) Protocol », 2008
RFC 6052, « IPv6 Addressing of IPv4/IPv6 Translators », 2010

Authentification
Le soussigné, Christophe Andres, atteste par la présente avoir réalisé seul ce travail et n’avoir utilisé
aucune autre source que celles expressément mentionnées, si ce n’est les connaissances acquises
durant ses études et son expérience acquise dans une activité professionnelle.
Villars-sur-Glâne, le 23.09.2016
Christophe Andres

Andres Christophe

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Andres Christophe

Transféré par

Droits d'auteur :

Formats disponibles

Travail de Bachelor 2016

Période de réalisation Juillet à septembre 2016

Auteur Andres Christophe

Conseiller Füllemann Pierre

Mandant Pose Javier

Yverdon-les-Bains, septembre 2016

HEIG-VD, av. Sport 20, 1401 Yverdon-les-Bains

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 1 | 149

Table des matières

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 2 | 149

4.2.3. Conclusion Concept ....................................................................................................... 35

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 3 | 149

6.4.5. Configuration des interfaces 4, 5 et 6 ........................................................................... 62

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 4 | 149

6.10.2. Configuration de l’interface de management ............................................................. 110

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 5 | 149

16.1. Planification ..................................................................................................................... 140

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 6 | 149

L’entreprise propose 4 principaux types de prestations :

• Le Cloud : Hébergement des ressources informatiques au sein de l’infrastructure CISEL, afin de

Figure 1-1 | Logo de CISEL Informatique

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 7 | 149

2.Présentation du protocole IPv6

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 8 | 149

On peut citer les avantages et bénéfices d’IPv6 suivants :

• Extension de la plage d’adresse IP avec 128 bits contre 32 pour IPv4

Figure 2-1 | Statistiques de l’utilisation d’IPV6 en suisse

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 9 | 149

2.1. Entête IPv6 vs IPv4

Figure 2-2 | entête IPv4

Et voici celle d’IPv6 (RFC 2460)

Figure 2-3 | Entête IPv6

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 10 | 149

Voici les correspondances des champs IPv4 et IPv6:

Figure 2-4 | Next Header IPv6

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 11 | 149

2.2. Adresse IPv6

Figure 2-5 | Format adresse IPv6

2001:0DB8:AAAA:0001:0000:0000:0000:0200 -> 2001:DB8:AAAA:1:0:0:0:200

FF02:0000:0000:0000:0000:0000:0000:0001 -> FF02::0001

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 12 | 149

On peut bien sûr combiner les deux écritures :

FF02:0000:0000:0000:0000:0000:0000:0001 -> FF02::1

Adresse IPv6/longueur du préfixe

Exemple pour l’adresse

2.2.1. Types d’adresses

Les trois types d’adresses sont les suivantes :

Figure 2-6 | Types d’adresses IPv6

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 13 | 149

2.2.2. Les Adresses Unicast

On peut voir les types d’adresses « Unicast » suivants :

Voici un schéma de la structure d’adresse :

Figure 2-7 | Structure adresse IPv6

Voici un exemple d’une configuration possible pour un plan d’adressage :

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 14 | 149

Figure 2-8 | Exemple de plan d’adressage IPv6

Voici les différentes options pour les deux possibilités :

Figure 2-9 | Options de configuration d’adresse Global Unicast

RAPPORT | TRAVAIL DE BACHELOR | HEIG-VD 2016 15 | 149

• Stateless Autoconfiguration permet la configuration automatique de l’adresse via les

Voici donc l’utilisation de l’adresse « Link-Local »

• Avant l’obtention d’une adresse IPv6 routable

La configuration de l’adresse peut également se faire manuellement ou de manière automatique.

Elle indique l’absence d’une adresse IPv6.