---
# System prepended metadata

title: SAE2.1 – Construire un réseau informatique pour une petite structure
tags: [HTTP, NAT, SSH, OSPF, adressage, VTP, DNS, vlan, Analyse_de_trame]

---

# SAE2.1 – Construire un réseau informatique pour une petite structure

https://hackmd.io/etrSzKK6QZ-nyBaWel9tLA?view

**Objectifs :**

Mettre en œuvre un réseau informatique multisites simplifié pour une entreprise, déployer des services élémentaires et appliquer des règles de sécurité. Cette topologie répondra à un besoin simple d’interconnexion du siège de l’entreprise situé à Paris avec sa filiale de Poitiers. L’architecture du réseau et les fonctionnalités mises en œuvre sont décrites et illustrées ci-après.

## Fonctionnalité à mettre en oeuvre
### Siège de l'entreprise - Paris
Le réseau IP privé 172.16.0.0/16 est allouée au siège de l’entreprise. Les sous-réseaux comporteront environ 250 hôtes. Les VLAN utilisés sont les suivants : 

| VLAN 100                   | VLAN 110                                     | VLAN 120                      | VLAN 170                                |
| -------------------------- | -------------------------------------------- | ----------------------------- | --------------------------------------- |
| DMZ - Héberge les serveurs | R&D – Département recherche et développement | PROD – Département production | ADMIN – Gestion du réseau et vlan natif |

Les services HTTP, DNS et SSH sont déployés sur le SRV-DEB9-1 dans la DMZ. Les utilisateurs peuvent accéder à ces services depuis les hôtes du siège et également depuis le site de Poitiers. Le nom de domaine de l’entreprise est *netcom.local*. Les utilisateurs ont également accès à Internet.

Le routeur R-GW-1 est le routeur passerelle du siège de l’entreprise. Il est connecté au réseau IP mis à disposition par le FAI. Les fonctionnalités de translation d’adresse dynamique et de translation d’adresse statique sont utilisées.

### Filiale de l’entreprise – Poitiers

Le réseau IP privé 192.168.86.0/24 est allouée à la filiale de l’entreprise située à Poitiers. Les VLAN utilisés sont les suivants : 

| VLAN 130                          | VLAN 140                  | VLAN 170                                |
| --------------------------------- | ------------------------- | --------------------------------------- |
| COMPTA – Département comptabilité | VENTE – Département vente | ADMIN – Gestion du réseau et vlan natif |
| 20 hôtes                          | 72 hôtes                  | 6 hôtes                                 |

Les utilisateurs du site de Poitiers ont accès aux ressources de la DMZ (HTTP, DNS et SSH pour l’administrateur) et également à Internet.
Le routeur R-GW-2 est le routeur passerelle de la filiale de l’entreprise. Il est connecté au réseau IP mis à disposition par le FAI. La fonction NAT est utilisée.

### Interconnexion du FAI

Le FAI assure l’interconnexion du siège de l’entreprise avec sa filiale et permet la connexion vers Internet par l’intermédiaire des routeurs R-1, R-2 et R-3. Le réseau IP alloué pour l’adressage de cette interconnexion est 10.10.10.0/27. Le protocole de routage OSPFv2 est utilisé.

:::info
**Remarques :**
Tous les équipements actifs de l’entreprise permettent un accès distant avec le protocole SSH.
Tous les hôtes du réseau (Siège et Filiale) interroge le serveur DNS de la DMZ.
:::

### Schéma de la topologie du réseau à mettre en place
![sae topo](https://hackmd.io/_uploads/H1c3y1XxA.png)

## Adressage du réseau

### Adressage pour le siège de l’entreprise - Paris

| Adresse IP du réseau | Masque de sous-réseau | Adresse de passerelle | ID du VLAN | Ports associés pour chaque réseau |
| -------------------- | --------------------- | --------------------- | ---------- | --------------------------------- |
| 172.16.0.0           | 255.255.255.0 (/24)   | 172.16.0.254          | 100        | ?                                 |
| 172.16.1.0           | 255.255.255.0 (/24)   | 172.16.1.254          | 110        | ?                                 |
| 172.16.2.0           | 255.255.255.0 (/24)   | 172.16.2.254          | 120        | ?                                 |
| 172.16.3.0           | 255.255.255.0 (/24)   | 172.16.3.254          | 170        | ?                                 |

### Adressage pour la filiale de l’entreprise – Poitiers

| Adresse IP du réseau | Masque de sous-réseau | Adresse de passerelle | ID du VLAN | Ports associés pour chaque réseau |
| -------------------- | --------------------- | --------------------- | ---------- | --------------------------------- |
| 192.168.86.0         | 255.255.255.128 (/25) | 192.168.86.126        | 130        | ?                                 |
| 192.168.86.128       | 255.255.255.224 (/27) | 192.168.86.158        | 140        | ?                                 |
| 192.168.86.160       | 255.255.255.248 (/29) | 192.168.86.166        | 170        | ?                                 |

### Adressage de l'interconnexion du FAI

| Nom du réseau | Adresse réseau | Plage d'adresse IP        | Adresse de broadcast | Masque de sous-réseau |
| ------------- | -------------- | ------------------------- | -------------------- | --------------------- |
| R-1 -> R-2    | 10.10.10.0     | 10.10.10.1 - 10.10.10.2   | 10.10.10.3           | 255.255.255.252 (/30) |
| R-1 -> R-3    | 10.10.10.4     | 10.10.10.5 - 10.10.10.6   | 10.10.10.7           | 255.255.255.252 (/30) |
| R-1 -> R-GW-1 | 10.10.10.8     | 10.10.10.9 - 10.10.10.10  | 10.10.10.11          | 255.255.255.252 (/30) |
| R-2 -> R-3    | 10.10.10.12    | 10.10.10.13 - 10.10.10.14 | 10.10.10.15          | 255.255.255.252 (/30) |
| R-2 -> R-GW-2 | 10.10.10.16    | 10.10.10.17 - 10.10.10.18 | 10.10.10.19          | 255.255.255.252 (/30) |

## Configuration des équipements du réseau "Filiale"

### Configuration du commutateur SW-3
La configuration de SW-3 est la suivante : 

Elle dispose de 3 VLANs : COMPTA, VENTE et ADMIN ; avec les numéros correspondant : 130, 140 et 170.

```
conf t
hostname SW-3
no ip domain-lookup

vlan 130
name COMPTA
vlan 140
name VENTE
vlan 170
name ADMIN
```

On vérifie par la suite que les VLANs ont bien été créent avec la commande 'sh vlan br' : 

![image](https://hackmd.io/_uploads/BktC-DJXR.png)

:::success
Nos VLANs ont bien été créent !
:::

**Maintenant on souhaite réaliser le routage inter-VLAN sur ce réseau.**

Dans un premier temps, on associe les VLANs au ports de SW-3, à l'aide des commandes suivantes : 
```
int Gi0/0
switchport mode access
switchport access vlan 130

int Gi1/0
switchport mode access
switchport access vlan 140

int Gi2/0
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 170
```

### Configuration du routeur R-GW-2
Pour que le routage inter-VLAN fonctionne, il nous faut maintenant configurer le R-GW-2.

On commance donc par configurer les adresses IP des interfaces du routeurs, à l'aide de l'adressage effectué plutôt et des commandes suivantes : 

```
int Gi0/2.130
encapsulation dot1Q 130
ip address 192.168.86.126 255.255.255.128

int Gi0/2.140
encapsulation dot1Q 140
ip address 192.168.86.158 255.255.255.224

int Gi0/2.170
encapsulation dot1Q 170 native
ip address 192.168.86.166 255.255.255.248

int Gi0/2
no shutdown
```

### Configuration des VPC de chaque VLAN
Enfin, nous configurons les VPC avec leurs adresses IP, à l'aide de la commande : ```ip [addr_ip] [mask] [gateway]```

VPC-5 (COMPTA - VLAN 130)
```
ip 192.168.86.1 255.255.255.128 192.168.86.126
```

VPC-6 (VENTE - VLAN 140)
```
ip 192.168.86.129 255.255.255.224 192.168.86.158
```

### Vérification du routage inter-VLAN
Vérification de la bonne communication entre les VPC des différents VLANs : 

Test de connectivité (ping) entre VPC-5 et VPC-6 : 

![image](https://hackmd.io/_uploads/rymL8P17C.png)

Capture Wireshark des communications entre les VPCs : 

![image](https://hackmd.io/_uploads/r1iDvv17A.png)

![image](https://hackmd.io/_uploads/rJXKvw17A.png)

![image](https://hackmd.io/_uploads/By2jPPymR.png)

![image](https://hackmd.io/_uploads/Bkgpwvk7C.png)


:::success
Nos VPC communiquent bien ensemble, le routage inter-VLAN est donc bien configuré.
:::

### Configuration du SSH sur les équipements actifs de la Filiale
#### SSH sur R-GW-2

Pour activer le SSH sur les équipements actifs, on utilise les commandes suivantes : 
```
!--- Étape 1: Créer compte admin et un mot de passe

service password-encryption
username poitiers password 0 gtrnet

!--- Étape 2: Configurer le domaine DNS du routeur.

ip domain-name filiale.local

!--- Étape 3: Générer une clé SSH à utiliser avec SSH.

crypto key generate rsa modulus 1024
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 2

!--- Étape 4: Par défaut, le transport vty est Telnet. Dans ce cas, Telnet est désactivé et seul SSH est pris en charge.

line vty 0 4
login local
transport input ssh
```

:::warning
Pour régler les problèmes de no matching key sur Debian 12, il faut ajouter ssh-rsa et diffie-hellman-group-exchange-sha1 au fichier /etc/ssh/ssh_config : 

```
nano /etc/ssh/ssh_config

--! Ajouter les lignes suivantes :
HostKeyAlgorithms +ssh-rsa
KexAlgorithms +diffie-hellman-group-exchange-sha1
```
:::

Afin de tester si le SSH fonctionne sur R-GW-2, on ajoute un PC (debian 12), et on tente de se connecter sur les équipements via SSH : 

![image](https://hackmd.io/_uploads/SJnO82y7R.png)

#### SSH sur SW-3
Pour ce qui est de SW-3, on suit les même étapes pour l'activation du SSH, mais on crééra une SVI (Switch Virtual Interface), qui n'est utilisée que pour l'accès à distance à notre commutateur.

Configuration de la SVI : 
```
conf t
int vlan 170
no shutdown
ip address 192.168.86.162 255.255.255.248
end
```

On vérifie la bonne configuration avec la commande 'sh ip int br' : 

```
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     unassigned      YES unset  up                    up
GigabitEthernet0/1     unassigned      YES unset  down                  down
GigabitEthernet0/2     unassigned      YES unset  down                  down
GigabitEthernet0/3     unassigned      YES unset  down                  down
GigabitEthernet1/0     unassigned      YES unset  up                    up
GigabitEthernet1/1     unassigned      YES unset  down                  down
GigabitEthernet1/2     unassigned      YES unset  down                  down
GigabitEthernet1/3     unassigned      YES unset  down                  down
GigabitEthernet2/0     unassigned      YES unset  up                    up
GigabitEthernet2/1     unassigned      YES unset  down                  down
GigabitEthernet2/2     unassigned      YES unset  down                  down
GigabitEthernet2/3     unassigned      YES unset  down                  down
GigabitEthernet3/0     unassigned      YES unset  up                    up
GigabitEthernet3/1     unassigned      YES unset  down                  down
GigabitEthernet3/2     unassigned      YES unset  down                  down
GigabitEthernet3/3     unassigned      YES unset  down                  down
Vlan170                192.168.86.162  YES manual up                    up
```

Pour tester le SSH, on procède de la même manière, on tente de se connecter avec le PC situé dans le VLAN ADMIN : 

![image](https://hackmd.io/_uploads/ByWxFhyQA.png)


:::success
Le SSH est bien activé et fonctionnel sur nos équipements actifs de la Filiale Poitiers
:::

### Enfin on termine la configuration de l'interface externe de R-GW-2

D'après le pool qui l'on a créer, on va assigner l'adresse ip **10.10.10.18 /30** à R-GW-2 : 

```
int Gi0/1
ip address 10.10.10.18 255.255.255.252
no shutdown
```

On vérifie la bonne assignation à l'aide de la commande 'sh ip int br' : 

```
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES unset  administratively down down
GigabitEthernet0/1         10.10.10.18     YES manual up                    up
GigabitEthernet0/2         unassigned      YES unset  up                    up
GigabitEthernet0/2.130     192.168.86.126  YES NVRAM  up                    up
GigabitEthernet0/2.140     192.168.86.158  YES NVRAM  up                    up
GigabitEthernet0/2.170     192.168.86.166  YES NVRAM  up                    up
GigabitEthernet0/3         unassigned      YES unset  administratively down down
```

## Configuration des équipements du réseau "Entreprise"
### Création et distribution des VLANs par VTP
#### Configuration du MLS-1

Pour la configuration du MLS-1, on suivra les étapes suivantes : 
- Configurer le nom d'hôte
- Désactiver les recherches DNS
- Création des VLANs
- Configuration du VTP

On utilise les commandes suivantes sur MLS-1 : 
```
hostname MLS-1
no ip domain-lookup

vlan 100
name DMZ
vlan 170
name ADMIN
vlan 110
name R&D
vlan 120
name PROD
exit

vtp mode server
vtp domain Paris
vtp password gtrnet
vtp version 2
vtp pruning

int Gi2/0
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 170

int Gi2/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 170

end
```

Vérification de la créations des VLANs : 

![image](https://hackmd.io/_uploads/Byqg301XR.png)

#### Configuration des SW-1 et SW-2
Pour la configuration des SW-1 et SW-2, on suivra les étapes suivantes : 
- Configurer le nom d'hôte
- Désactiver les recherches DNS
- Configuration du VTP
    - Activation du mode client
    - Ajout du nom de domaine
    - Ajout du mot de passe
    - Mettre un lien trunk entre les SW et MLS
- Affectation des ports au bon VLAN

Configuration de SW-1 : 
```
en
conf t
hostname SW-1
no ip domain-lookup

vtp mode client
vtp domain Paris
vtp password gtrnet

int Gi2/0
switchport trunk encapsulation dot1Q
switchport mode trunk
switchport trunk native vlan 170

int Gi0/0
switchport mode access
switchport access vlan 100

int Gi1/0
switchport mode access
switchport access vlan 170

end
```

Configuration de SW-2 : 
```
en
conf t
hostname SW-2
no ip domain-lookup

vtp mode client
vtp domain Paris
vtp password gtrnet

int Gi2/1
switchport trunk encapsulation dot1Q
switchport mode trunk
switchport trunk native vlan 170

int Gi1/0
switchport mode access
switchport access vlan 170

int Gi3/0
switchport mode access
switchport access vlan 110

int Gi3/1
switchport mode access
switchport access vlan 120

end
```

On vérifie le bon déploiement des VLAN avec les commandes 'show vtp counters' et 'show vlan brief' : 

show vtp counters :
```
VTP statistics:
Summary advertisements received    : 1
Subset advertisements received     : 0
Request advertisements received    : 0
Summary advertisements transmitted : 1
Subset advertisements transmitted  : 0
Request advertisements transmitted : 0
Number of config revision errors   : 0
Number of config digest errors     : 0
Number of V1 summary errors        : 0


VTP pruning statistics:

Trunk            Join Transmitted Join Received    Summary advts received from
                                                   non-pruning-capable device
---------------- ---------------- ---------------- ---------------------------
Gi2/0               0                0                0
```

show vlan brief :
```
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/1, Gi0/2, Gi0/3, Gi1/1
                                                Gi1/2, Gi1/3, Gi2/1, Gi2/2
                                                Gi2/3, Gi3/0, Gi3/1, Gi3/2
                                                Gi3/3
100  DMZ                              active    Gi0/0
110  R&D                              active
120  PROD                             active
170  ADMIN                            active    Gi1/0
1002 fddi-default                     act/unsup
1003 trcrf-default                    act/unsup
1004 fddinet-default                  act/unsup
1005 trbrf-default                    act/unsup
```

:::success
La mise en place des VLANs et leurs distributions via le protocol VTP est fonctionnel !
:::

### Configuration du routage inter-VLAN sur le commutateur de couche 3

- Créer les SVI
- Encapsulation dot1Q
- adresse IP


Sur un commutateur de couche 3, une interface virtuelle de commutateur (SVI) est une interface logique qui fonctionne comme un routeur pour un VLAN (réseau local virtuel) spécifique.

Les SVI permettent de :

- Effectuer le routage entre les VLANs: Les paquets qui traversent le commutateur et qui doivent passer d'un VLAN à un autre sont gérés par la SVI associée à chaque VLAN. La SVI utilise les tables de routage et l'adressage IP pour déterminer le chemin optimal pour envoyer les paquets à leur destination.
- Connecter le VLAN à un routeur externe: La SVI peut être connectée à un routeur externe pour permettre aux appareils du VLAN d'accéder à Internet ou à d'autres réseaux.

On va dans un premier temps activer les fonctionnalités de couche 3 du commutateur avec la commande ```ip routing```.

Par la suite, on configure les SVI avec leurs adresses IP et masque de sous-réseaux : 

```
interface vlan 100
ip address 172.16.0.254 255.255.255.0
no shutdown

interface vlan 110
ip address 172.16.1.254 255.255.255.0
no shutdown

interface vlan 120
ip address 172.16.2.254 255.255.255.0
no shutdown

interface vlan 170
ip address 172.16.3.254 255.255.255.0
no shutdown
```

On vérifie la communication entre les hôtes des différents VLANs par des tests de connectivité ICMP : 

Ping entre VLAN 100 -> VLAN 110 : 
![image](https://hackmd.io/_uploads/H13xaJgXR.png)

Ping entre VLAN 100 -> VLAN 120 : 
![image](https://hackmd.io/_uploads/SkuX6ylXR.png)

Ping entre VLAN 100 -> VLAN 170 : 
![image](https://hackmd.io/_uploads/SyPBayemA.png)

Pour finalement validé le fonctionnement du routage inter-vlan, on réalise des captures Wireshark afin d'analyser les paquets 802.1Q : 

Capture Wireshark lors du ping VLAN 100 -> VLAN 110 : 

![image](https://hackmd.io/_uploads/SyXJWggQA.png) 
On peut voir que toutes les requêtes porte l'étiquette **ID: 100** sur Gi2/0 de MLS-1 (celle du VLAN100).

![image](https://hackmd.io/_uploads/HJzHbgx70.png)
On peut voir que toutes les requêtes porte l'étiquette **ID: 110** sur Gi2/1 de MLS-1 (celle du VLAN110).

### Configuration de l’interconnexion entre MLS-1 et R-GW-1

Pour l'interconnexion, la solution choisie est de configurer le port Gi0/0 pour qu’il prenne en charge la couche 3. Ensuite, un routage statique est nécessaire entre le commutateur de couche 3 et le routeur R-GW-1.

Pour configurer le port Gi0/0, il faut qu'il prenne en charge la couche 3, pour cela, on utilise la commande ```no switchport```. On utilisera l'adressage suivant **1.1.1.0/30**.

Configuration du port Gi0/0 (MLS-1) : 
```
int Gi0/0
no switchport
ip address 1.1.1.1 255.255.255.252
no shutdown
exit

ip route 0.0.0.0 0.0.0.0 1.1.1.2
```

Configuration du port Gi0/0 (R-GW-1) : 
```
int Gi0/0
ip address 1.1.1.2 255.255.255.252
no shutdown

ip route 172.16.0.0 255.255.0.0 1.1.1.1
```

#### Analyse des tables de routages de MLS-1 et R-GW-1

Voici la table de routage de MLS-1 : 
```
Gateway of last resort is 1.1.1.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 1.1.1.2
      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/30 is directly connected, GigabitEthernet0/0
L        1.1.1.1/32 is directly connected, GigabitEthernet0/0
      172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
C        172.16.0.0/24 is directly connected, Vlan100
L        172.16.0.254/32 is directly connected, Vlan100
C        172.16.1.0/24 is directly connected, Vlan110
L        172.16.1.254/32 is directly connected, Vlan110
C        172.16.2.0/24 is directly connected, Vlan120
L        172.16.2.254/32 is directly connected, Vlan120
C        172.16.3.0/24 is directly connected, Vlan170
L        172.16.3.254/32 is directly connected, Vlan170
```

Voici la table de routage de R-GW-1 : 
```
Gateway of last resort is not set

      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/30 is directly connected, GigabitEthernet0/0
L        1.1.1.2/32 is directly connected, GigabitEthernet0/0
S     172.16.0.0/16 [1/0] via 1.1.1.1
```

**Pour MLS-1 :**
Gateway of last resort: Cette ligne indique la passerelle par défaut à utiliser lorsque le routeur ne connaît pas la route pour une destination donnée. Dans ce cas, la passerelle par défaut est définie à 1.1.1.2 pour le réseau 0.0.0.0.

Routes spécifiques:

0.0.0.0/0: Cette route indique que tout trafic destiné à n'importe quelle adresse IP (0.0.0.0/0) doit être envoyé via la passerelle 1.1.1.2.
1.0.0.0/8: Il y a deux sous-réseaux dans cette plage.
172.16.0.0/16: Cette plage est également divisée en plusieurs sous-réseaux avec différentes passerelles et adresses de liaison.

**Pour R-GW-1 :**
Gateway of last resort: Ici, la passerelle par défaut n'est pas définie (not set). Cela signifie que ce routeur ne connaît pas de passerelle par défaut pour les destinations inconnues.

Routes spécifiques:

1.0.0.0/8: Comme sur MLS-1, cette plage est divisée en deux sous-réseaux.
172.16.0.0/16: Il y a une route spécifique définie pour cette plage, indiquant que tout trafic destiné à cette plage doit être envoyé via la passerelle 1.1.1.1.

#### Vérification de la connectivité entre un hôte du réseau et l'interface Gi0/0 du routeur R-GW-1

Test de connectivité ping entre VLAN 100 et Gi0/0 de R-GW-1 : 

![image](https://hackmd.io/_uploads/ryoSpWlmA.png)

#### Mise en place du protocol SSH sur les équipements actifs R-GW-1, MLS-1, SW-1 et SW-2

On suit les même étapes que pour la Filiale : 

```
!--- Étape 1: Créer compte admin et un mot de passe

service password-encryption
username paris password 0 gtrnet

!--- Étape 2: Configurer le domaine DNS du routeur.

ip domain-name entreprise.local

!--- Étape 3: Générer une clé SSH à utiliser avec SSH.

crypto key generate rsa modulus 1024
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 2

!--- Étape 4: Par défaut, le transport vty est Telnet. Dans ce cas, Telnet est désactivé et seul SSH est pris en charge.

line vty 0 4
login local
transport input ssh
```

Pour SW-1 et SW-2, on affecte une adresse IP à une SVI (VLAN 170), afin de pouvoir s'y connecter en SSH.

Pour SW-1 : 
```
interface vlan 170
ip address 172.16.3.3 255.255.255.0
no shutdown
```

Pour SW-2 : 
```
interface vlan 170
ip address 172.16.3.4 255.255.255.0
no shutdown
```

#### Vérification du bon fonctionnement du SSH avec une machine debian

Sur R-GW-1 : 

![image](https://hackmd.io/_uploads/r1CYfGeXC.png)

Sur MLS-1 : 

![image](https://hackmd.io/_uploads/ByOhfGlQA.png)

Sur SW-1 : 

![image](https://hackmd.io/_uploads/HyNvVGl7C.png)

Sur SW-2 : 

![image](https://hackmd.io/_uploads/rJAqVMxXC.png)

:::info
Peut-être limiter l'accès au SSH seulement au VLAN 170, avec une ACL ???
```
access-list SSH_ACCESS permit tcp 172.16.3.0 0.0.0.255 any eq ssh

interface GigabitEthernet2/0
ip access-group SSH_ACCESS in

interface GigabitEthernet2/1
ip access-group SSH_ACCESS in
```
:::

:::success
Le protocole a bien été mis en place sur nos équipements actifs et est fonctionnel !
:::

### Configuration du réseau "FAI"

On commence par affecter les adresses IP aux interfaces des routeurs R-1, R-2, et R-3. L'interface Gi0/ de R-3 sera configurée ultérieurement.

Pour cela on utilise l'adressage effectuer au début de ce document (cf. Adressage de l'interconnexion du FAI) : 

#### Adressage de l'interconnexion du FAI

| Nom du réseau | Adresse réseau | Plage d'adresse IP        | Adresse de broadcast | Masque de sous-réseau |
| ------------- | -------------- | ------------------------- | -------------------- | --------------------- |
| R-1 -> R-2    | 10.10.10.0     | 10.10.10.1 - 10.10.10.2   | 10.10.10.3           | 255.255.255.252 (/30) |
| R-1 -> R-3    | 10.10.10.4     | 10.10.10.5 - 10.10.10.6   | 10.10.10.7           | 255.255.255.252 (/30) |
| R-1 -> 
| 10.10.10.8     | 10.10.10.9 - 10.10.10.10  | 10.10.10.11          | 255.255.255.252 (/30) |
| R-2 -> R-3    | 10.10.10.12    | 10.10.10.13 - 10.10.10.14 | 10.10.10.15          | 255.255.255.252 (/30) |
| R-2 -> R-GW-2 | 10.10.10.16    | 10.10.10.17 - 10.10.10.18 | 10.10.10.19          | 255.255.255.252 (/30) |

### Configuration du protocole de routage OSPF sur R-1, R-2 et R-3

Avant toute chose, on choisit par convention le routeur ID par leurs noms, c'est-à-dire : 

R-1 aura pour router-id : 1.1.1.1
R-2 aura pour router-id : 2.2.2.2
R-3 aura pour router-id : 3.3.3.3

Ensuite l'air de routage OSPF sera le 1 et la zone 0. Le réseau autorisé à diffuser est le **10.10.10.0 /24** (Masque Wildcard 0.0.0.255).

Configuration sur R-3 : 

```
conf t
router ospf 1
router-id 3.3.3.3
passive-interface Gi0/1
network 10.10.10.0 0.0.0.255 area 0
default-information originate
end
```

Configuration sur R-2 : 

```
conf t
router ospf 1
router-id 2.2.2.2
passive-interface Gi0/1
network 10.10.10.0 0.0.0.255 area 0
end
```

Configuration de R-1 : 

```
conf t
router ospf 1
router-id 1.1.1.1
passive-interface Gi0/1
network 10.10.10.0 0.0.0.255 area 0
end
```

Les interfaces G0/1 de R-1 et R-2 sont pasives car ils s'utiliseront du NAT surchargé pour communiquer. Et leurs réseaux se trouve déjà dans celui des routeurs R1-2-3.

Vérification de la configuration d'OSPF sur **R-3** : 

```
 Routing Process "ospf 1" with ID 3.3.3.3
 Start time: 00:00:17.570, Time elapsed: 00:08:02.139
 It is an autonomous system boundary router
 Reference bandwidth unit is 100 mbps
    Area BACKBONE(0)
        Number of interfaces in this area is 3
        Area has no authentication
        SPF algorithm last executed 00:01:40.340 ago
        SPF algorithm executed 7 times
        Area ranges are
        Number of LSA 5. Checksum Sum 0x017700
        Number of opaque link LSA 0. Checksum Sum 0x000000
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0
```

En reprenant les informations importantes, on peut voir :

- `Routing Process "ospf 1" with ID 3.3.3.3`, ce qui montre que le processus OSPF est le numéro 1 avec un ID de routeur de 3.3.3.3.
- `It is an autonomous system boundary router`, ce qui signifie que le routeur est configuré comme un ASBR (Autonomous System Boundary Router), indiquant qu'il fait la redistribution des routes externes, probablement vers ou depuis un autre protocole de routage.
- `Reference bandwidth unit is 100 mbps`, la bande passante de référence est fixée à 100 Mbps, utilisée pour calculer le coût des liens OSPF en fonction de leur bande passante.

Vérification de la configuration d'OSPF sur **R-2** : 

```
 Routing Process "ospf 1" with ID 2.2.2.2
 Start time: 00:00:18.018, Time elapsed: 00:19:41.481
 Reference bandwidth unit is 100 mbps
    Area BACKBONE(0)
        Number of interfaces in this area is 3
        Area has no authentication
        SPF algorithm last executed 00:14:38.808 ago
        SPF algorithm executed 6 times
        Area ranges are
        Number of LSA 5. Checksum Sum 0x017700
        Number of opaque link LSA 0. Checksum Sum 0x000000
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0
```

Les informations obtenues sur R-2 sont assez similaires par rapport à R-3, mise à part que son ID de routeur est 2.2.2.2 et qu'il n'est pas ASBR.

Vérification de laconfiguration d'OSPF sur **R-1** : 

```
 Routing Process "ospf 1" with ID 1.1.1.1
 Start time: 00:00:16.025, Time elapsed: 00:29:54.008
 Reference bandwidth unit is 100 mbps
    Area BACKBONE(0)
        Number of interfaces in this area is 3
        Area has no authentication
        SPF algorithm last executed 00:08:04.649 ago
        SPF algorithm executed 7 times
        Area ranges are
        Number of LSA 6. Checksum Sum 0x013FB5
        Number of opaque link LSA 0. Checksum Sum 0x000000
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0
```

Les informations obtenues sur R-1 sont assez similaires par rapport à R-3, mise à part que son ID de routeur est 1.1.1.1.

#### Vérification des tables de routage

R-1 : 
```
Gateway of last resort is 10.10.10.6 to network 0.0.0.0

O*E2  0.0.0.0/0 [110/1] via 10.10.10.6, 00:12:17, GigabitEthernet0/3
      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C        10.10.10.0/30 is directly connected, GigabitEthernet0/2
L        10.10.10.1/32 is directly connected, GigabitEthernet0/2
C        10.10.10.4/30 is directly connected, GigabitEthernet0/3
L        10.10.10.5/32 is directly connected, GigabitEthernet0/3
C        10.10.10.8/30 is directly connected, GigabitEthernet0/1
L        10.10.10.9/32 is directly connected, GigabitEthernet0/1
O        10.10.10.12/30 [110/2] via 10.10.10.6, 00:12:17, GigabitEthernet0/3
                        [110/2] via 10.10.10.2, 00:14:34, GigabitEthernet0/2
O        10.10.10.16/30 [110/2] via 10.10.10.2, 00:33:04, GigabitEthernet0/2
```

R-1 reçoit bien la route par défaut depuis le routeur R-3, et reçoit bien les routes qu'il ne connaît pas (10.10.10.12, réseau entre R-2 et R-3 et 10.10.10.16, réseau entre R-2 et R-GW-2.

R-2 : 
```
Gateway of last resort is 10.10.10.14 to network 0.0.0.0

O*E2  0.0.0.0/0 [110/1] via 10.10.10.14, 00:21:32, GigabitEthernet0/0
      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C        10.10.10.0/30 is directly connected, GigabitEthernet0/2
L        10.10.10.2/32 is directly connected, GigabitEthernet0/2
O        10.10.10.4/30 [110/2] via 10.10.10.14, 00:40:32, GigabitEthernet0/0
                       [110/2] via 10.10.10.1, 00:19:15, GigabitEthernet0/2
O        10.10.10.8/30 [110/2] via 10.10.10.1, 00:18:52, GigabitEthernet0/2
C        10.10.10.12/30 is directly connected, GigabitEthernet0/0
L        10.10.10.13/32 is directly connected, GigabitEthernet0/0
C        10.10.10.16/30 is directly connected, GigabitEthernet0/1
L        10.10.10.17/32 is directly connected, GigabitEthernet0/1
```

R-2 reçoit bien la route par défaut depuis le routeur R-3, et reçoit bien les routes qu'il ne connaît pas (10.10.10.4, réseau entre R-1 et R-3 et 10.10.10.8, réseau entre R-1 et R-GW-1)

R-3 : 
```
Gateway of last resort is 192.168.122.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.168.122.1
      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O        10.10.10.0/30 [110/2] via 10.10.10.13, 00:23:03, GigabitEthernet0/0
                       [110/2] via 10.10.10.5, 00:20:45, GigabitEthernet0/3
C        10.10.10.4/30 is directly connected, GigabitEthernet0/3
L        10.10.10.6/32 is directly connected, GigabitEthernet0/3
O        10.10.10.8/30 [110/2] via 10.10.10.5, 00:20:23, GigabitEthernet0/3
C        10.10.10.12/30 is directly connected, GigabitEthernet0/0
L        10.10.10.14/32 is directly connected, GigabitEthernet0/0
O        10.10.10.16/30 [110/2] via 10.10.10.13, 00:23:03, GigabitEthernet0/0
      192.168.122.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.122.0/24 is directly connected, GigabitEthernet0/1
L        192.168.122.76/32 is directly connected, GigabitEthernet0/1
```

R-3 possède bien une route par défaut et la diffuse bien. Il reçoit aussi les routes qu'il ne connaît pas, réseau R-2 -- R-1, R-1 -- R-GW-1, et R-2 -- R-GW-2.

Vérification des voisions OSPF de R-3 : 
```
Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:35    10.10.10.5      GigabitEthernet0/3
2.2.2.2           1   FULL/DR         00:00:33    10.10.10.13     GigabitEthernet0/0
```

R-3 connaît bien ses voisins.

#### Vérifcation par des tests de connectivités sur R-GW-1 et R-GW-2 

Afin que les routeurs R-GW-1 et R-GW-2 puissent communiquer ensemble, il leur faut configurer un route par défaut vers leurs routeurs respectifs.

Pour R-GW-1 : `ip route 0.0.0.0 0.0.0.0 10.10.10.9`
Pour R-GW-2 : `ip route 0.0.0.0 0.0.0.0 10.10.10.17`

Test de connectivité entre R-GW-1 et R-GW-2 : 
```
R-GW-2#ping 10.10.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/7 ms
```

Test de connectivité entre R-GW-1 et R-3 : 
```
R-GW-1#ping 10.10.10.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/5 ms

R-GW-1#ping 10.10.10.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.14, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
```

:::success
Le protocole de routage OSPF a bien été mis en place et est fonctionnel.
:::

### Configuration de l'interface Gi0/1 de R3

L’interface Gi0/1 du routeur R-3 permet l’interconnexion du réseau du FAI à celui du serveur sur lequel est installé GNS3. C’est l’élément Cloud qui réalise le « Bridge » entre les 2 interfaces et qui permet ainsi au réseau du FAI d’être connecté à Internet. ». L’adresse IP de Gi0/1 doit donc se trouver dans le même réseau que l’interface physique ens18 du serveur. Vous utiliserez une adresse IP disponible prise dans ce réseau pour configurer Gi0/1. De plus, pour permettre aux hôtes des différents réseaux déployés dans l’environnement de simulation d’accéder à Internet, un mécanisme de translation d’adresse (NAT) doit être configuré sur le routeur R-3.

On commence donc par cherche l'adresse réseau de notre serveur GNS3, à l'aide de la commande `ip a` : 

![image](https://hackmd.io/_uploads/Hk9XJ3p4A.png)

On peut s'aperçevoir que l'adresse réseau du serveur GNS est : 172.16.44.0/24. On choisit une adresse IP dans ce réseau au hasard, dans notre cas 172.16.44.22 /24, on vérifie d'abord si l'adresse n'est pas prise en effectuant un ping : 

Capture d'écran du ping non fonctionnel

Après avoir confirmé que l'adresse IP n'est pas prise, on la configure sur l'interface Gi0/1 de R3 : 

```
conf t
int Gi0/1
ip addr 172.16.44.22 255.255.255.0
no shutdown
end
```

On vérifie la bonne configuration de l'interface, à l'aide de la commande `sh ip int br` : 

```
Interface                  IP-Address      OK? Method Status                Prot                                                                         ocol
GigabitEthernet0/0         10.10.10.14     YES NVRAM  up                    up                                                                           
GigabitEthernet0/1         172.16.44.22    YES manual up                    up                                                                           
GigabitEthernet0/2         unassigned      YES unset  down                  down                                                                         
GigabitEthernet0/3         10.10.10.6      YES NVRAM  up                    up  
```

:::success
L'interface Gi0/1 de R3 est bien configuré. :+1: 
:::

### Mise en place du NAT surchargé sur le routeur R3

Afin de permettre aux routeurs R-1 et R-2 d'accéder à internet, on configure du NAT surchargé sur R-3.

On commance par affectuer quelles ports sont interne et externe. Dans notre cas, les interfaces internes sont Gi0/3 et Gi0/0, pour ce qui est de l'adresse externe c'est Gi0/0 : 

```
conf t
int Gi0/3
ip nat inside
int Gi0/0
ip nat inside
int Gi0/1
ip nat outside
end
```

Ensuite on créer une ACL qui spécifie le flux réseau devant être translaté. On utilisera une ACL standard : 

```
ip access-list standard Int-List
permit 10.10.10.0 0.0.0.255
```

L'avant dernière étape est l’activation du NAT surchargé sur le routeur pour permettre la translation des réseaux définis dans l’ACL vers l’adresse publique de l’interface de sortie. Voici la commande utilisée : 

`ip nat inside source list Int-List interface Gi0/1 overload`

La dernière étape est d'ajouter une route par défaut vers la passerelle de R-3 `172.16.44.254`, afin de pouvoir sortir sur internet : 

```
ip route 0.0.0.0 0.0.0.0 172.16.44.254
```

On vérifie maintenant qu'à partir de R-1 et R-2, que l'on obtient une connectivité avec un serveur de l'Internet (8.8.8.8), et on visualisera la table de translations d'adresse : 

Test de connectivité entre R-GW-1 et le serveur DNS de Google : 
```
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/12/17 ms
```

Table de translations d'adresse sur R-3 : 
```
Pro Inside global      Inside local       Outside local      Outside global
icmp 172.16.44.22:1    10.10.10.5:1       8.8.8.8:1          8.8.8.8:1
```

Test de connectivité entre R-GW-2 et le serveur DNS de Google : 
```
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/13/14 ms
```

Table de translations d'adresse sur R-3 : 
```
Pro Inside global      Inside local       Outside local      Outside global
icmp 172.16.44.22:0    10.10.10.13:0      8.8.8.8:0          8.8.8.8:0
```

Les routeurs R-GW-1 et R-GW-2 sont des routeurs d’extrémité (edge router) respectivement pour le Siège et la Filiale de l’entreprise. A ce stade, ces routeurs possèdent un accès vers l’extérieur mais pas les hôtes du réseau interne. Ces derniers ont un adressage privé et ne peuvent donc pas envoyer de requêtes vers les réseaux externes. Un mécanisme de translation d’adresse doit être configuré sur le routeur R-GW-1 et R-GW-2.

### Configuration du mécanisme de translation d'adresse (NAT) sur le routeur R-GW-1 puis sur le routeur R-GW-2

On configure donc le NAT surchargé sur R-GW-1 : 
```
conf t
int Gi0/0
ip nat inside
int Gi0/1
ip nat outside
exit
ip access-list standard Int-List
permit 172.16.0.0 0.0.255.255
exit
ip nat inside source list Int-List interface Gi0/1 overload
end
```

On configure donc le NAT surchargé sur R-GW-2 : 
```
conf t

int Gi0/2
ip nat inside
int Gi0/2.130
ip nat inside
int Gi0/2.140
ip nat inside
int Gi0/2.170
ip nat inside

int Gi0/1
ip nat outside
exit

ip access-list standard Int-List
permit 192.168.86.0 0.0.0.255
exit

ip nat inside source list Int-List interface Gi0/1 overload

end
```

On vérifie que l'on peut  atteindre les hôtes de l’Internet à partir des ordinateurs situés dans les différents VLAN : 

Test de connectivité entre le VLAN 170 et internet, et analyse de la table de translations : 
```
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=110 time=26.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=110 time=29.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=25.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=110 time=20.4 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=110 time=33.4 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=110 time=26.8 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5009ms
rtt min/avg/max/mdev = 20.444/26.967/33.351/3.976 ms
```

```
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.10.10.10:31138 172.16.2.1:31138   8.8.8.8:31138      8.8.8.8:31138
icmp 10.10.10.10:25051 172.16.3.1:25051   8.8.8.8:25051      8.8.8.8:25051
```

#### Analyse du Ping

Le ping a été exécuté à partir d'un hôte dans le VLAN 170 vers l'adresse IP 8.8.8.8 pour tester la connectivité Internet. Voici ce que nous pouvons déduire des résultats : 

- **Résultats du Ping** : Les réponses reçues indiquent qu'il n'y a pas de perte de paquets, avec six paquets envoyés et six reçus. Ceci confirme une bonne connectivité entre le VLAN 170 et Internet.

- **Temps de Réponse** : 
    - **Minimum** : 20.444 ms
    - **Maximum** : 33.351 ms
    - **Moyenne** : 26.967 ms
    - **Écart-Type** : 3.976 ms

#### Analyse de la Table de Translations

- **Inside Local** : Adresse IP privée à l'intérieur du réseau. Ici, les adresses 172.16.2.1 et 172.16.3.1 sont traduites, ce qui indique qu'il y a au moins deux sous-réseaux différents à l'intérieur du VLAN ou du réseau interne.
- **Inside Global** : Adresse IP utilisée pour représenter les adresses locales Inside Local sur Internet.
- **Outside Local et Outside Global** : Ces deux colonnes contiennent l'adresse de destination (8.8.8.8), indiquant que les paquets sont dirigés vers le même serveur externe.

Test de connectivité entre le VLAN 130 et internet, et analyse de la table de translations : 
```
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=111 time=22.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=111 time=22.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=111 time=25.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=111 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=111 time=18.9 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=111 time=17.6 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 17.407/20.636/25.476/2.924 ms
```

```
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.10.10.18:16674 192.168.86.1:16674 8.8.8.8:16674      8.8.8.8:16674
```

- **Résultats du Ping** : Les réponses reçues indiquent qu'il n'y a pas de perte de paquets, avec six paquets envoyés et six reçus. Ceci confirme une bonne connectivité entre le VLAN 170 et Internet.

- **Temps de Réponse** : 
    - **Minimum** : 17.407 ms
    - **Maximum** : 25.476 ms
    - **Moyenne** : 20.636 ms
    - **Écart-Type** : 2.924 ms

#### Analyse de la Table de Translations

- **Inside Local** : L'adresse 192.168.86.1 représente un appareil ou un hôte dans le VLAN 130. C'est une adresse IP typiquement utilisée dans les réseaux domestiques ou de petites entreprises.
- **Inside Global** : L'adresse 10.10.10.18 est utilisée comme adresse publique pour l'hôte interne quand il accède à Internet.
- **Outside Local et Outside Global** : Les deux adresses sont 8.8.8.8:16674, ce qui indique que le paquet est destiné au serveur Google DNS et que le port 16674 est utilisé pour cette session ICMP spécifique, probablement pour garder une trace unique de la session dans les dispositifs de réseau.

Le serveur situé dans la DMZ n'est pas accessible à partir des ordinateurs de Filiale, puisque le routeur R-GW-2, ne connait pas la route vers le réseau 172.16.0.0/16.

## Partie 2 - Mettre en place des services réseaux

### Installation du service HTTP

Pour installer le service HTTP, il nous faut apache2 : `apt install apache2 -y`

### Rendre le service HTTP disponible au réseau filiale

Afin de rendre le service HTTP disponible dans le réseau Filiale, on réalise du NAT statique sur le port 80. Le but de cela, est de faire en sorte que lorsque qu'un ordinateur du réseau Filiale veut accéder au service HTTP du serveur, il rendre l'adresse IP publique du réseau d'entreprise (10.10.10.10) avec le port web (80), et le routeur, à l'aide du NAT statique le redirige vers le serveur WEB.

Pour cela, on utilise la commande suivante sur le routeur R-GW-1 : 

`ip nat inside source static tcp 172.16.0.1 80 10.10.10.10 80`

- **Type de NAT** : La commande configure une NAT statique, ce qui signifie que l'adresse IP interne sera toujours traduite en la même adresse IP externe, et vice versa, de manière constante.
- **Direction et type de trafic** : `ip nat inside source` indique que la source du trafic qui entre de l'intérieur (inside) du réseau vers l'extérieur sera modifiée. La mention tcp spécifie que cette règle s'applique uniquement aux paquets TCP.
- **Adresse IP et port interne** : 172.16.0.1 80 précise que le trafic provenant de l'adresse IP interne 172.16.0.1 et du port TCP 80 (habituellement utilisé pour le trafic HTTP) sera traduit.
- **Adresse IP et port externe** : 10.10.10.10 80 spécifie que l'adresse IP source interne 172.16.0.1 sur le port 80 sera traduite en adresse IP 10.10.10.10 sur le port 80 lorsqu'elle traverse le routeur pour accéder à des réseaux externes.

Cela permet aux serveurs ou services qui s'exécutent sur l'adresse interne 172.16.0.1 d'être accessibles de l'extérieur en utilisant l'adresse 10.10.10.10.

#### Vérification du fonctionnement du NAT statique

Pour vérifier si le NAT statique fonctionne, on peut install links (un navigateur web en ligne de commande) et tenter de se connecter sur R-GW--1 (10.10.10.10) : 

![image](https://hackmd.io/_uploads/rkRKSnXB0.png)

:::success
Le NAT statique est fonctionnelle, et la page WEB est accessible depuis le réseau Filiale.
:::

### Installation du service DNS

#### Installation de BIND9

Pour ce qui s'agit du serveur DNS, on utilise le logiciel Bind9. On l'installe avec la commane `apt install bind9 -y`.

#### Création de la zone directe

Dans un premier temps, on va configurer la zone directe et inverse. On commence donc par modifier le fichier `/etc/bind/named.conf.local`, et y ajouter : 

```
zone "netcom.local" {
    type master;
    file "/etc/bind/db.netcom.local";
};

zone "86.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192.168.86";
};

zone "16.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.172.16";
};

zone "1.1.1.in-addr.arpa" {
    type master;
    file "/etc/bind/db.1.1.1";
};
```

1. **zone "netcom.local"** : 
    -  Cette ligne commence la définition pour la zone DNS appelée "netcom.local". C'est le domaine de premier niveau pour lequel ce serveur DNS servira des informations d'enregistrement.

2. **type master** : 
    -  Indique que ce serveur DNS est le serveur principal (master) pour la zone "netcom.local". En tant que serveur master, il détient le fichier de données autoritaire pour cette zone et peut répondre aux requêtes DNS concernant ce domaine.

3. **file "/etc/bind/db.netcom.local"** : 
    - Spécifie le chemin du fichier sur le système de fichiers où les enregistrements de la zone sont stockés. Ce fichier contient tous les enregistrements DNS nécessaires pour la zone, tels que les enregistrements A (adresses IP), MX (mail exchange), CNAME (canonical name), etc.

4. **allow-update { none; }:** : 
    - Cette directive configure la politique de mise à jour dynamique pour la zone. Ici, il est réglé sur none, ce qui signifie que les mises à jour dynamiques sont interdites. BIND supporte les mises à jour dynamiques des zones DNS, ce qui permet à d'autres serveurs autorisés de modifier les enregistrements DNS de manière programmatique sans intervention manuelle. Cependant, dans ce cas, les mises à jour dynamiques sont désactivées pour renforcer la sécurité et éviter des modifications non autorisées.

#### Configuration de Bind

Afin de permettre aux requêtes non résolues d'être transmises au DNS public de Google, on modifie le fichier `/etc/bind/named.conf.options`, et on y ajoute : 

```
options {
     directory "/var/cache/bind";
     
     forwarders {
             8.8.8.8;
     };
     
     listen-on { any; };
     recursion yes;
     allow-recursion { 127.0.0.1; any; };
     allow-query { any; };
     auth-nxdomain no;
     dnssec-validation auto;
     listen-on-v6 { any; };
};

```

#### Construction des fichiers de zone

On construit le fichier de zone directe `db.netcom.local`, comme ce qui suit : 
```
;
; BIND data file for netcom.local
;
$TTL    604800
@       IN      SOA     ns1.netcom.local. admin.netcom.local. (
                              2023060601 ; Serial
                                   604800 ; Refresh
                                    86400 ; Retry
                                  2419200 ; Expire
                                   604800 ) ; Negative Cache TTL
;
@       IN      NS      ns1.netcom.local.
ns1     IN      A       172.16.0.1
www     IN      CNAME   ns1

; Enregistrements pour les hôtes des différents VLANs
rgw1           IN      A       1.1.1.2
vpc1           IN      A       172.16.3.1
vpc2           IN      A       172.16.3.2
sw1            IN      A       172.16.3.3
sw2            IN      A       172.16.3.4
mls1           IN      A       172.16.3.254
vpc3           IN      A       172.16.1.1
vpc4           IN      A       172.16.2.1
vpc5           IN      A       192.168.86.1
vpc6           IN      A       192.168.86.129
sw3            IN      A       192.168.86.162
rgw2           IN      A       192.168.86.166
```

Ensuite on finit par construite les zones inversées : 

db.172.16 : 

```
;
; BIND reverse data file for 172.16.0.0/16
;
$TTL    604800
@       IN      SOA     ns1.netcom.local. admin.netcom.local. (
                              2023060601 ; Serial
                                   604800 ; Refresh
                                    86400 ; Retry
                                  2419200 ; Expire
                                   604800 ) ; Negative Cache TTL
;
@       IN      NS      ns1.netcom.local.
1.0     IN      PTR     ns1.netcom.local.
1.1     IN      PTR     vpc3.netcom.local.
1.2     IN      PTR     vpc4.netcom.local.
1.3     IN      PTR     vpc1.netcom.local.
2.3     IN      PTR     vpc2.netcom.local.
3.3     IN      PTR     sw1.netcom.local.
4.3     IN      PTR     sw2.netcom.local.
```

db.192.168.86 : 
```
;
; BIND reverse data file for 192.168.86.0/24
;
$TTL    604800
@       IN      SOA     ns1.netcom.local. admin.netcom.local. (
                              2023060601 ; Serial
                                   604800 ; Refresh
                                    86400 ; Retry
                                  2419200 ; Expire
                                   604800 ) ; Negative Cache TTL
;
@       IN      NS      ns1.netcom.local.
1       IN      PTR     vpc5.netcom.local.
129     IN      PTR     vpc6.netcom.local.
162     IN      PTR     sw3.netcom.local.
166     IN      PTR     rgw2.netcom.local.
```

et enfin, db.1.1.1 : 
```
;
; BIND reverse data file for 1.1.1.0/24
;
$TTL    604800
@       IN      SOA     ns1.netcom.local. admin.netcom.local. (
                              2023060601 ; Serial
                                   604800 ; Refresh
                                    86400 ; Retry
                                  2419200 ; Expire
                                   604800 ) ; Negative Cache TTL
;
@       IN      NS      ns1.netcom.local.
2       IN      PTR     rgw1.netcom.local.
```