SAE 2.01

Q1.

| Nom du réseau | Adresse IP | Masque | Passerelle | ID VLAN | Ports associés |
| ---------------- | ----------------- | --------------- | -------------- | -------- | -------------------------------- |
| DMZ | 172.16.0.0/24 | 255.255.255.0 | 172.16.0.254 | VLAN 100 | Gi0/0-3 de SW-1 |
| R&D | 172.16.1.0/24 | idem | 172.16.1.254 | VLAN 110 | Gi3/0 de SW-2 |
| PROD | 172.16.2.0/24 | idem | 172.16.2.254 | VLAN 120 | Gi3/1 de SW-2 |
| ADMIN | 172.16.3.0/24 | idem | 172.16.3.254 | VLAN 170 | Gi1/0-3 de SW-1 et 2 |
| COMPTA | 192.168.86.0/25 | 255.255.255.128 | 192.168.86.126 | VLAN 130 | Gi0/0-3 de SW-3 |
| VENTE | 192.168.86.128/27 | 255.255.255.224 | 192.168.86.158 | VLAN 140 | Gi1/0-3 de SW-3 |
| ADMIN | 192.168.86.160/29 | 255.255.255.248 | 192.168.86.166 | VLAN 170 | Gi3/0-3 de SW-3 et Gi2/0 (trunk) |
| FAI R-GW-1 - R-1 | 10.10.10.0/30 | 255.255.255.252 | 10.10.10.2 | | |
| FAI R1-R2 | 10.10.10.4/30 | 255.255.255.252 | 10.10.10.6 | | |
| FAI R1-R3 | 10.10.10.8/30 | 255.255.255.252 | 10.10.10.10 | | |
| FAI R2-R3 | 10.10.10.12/30 | 255.255.255.252 | 10.10.10.14 | | |
| FAI R-2 - R-GW-2 | 10.10.10.16/30 | 255.255.255.252 | 10.10.10.18 | | |

Q3. Nous attribuons les adresses IP aux différents hôtes des réseaux selon le schéma de topologie ci-dessous :


Dans le VLAN 170, nous attribuons à l'interface de gestion SVI de SW-3 l'adresse 192.168.86.161/29 et à celle de R-GW-2 l'adresse 192.168.86.166/29, qui constitue aussi l'adresse de passerelle du VLAN 170. Nous procédons de façon similaire pour le réseau siège.

Q4. Pour configurer les VLAN sur SW-3, nous saisissons la commande vlan suivie du numéro du VLAN, puis nous lui attribuons un nom grâce à la commande name suivie du nom défini dans la topologie. Nous configurons les ports d'accès aux différents VlAN depuis le mode de configuration des interfaces (int suivie du nom et du type de l'interface, ou int range pour séléctionner plusieurs interfaces, tel que défini dans la topologie), et nous passons le port en mode d'accès grâce à la commande switchport mode access, puis switchport access vlan suivie du numéro du VLAN, pour associer le ou les ports au VlAN. Enfin, nous saisissons no shut afin que les interfaces soient actives. Nous configurons également le lien d'agrégation trunk (trames etiquetees 802.1q) sur le port Gi2/0 de SW-3. Pour ce faire, nous entrons dans le mode de configuration de l'interface Gi2/0, puis nous saisissons la commande switchport trunk encapsulation dot1q, afin que le port prenne en charge l'activation du mode trunk (la commande est requise qur un commutateur de couche 3 tel que ceux utilisés sur GNS3, mais pas sur un commutateur de couche 2), puis nous saisissons switchport mode trunk afin d'activer le lien d'agrégation sur le port. Nous choisissons ensuite le VLAN 170 comme VLAN natif sur lequel les trames étiquetées 802.1q seront acheminées, grâce à la commande switchport trunk native vlan 170. Enfin, nous activons l'interface en saisissant no shut.

Q5. Nous configurons ensuite le routage inter-VLAN sur le routeur R-GW-2. Pour ce faire, nous activons l'interface Gi0/2 (reliée à l'interface Gi2/0 de SW-3) avec la commande no shut, puis nous créons les sous interfaces Gi0/2.130, Gi0/2.140 et Gi0/2.170 (commande int suivie de la sous interface). Nous saisissons la commande encapsulation dot1q 130 pour la sous interface Gi0/2.130 (respectivement 140 et 170), afin que l'interface traite les trames étiquetées 802.1q et que le routeur route les paquets encapsulés dedans. Nous attribuons ensuite à chaque sous interface la dernière adresse IP disponible de la plage de chaque VLAN lui correspondant (commande ip address suivie de l'adresse et du masque de sous réseau). Cette adresse IP constituera l'adresse de passerelle des VLAN. Concernant la sous interface Gi0/2.170, nous précisons qu'elle doit prendre en charge les trames du VLAN natif 170, en ajoutant le mot clé "native" à la fin de la commande encapsulation dot1q (encapsulation dot1q 170 native). Le routage inter-VLAN est alors fontionnel.

Q6. Nous réalisons une capture Wireshark entre Gi2/0 de SW-3 et Gi0/2 de R-GW-2, et nous voyons que l'encapsulation 802.1Q est active


Q7. Nous configurons le commutateur SW-3 et le routeur R-GW-2 afin qu'il soit possible de les administrer en SSH. Pour ce faire, nous attribuons une adresse IP à l'interface SVI (Switch Virtual Interface) de SW-3. C'est l'interface du VLAN 170 qui jouera le rôle de SVI, donc nous lui attribuons l'adresse IP 192.168.86.161/29 (cf. topologie) en entrant dans le mode de configuration d'interface (int vlan 170) puis en saisissant la commande ip address 192.168.86.161 255.255.255.248. Nous configurons également l'adresse de passerelle par défaut du commutateur afin que celui-ci puisse être joignable des autres réseaux et VLAN, par la commande ip default-gateway 192.168.86.166 (adresse de passerelle du VLAN 170). Comme SW-3 est un commutateur de couche 3, nous désactivons le routage (no ip routing) afin que l'adresse de passerelle soit prise en compte. Nous nous occupons ensuite de la configuration du service SSH. Pour ce faire, nous créons un nom de domaine IP hôte VLAN170 grâce à la commande ip domain name VLAN170. Nous générons ensuite des clés RSA en utilisant un modulus de 4096 bits, grâce à la commande crypto key generate rsa (puis saisir 4096 et entrée). Nous configurons les actifs pour qu'ils exécutent SSHv2, grâce à la commande ip ssh version 2, et nous ajoutons un compte d’utilisateur pour l’administration ayant pour nom d’utilisateur admin et comme mot de passe gtrnet, grâce à la commande username admin secret gtrnet. Nous utilisons l’utilisateur local et n’autorisons que les connexions distantes SSH (pas Telnet), grâce aux commandes suivantes :

line vty 0 4  
login local 
transport input ssh 

Nous pouvons visualiser les connexions SSH avec show ip ssh ou show ssh. Nous pouvons également attribuer un mot de passe à la console du commutateur, grâce aux commandes suivantes :

line console 0
password gtrnet (ou autre mdp)
login

Q8. Après avoir effectué ces étapes, nous saisissons depuis VPC5 ou VPC6 la commande ssh 192.168.86.161 (ou .166) pour tester la connexion SSH, cependant nous obtenons l'erreur suivante :


En effet, l'algorithme d'échange des clés SSH n'est pas le même entre les machines Linux et les actifs Cisco. Pour résoudre ce problème, nous ajoutons les lignes suivantes au fichier /etc/ssh/ssh_config :

Host *
    KexAlgorithms +diffie-hellman-group-exchange-sha1
    Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
    PubkeyAcceptedAlgorithms +ssh-rsa
    HostkeyAlgorithms +ssh-rsa

(source : https://unix.stackexchange.com/questions/615987/ssh-to-cisco-device-fails-with-diffie-hellman-group1-sha1 )

Nous réessayons ensuite de nous connecter avec le nom d'utilisateur admin (cf. Q7) grâce à la commande ssh -l admin 192.168.86.161 , et nous voyons que la connexion s'effectue avec succès :


Q10. Nous configurons le protocole VTP sur les commutateurs SW-1, SW-2 et MLS-1 du réseau siège. Pour ce faire, nous créons d'abord les VLAN et affectons les ports à ces derniers, selon la procédure vue à la Q4. Nous configurons les ports Gi2/0 de MLS-1 et SW-1, et Gi2/1 de MLS-1 et SW-2, en mode trunk afin que les trames étiquetées soient acheminées au routeur MLS-1 de couche 3 qui se chargera du routage inter-VLAN, ainsi que pour assurer l'acheminement des trames VTP. Nous activons le protocole VTP et passons les commutateurs SW-1 et SW-2 en mode client VTP, afin qu'ils reçoivent les VLAN depuis MLS-1 sur lequel ils seront créés, grâce à la commande vtp mode client. Nous passons le commutateur MLS-1 en mode serveur VTP afin qu'il déploie sur les clients VTP les VLAN, grâce à la commande vtp mode server. Nous choisissons le nom de domaine VTP "siege" ainsi que le mot de passe VTP gtrnet. Nous appliquons ce nom de domaine et ce mot de passe sur les 3 commutateurs grâce aux commandes vtp domain siege , et vtp password gtrnet.

Q12. Nous configurons le routage inter-VLAN sur le commutateur de couche 3, simplement en saisissant la commande ip routing, afin que le routage entre les interfaces (physiques et virtuelles) soit effectué. Une SVI (Switch Virtual Interface) est une interface virtuelle, le plus souvent reliée à un VLAN, et qui sert à administrer le commutateur à distance via des protocoles applicatifs (couche 7) tels que SSH. Elles possèdent une adresse IP afin d'être accessible sur les réseaux IP.

Q13. Nous réalisons un test de connectivité entre le serveur du VLAN DMZ et la machine VPC3 du VLAN R&D, et nous réalisons en même temps une capture Wireshark entre les commutateurs SW-1 et MLS-3, ce qui nous permet de valider l'encapsulation 802.1Q (nous voyons ci-dessous que la trame ethernet porte une étiquette 802.1Q).


Q14. Nous configurons l'interconnexion entre MLS-1 et R-GW-1. Pour ce faire, nous créons le nouveau sous-réseau 172.16.4.0/24, servant spécifiquement au routage entre MLS-1 et R-GW-1, et nous passons l'interface Gi0/0 de MLS-1 en couche 3, par la commande no switchport, afin que cette interface prenne en charge l'attribution d'une adresse IP. Nous attribuons ensuite l'adresse IP 172.16.4.1/24 à l'interface Gi0/0 de MLS-1, et l'adresse IP 172.16.4.254/24 à l'interface Gi0/0 de R-GW-1. Nous créons ensuite la route par défaut 0.0.0.0/0 pointant sur le prochain saut 172.16.4.254, sur MLS-1, afin que les paquets à destination des réseaux externes, non connus de la table de routage de MLS-1, soient envoyés à R-GW-1 (interface Gi0/0) puis sur les réseaux externes. La commande à saisir sur MLS-1 est donc ip route 0.0.0.0 0.0.0.0 172.16.4.254. Nous créons également une route résumée sur R-GW-1 vers le réseau résumé 172.16.0.0/16 (résumant l'ensemble des réseaux du siège) et pointant sur le prochain saut 172.16.4.1 (interface Gi0/0 de MLS-1), afin que les paquets à destination des VLAN du siège soient correctement acheminés par ces derniers par R-GW-1.

Q15. Nous affichons ci-dessous la table de routage de MLS-1 :


Nous voyons que la route statique par défaut 0.0.0.0/0 est correctement configurée et pointe bien sur R-GW-1 (adresse IP 172.16.4.254/24), et que l'ensemble des VLAN sont des réseaux directments connectés à MLS-1, ce qui est cohérent par rapport à la toplogie mise en place.
Nous affichons également la table de routage de R-GW-1 et, comme nous le voyons ci-dessous, le routeur possède la route statique définie précédemment, vers le réseau 172.16.0.0/16 résumant tous les VLAN et pointant sur l'interface Gi0/0 de MLS-1, d'adresse 172.16.4.1/24, ainsi que les réseaux directements connectés 172.16.4.0/24 (liaison MLS-1 / R-GW-1) et 10.10.10.0/30 (liaison R-GW-1 / R1 du FAI) :


Q16. Nous configurons le protocole SSH sur l'ensemble des actifs réseaux du siège, en suivant la procédure décrite à la Q7. Nous ne désactivons pas le routage ni ne configurons d'adresse de passerelle sur MLS1 car il s'agit d'un commutateur de couche 3 possédant déjà les routes vers les différents VLAN, mais nous le faisons sur SW-1 et 2 avec l'adresse de passerelle du VLAN 170 172.16.3.254/24, car ils ne possèdent pas de table de routage et doivent savoir où acheminer les paquets à destination d'un autre réseau que celui de la SVI (VLAN 170), et être joignables depuis ces autres réseaux pour la configuration en SSH. Nous choisissons le nom de domaine IP VLAN170RGW1 pour R-GW-1, VLAN170MLS1 pour MLS1, VLAN170SW1 pour SW-1 et VLAN170SW2 pour SW-2.

Q18. Nous configurons l'adresse IP 10.10.10.1/30 sur l'interface externe (Gi0/1) du routeur R-GW-1.

Q20. Nous activons le protocole OSPF sur les routeurs grâce à la ocmmande router ospf 1 (processus ospf 1). Comme il y a une zone de backbone entre R1, R2 et R3, nous choisissons l'aire de routage 0 pour cette zone (1 pour R-GW-1 / R1 et 2 pour R-2 / R-GW-2), et nous définissons les identifiants des routeurs en x.x.x.x avec x le numéro du routeur, par la commande router-id x.x.x.x et nous autorisons les différents réseaux de la zone de routage, à être diffusés dans les paquets LSA. Nous saisissons pour cela la commande network (adresse IP masque de sous réseau) area (numéro d'aire). Nous ne diffusons pas le réseau reliant le routeur R3 au réseau de la VM, car il ne fait pas partie de la zone de routage. De plus, les routeurs R-GW-1 et R-GW-2 ne participant pas au routage OSPF, nous désactivons la diffusion des paquets LSA sur ces interfaces grâce à la commande passive interface suivie du type et du numéro de l'interface. Nous propageons la route par défaut depuis R3 grâce à la commande default-information originate, et nous sauvegardons la configuration OSPF grâce à la commande clear ip ospf process 1. Les routeurs R1, R2 et R3 sont des routeurs ABR car ils relient plusieurs aires de routage OSPF, et R3 est un routeur ASBR car il est à la frontière du domaine de routage OSPF.

Q21. Nous affichons ci-dessous la table de routage de R-1 :


Nous voyons que la totalité des réseaux de la zone OSPF sont présents dans la table de routage. Les réseaux reliant R1 à R2 et à R3 sont directements connectés, et le réseau 10.10.10.12/30 (reliant R-2 à R-3) est acquis par le protocole OSPF avec une métrique de 2 (coût de 1 pour atteindre R2 ou R3 puis coût de 1 pour atteindre l'interface du réseau de destination). La métrique est par ailleurs égale pour les 2 prochains sauts 10.10.10.10/30 et 10.10.10.6/30, les deux apparaissent donc sur la même route, mais le premier a été configuré en OSPF avant le second, et apparaît donc en haut de la liste. Il y a répartition de charge entre les 2 prochains sauts pour cette route, avec un envoi des paquets en priorité vers 10.10.10.10/30 et vers le second (10.10.10.6/30) si le premier est encombré. Le réseau 10.10.10.16/30, avec une métrique de 2 (coût de 1 vers 10.10.10.6/3 soit l'interface Gi0/2 de R-2 puis coût de 1 vers l'interface de destination du réseau 10.10.10.16/30), est présent, avec l'acronyme IA signifiant inter area soit un réseau situé dans une autre aire de routage.
Nous observons un résultat similaire pour R2 et R3 tel que nous le voyons ci-dessous :

7


Q22. Pour vérifier si un message ICMP passe par R3 alors qu'il est destiné à R-GW-2, nous réalisons une capture de flux entre R1 et R3 et vérifions si des paquets ICMP d'adresse source celle de R-GW-1 et d'adresse de destination celle de R-GW-2, transitent sur cette liaison.

Q23. Nous choisissons l'adresse IP 172.16.17.253/24 prise dans le réseau de l'interface ens18 du serveur, puis nous l'attribuons à l'interface Gi0/1 de R-3. Nous créons également la route par défaut vers l'adresse de passerelle du réseau du serveur GNS3 (172.16.17.254/24).

Q24. Nous configurons la translation d'adresse sur le routeur R-3, en passant les interfaces Gi0/0 et Gi0/3 en ip nat inside, et l'interface Gi0/1 en ip nat outside. Nous créons une ACL permettant au réseau résumé 10.10.10.0/27 (résumant les interconnexions du FAI), d'être translaté, grâce à la commande access-list permit 10.10.10.0 0.0.0.31 , puis nous saisissons la commande ip nat inside source list 1 interface Gi0/1 overload, afin de mettre en place une translation NAT dynamqiue avec surcharge, permettant à tous les paquets de sortir sur Internet avec la même adresse IP mais avec un port TCP/UDP différent et ainsi les différentier.

Q25. Nous affichons la table de translation d'adresses de R3, après avoir fait un test de connectivité vers le serveur DNS de Google (8.8.8.8) depuis R1 et R2, grâce à la commande sh ip nat translations. Nous en voyons ci-dessous le résultat :


Comme nous le voyons ci-dessus, la table contient les adresses internes privée et translatées en adresses externes publiques. Nous voyons que l'adresse privée 10.10.10.9/30 (correspondant au port Gi0/3 du routeur R1), ayant le port 1 (même si icmp est un protocole de couche 3, un port est attribué dans la table des translations), est traduite par l'adresse externe 172.16.17.253/24 ayant aussi le port 1, et avec l'adresse de destination 8.8.8.8 et le port 1. Il en est de même pour le test de connectivité de R2 (seconde ligne ci-dessus).

Q27. Nous configurons également le NAT sur R-GW-1 et R-GW-2. Nous passons l'interface Gi0/0 en ip nat inside et l'interface Gi0/1 en ip nat outside. Nous créons une ACL sur R-GW-1 permettant de translater le réseau résumé des VLAN : 172.16.0.0/16 (commande access-list 1 permit 172.16.0.0 0.0.255.255). Nous configurons également un NAT dynamique surchargé (même commande qu'à la Q24). Sur R-GW-2, le réseau résumé 192.168.86.0/24 est autorisé à être translaté, et les commandes ip nat inside sont exécutées sur les sous interfaces Gi0/2.130, Gi0/2.140 et Gi0/2.170 et non sur l'interface Gi0/2.

Q28. Nous affichons la table des translations d'adresse du routeur R-GW-1 :


Nous voyons que lorsque VPC1 envoie une requête ICMP vers le serveur 8.8.8.8, son adresse privée 172.16.3.1/24 est translatée par l'adresse publique 10.10.10.1/30 qui correspond à l'adresse externe du routeur R-GW-1 ayant effectué la translation. Le port 29440 permet d'identifier le VPC1 afin que le routeur sache lui envoyer un paquet qui lui est destiné, s'il reçoit un paquet sur son IP externe et sur ce port.
Nous observons un résultat similaire pour R-GW-2, avec l'adresse privée de VPC5 192.168.86.1/25 translatée par l'adresse publique 10.10.10.18/30 et le port 48300 :


Q29. Le serveur situé dans la DMZ n'est pas accessible à partir des ordinateurs de Filiale, car son adresse IP se situe dans le réseau DMZ qui est privé (partie interne du NAT du siège). L'adresse privée du serveur n'est donc pas accessible des réseaux externes à celui de la DMZ et il faudrait mettre en place une redirection de ports vers le serveur, afin que le trafic reçu sur l'adresse externe de R-GW-1 et sur ces ports, soit redirigé vers l'IP interne du serveur. Il faut saisir sur R-GW-1 la commande ip nat inside source static tcp 172.16.0.1 80 10.10.10.1 80 afin de configurer une telle redirection. Nous faisons de même pour le service DNS (port udp et tcp 53) afin que le serveur DNS soit joignable depuis le réseau filiale via l'adresse externe de R-GW-1, grâce aux commandes ip nat inside source static tcp 172.16.0.1 53 10.10.10.1 53 et ip nat inside source static udp 172.16.0.1 53 10.10.10.1 53. Nous configurons ensuite les hôtes du réseau filiale avec comme adresse du serveur DNS, l'adresse externe de R-GW-1.

Q30. Nous installons le service HTTP (serveur NGINX) grâce à la commande apt update, puis apt install nginx.

Q31. Nous créons le fichier db.netcom.local à partir du fichier db.empty, dans /etc/bind , grâce à la commande cp db.empty db.netcom.local puis nous déclarons la zone netcom.local dans le fichier /etc/bind/named.conf.local , dont le contenu doit être le suivant :

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

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

Nous définissons ensuite la zone netcom.local dans le fichier /etc/bind/db.netcom.local , de la façon suivante :

; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN netcom.local.
$TTL    86400
@       IN      SOA     dns.netcom.local. hostmaster.netcom.local. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      web.netcom.local. ;
web     IN      A       172.16.0.1;
vpc1    IN      A       172.16.3.1;
vpc2    IN      A       172.16.3.2;
vpc3    IN      A       172.16.1.1;
vpc4    IN      A       172.16.2.1;
sw1     IN      A       172.16.3.251;
sw2     IN      A       172.16.3.252;

Nous configurons l'adresse DNS 172.16.0.1 (adresse du serveur) sur les clients puis nous réalisons une requête HTTP vers web.netcom.local. (par exemple grâce à l'utilitaire curl). Nous configurons également les adresses IP des autres hôtes du réseau et leur associons un FQDN (cf. ci-dessus).
Nous mettons également en place une résolution inverse, de l'adresse 172.16.0.1 vers le FQDN web.netcom.local. et idem pour les autres hôtes du réseau. Dans le fichier named.conf.local nous déclarons la zone inverse de la DMZ, de la façon suivante :

zone "0.16.172.in-addr.arpa"
{
type master;
file "/etc/bind/db.dmz.netcom.local.rev";
};

Nous créons ensuite le fichier db.dmz.netcom.local.rev à partir du fichier db.empty, selon la méthode vue plus haut. Nous obtenons le fichier suivant :

; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN 0.16.172.in-addr.arpa.
$TTL    86400
0.16.172.in-addr.arpa.  IN      SOA     dns.netcom.local. hostmaster.netcom.local. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      web.netcom.local. ;
1       PTR     web.netcom.local. ;

Nous procédons de façon similaire pour le réseau admin et les hôtes VPC-1, VPC-2 et les SVI des actifs réseau (fichier db.admin.netcom.local.rev) :

; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN 3.16.172.in-addr.arpa.
$TTL    86400
3.16.172.in-addr.arpa.  IN      SOA     dns.netcom.local. hostmaster.netcom.local. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      vpc1.netcom.local. ;
1       PTR     vpc1.netcom.local. ;
@       IN      NS      vpc2.netcom.local. ;
2       PTR     vpc2.netcom.local. ;
@       IN      NS      sw1.netcom.local. ;
251     PTR     sw1.netcom.local. ;
@       IN      NS      sw2.netcom.local. ;
252     PTR     sw2.netcom.local. ;
@       IN      NS      mls1.netcom.local. ;
254     PTR     mls1.netcom.local. ;

Nous procédons de la même façon pour le réseau R&D et l'hôte VPC-3 (fichier db.rd.netcom.local.rev) :

  GNU nano 7.2                 db.rd.netcom.local.rev *
; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN 1.16.172.in-addr.arpa.
$TTL    86400
1.16.172.in-addr.arpa.  IN      SOA     dns.netcom.local. hostmaster.netcom.local. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      vpc3.netcom.local. ;
1       PTR     vpc3.netcom.local. ;

Ainsi que pour le réseau PROD (fichier db.prod.netcom.local.rev) : 

; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN 2.16.172.in-addr.arpa.
$TTL    86400
2.16.172.in-addr.arpa.  IN      SOA     dns.netcom.local. hostmaster.netcom.local. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      vpc4.netcom.local. ;
1       PTR     vpc4.netcom.local. ;

Et pour le réseau interconnectant MLS1 et RGW1 (fichier db.inter.netcom.local ) :

; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN 4.16.172.in-addr.arpa.
$TTL    86400
4.16.172.in-addr.arpa.  IN      SOA     dns.netcom.local. hostmaster.netcom.local. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      rgw1.netcom.local. ;
1       PTR     rgw1.netcom.local. ;

Enfin, nous ajoutons les différentes zones au fichier named.conf.local , de sorte à obtenir le fichier complet suivant :

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

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

zone "0.16.172.in-addr.arpa"
{
type master;
file "/etc/bind/db.dmz.netcom.local.rev";
};

zone "3.16.172.in-addr.arpa"
{
type master;
file "/etc/bind/db.admin.netcom.local.rev";
};

zone "1.16.172.in-addr.arpa"
{
type master;
file "/etc/bind/db.rd.netcom.local.rev";
};

zone "2.16.172.in-addr.arpa"
{
type master;
file "/etc/bind/db.prod.netcom.local.rev";
};

zone "4.16.172.in-addr.arpa"
{
type master;
file "/etc/bind/db.inter.netcom.local.rev";
};

Nous réalisons également une redirection des requêtes non résolues par le serveur DNS, vers le serveur DNS de l'IUT d'adresse 195.220.217.6 en modifiant le fichier named.conf.options de la manière suivante :

options {
        directory "/var/cache/bind";
        recursion yes ;
        allow-recursion {any ; } ;
        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

           forwarders {
                195.220.217.6;
           };

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;

        listen-on-v6 { any; };
};

Les paramètres recursion yes ; et allow-recursion {any ; } ; permettent les requêtes DNS récursives émises par les clients DNS.

Nous testons la résolution directe et inverse grâce à l'utilitaire dig, dont nous voyons ci-dessous le résultat si l'on saisit la commande dig mls1.netcom.local :

; <<>> DiG 9.18.24-1-Debian <<>> mls1.netcom.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25116
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 04c5c67038fdef590100000066420438000df3a3ac64765f (good)
;; QUESTION SECTION:
;mls1.netcom.local.             IN      A

;; ANSWER SECTION:
mls1.netcom.local.      86400   IN      A       172.16.3.254

;; Query time: 16 msec
;; SERVER: 172.16.0.1#53(172.16.0.1) (UDP)
;; WHEN: Mon May 13 12:14:48 UTC 2024
;; MSG SIZE  rcvd: 90

Si nous saisissons la commande nslookup 172.16.3.254 , nous obtenons bien le FQDN mls1.netcom.local. ce qui montre que la résolution inverse est fonctionnelle : 

254.3.16.172.in-addr.arpa       name = mls1.netcom.local.

Nous voyons ci-dessous une capture Wireshark de la résolution directe de l'hôte mls1.netcom.local depuis VPC1 (requête DNS) :


Nous voyons ci-dessous la réponse du serveur DNS :


Nous voyons également le résultat de la résolution inverse de l'adresse IP 172.16.3.254 (requête ci-dessous) :


Ainsi que la réponse du serveur DNS :


Q35. Nous réalisons une capture de flux sur le serveur grâce à l'utilitaire tcpdump et la commande du même nom, saisie sur le serveur et dont nous voyons ci-dessous le résultat :


Nous voyons ainsi qu'une requête émise depuis VPC1 vers www.google.fr est redirigée du serveur DNS interne de l'entreprise vers le serveur de l'IUT.

Nous souhaitons également pouvoir accéder à l'intranet de l'entreprise depuis l'extérieur du réseau siège (par exemple, depuis filiale ou Internet), grâce au nom de domaine intranet.netcom.local. Nous ajoutons l'enregistrement suivant au fichier db.netcom.local :

@       IN      NS      intranet.netcom.local. ;
intranet        IN      A       10.10.10.1 ;

Ainsi qu'un enregistrement de zone inverse dans le fichier db.intranet.netcom.local.rev :

; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN 10.10.10.in-addr.arpa.
$TTL    86400
10.10.10.in-addr.arpa.  IN      SOA     dns.netcom.local. hostmaster.netcom.local. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      intranet.netcom.local. ;
1       PTR     intranet.netcom.local. ;

Nous déclarons le fichier de zone inverse dans named.conf.local par l'ajout de l'enregistrement suivant :

zone "10.10.10.in-addr.arpa"
{
type master;
file "/etc/bind/db.intranet.netcom.local.rev";
};

Q36. Le service ssh est déjà installé. Afin que les hôtes parviennent à joindre le serveur en SSH, nous allons dans le fichier /etc/ssh/ssh_config et nous décommentons les 2 lignes suivantes sur le serveur ainsi que les clients :

Port 22
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc

Nous configurons également une translation d'adresse statique sur le port 22, afin que les hôtes de réseaux externes puissent accéder en SSH au serveur. Nous saisissons la commande ip nat inside source static tcp 172.16.0.1 22 10.10.10.1 22 sur R-GW-1. Afin de se connecter au serveur, nous saisissons la commande ssh debian@172.16.0.1 (puis mot de passe debian), si nous nous connectons depuis le réseau siège, sinon nous utilisons l'IP externe de R-GW-1 (10.10.10.1).

Bonus

Nous créons un nouveau VLAN 150 "Ressources", d'adresse IP 172.16.5.0/24, affecté aux ports Gi3/0-3 de SW-1, et sur lequel nous connectons un nouveau serveur linux au port Gi3/0. Nous créons également l'interface SVI VLAN150 sur MLS-1, qui sera la passerelle du VLAN 150 et avec l'adresse IP 172.16.5.254/24. Nous installons le service isc-dhcp-server sur le nouveau serveur Linux, ainsi que le paquet net-tools (outils de diagnostics). Nous déclarons l'interface DHCP ens4 dans le fichier /etc/default/isc-dhcp-server avec la ligne INTERFACESv4="ens4" et nous ajoutons les informations des différents réseaux pour lesquels attribuer des adresses en DHCP, dans le fichier /etc/dhcp/dhcpd.conf . Exemple pour le VLAN ressources :

subnet 172.16.5.0 netmask 255.255.255.0 {
   range 172.16.5.10 172.16.5.30;
   option domain-name-servers 172.16.0.1;
   option domain-name "internal.netcom.local";
   option routers 172.16.5.254;
   option broadcast-address 172.16.5.255;
   default-lease-time 600;
   max-lease-time 7200;
 }

Nous configurons ensuite une agent relai DHCP sur les différentes interfaces virtuelles de MLS1, à l'exception du VLAN 150 (car c'est dans ce dernier que se situe le serveur DHCP), afin que le serveur DHCP soit accessible depuis les autres VLAN (les requêtes DHCP étant en broadcast et normalement non routées).

Ensuite, nous installons le serveur FTP ftpd-ssl avec un chiffrement SSL. Il faut également installer le client ftp sur les clients (commande apt install ftp). Nous testons le service FTP depuis un client grâce à la commande ftp 172.16.5.1 (IP du serveur du VLAN 150).

Nous ajoutons ensuite un enregistrement DNS pour ce serveur afin que celui-ci soit résolvable pour les hôtes du siège et de la filiale, nous ajoutns les lignes suivantes au fichier /etc/bind/db.netcom.local :

@       IN      NS      server-dhcp-ftp.netcom.local. ;
server-dhcp-ftp IN      A       172.16.5.1 ;

Nous créons ausssi le fichier d'enregistrement de zone inverse db.ressources.netcom.local dont le contenu est :

; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN 5.16.172.in-addr.arpa.
$TTL    86400
5.16.172.in-addr.arpa.  IN      SOA     dns.netcom.local. hostmaster.netcom.loc>
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      server-dhcp-ftp.netcom.local. ;
1       PTR     server-dhcp-ftp.netcom.local. ;

Et nous déclarons le fichier dans /etc/bind/named.conf.local :

zone "5.16.172.in-addr.arpa"
{
type master;
file "/etc/bind/db.ressources.netcom.local.rev";
};

Puis, nous créons 2 règles NAT statique sur R-GW-1 (ports 20 et 21) permettant d'accéder, depuis le réseau filiale, au serveur FTP :

ip nat inside source static tcp 172.16.5.1 20 10.10.10.1 20
ip nat inside source static tcp 172.16.5.1 21 10.10.10.1 21