# 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
## 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' :
:::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 :
Capture Wireshark des communications entre les VPCs :
:::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 :
#### 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 :
:::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 :
#### 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 :
Ping entre VLAN 100 -> VLAN 120 :
Ping entre VLAN 100 -> VLAN 170 :
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 :
On peut voir que toutes les requêtes porte l'étiquette **ID: 100** sur Gi2/0 de MLS-1 (celle du VLAN100).
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 :
#### 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 :
Sur MLS-1 :
Sur SW-1 :
Sur SW-2 :
:::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` :
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) :
:::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.
```
Sign in with Wallet
Connect another wallet