Configuration du second réseau
Mise à jour :
Dans mon précédent guide, j’ai abordé la construction d’une machine de rebond sous Debian, un élément important pour sécuriser l’accès à nos machines du Homelab DevOps. Cette machine, équipée de deux cartes réseau, nous a permis de jeter les bases d’un système intermédiaire fiable et sécurisé pour la gestion du trafic réseau. Aujourd’hui, je vais vous guider à travers une suite logique de ce tutoriel : comment configurer cette même machine de rebond pour qu’elle serve non seulement de point de passage, mais également de passerelle Internet pour un réseau secondaire et pour fournir des adresses IP aux machines du second réseau.
Prérequis et matériel nécessaire
Avant de plonger dans la configuration de notre machine de rebond pour fournir un accès Internet et gérer les adresses IP et la résolution de noms, il est essentiel de s’assurer que nous disposons de tout le nécessaire, tant sur le plan matériel que logiciel. Voici ce dont vous aurez besoin :
Matériel
- Un ordinateur sous Debian : Cette machine fera office de serveur de
rebond. Elle doit être équipée de deux cartes réseau. La première sera
connectée à votre réseau principal (dans notre cas, le réseau
192.168.1.0/24) et la seconde au réseau secondaire (192.168.20.0/24) qui souhaite accéder à Internet via ce serveur. - Connexion Internet : Naturellement, votre serveur de rebond doit avoir accès à Internet pour pouvoir partager cette connexion avec le réseau secondaire.
- Switch ou routeur pour le réseau secondaire : Cela permettra de connecter plusieurs dispositifs au réseau secondaire et de les gérer via le serveur de rebond.
Connaissances préalables
Il est recommandé d’avoir une compréhension des bases des réseaux IP, du fonctionnement des pare-feux, des serveurs DHCP et des serveurs DNS. Une familiarité avec la ligne de commande Linux et la configuration réseau sur Debian sera également très utile pour suivre ce guide.
Configuration de base de Debian et des cartes réseau
Pour permettre à notre machine de rebond sous Debian de servir efficacement de
passerelle entre notre réseau principal (192.168.1.0/24) et le réseau
secondaire (192.168.20.0/24), il est essentiel de commencer par configurer
correctement les interfaces réseau. Cette configuration assure que notre serveur
peut communiquer à la fois avec les dispositifs internes sur les deux
sous-réseaux et avec l’Internet externe. Voici comment je procède pour
configurer les cartes réseau :
Étape 1 : Identification des interfaces réseau
Tout d’abord, je détermine les noms des interfaces réseau en utilisant la
commande ip link show.
ip link show1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 68:1d:ef:38:f6:e5 brd ff:ff:ff:ff:ff:ff3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 68:1d:ef:38:f6:e6 brd ff:ff:ff:ff:ff:ffbob@bastion ~Dans ce guide, je suppose que enp1s0 est l’interface connectée au réseau
principal (192.168.1.0/24) et que enp3s0 est celle connectée au réseau
secondaire (192.168.20.0/24).
Étape 2 : Configuration des interfaces réseau
Ensuite, je configure les adresses IP statiques pour les deux interfaces dans le
fichier /etc/network/interfaces. Cela garantit que notre serveur Debian a une
adresse IP fixe sur chaque réseau, ce qui est indispensable pour le rôle de
passerelle et de serveur DHCP/DNS.
Voici à quoi pourrait ressembler la configuration :
# Interface pour le réseau principalauto enp1s0iface enp1s0 inet static address 192.168.1.92 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.92 192.168.1.1
# Interface pour le réseau secondaireauto enp3s0iface enp3s0 inet static address 192.168.20.1 netmask 255.255.255.0 # Pas de gateway spécifié pour cette interface, car elle ne se connecte pas directement à InternetDans cette configuration, enp1s0 est configurée avec une adresse IP statique
qui lui permet de communiquer avec le réseau principal. La passerelle par défaut
est également définie pour diriger le trafic Internet. Pour enp3s0, une
adresse IP statique est configurée pour le réseau secondaire, mais sans
passerelle spécifiée, car le trafic Internet passera par enp1s0.
Étape 3 : Activation du routage IP
Pour permettre à notre serveur de transmettre le trafic entre les deux réseaux
et vers Internet, je dois activer le routage IP. Cela se fait en modifiant le
fichier /etc/sysctl.conf pour activer le transfert IP :
net.ipv4.ip_forward=1Après avoir modifié ce fichier, j’applique la modification avec la commande
sysctl -p.
Étape 4 : Configuration du pare-feu
Il est également nécessaire d’installer et de configurer ufw pour permettre et
contrôler le trafic entre les réseaux.
sudo apt install ufwIl faut autoriser le forwarding dans la configuration d’ufw. Ouvrez le fichier
/etc/default/ufw avec un vi. Recherchez la ligne commençant par
DEFAULT_FORWARD_POLICY. Remplacez la valeur DROP par ACCEPT. Enregistrez
le fichier et quittez l’éditeur.
DEFAULT_FORWARD_POLICY="ACCEPT"Avant de définir des règles spécifiques pour notre cas de routage, je configure les politiques par défaut de ufw pour refuser tout le trafic entrant et autoriser tout le trafic sortant. Cette configuration de base assure que notre serveur n’accepte pas de connexions non sollicitées, tout en permettant au trafic sortant de circuler librement :
sudo ufw --force disablesudo ufw --force resetsudo ufw default deny incomingsudo ufw default allow outgoingMaintenant nous allons autoriser le flux ssh et dns :
sudo ufw allow sshsudo ufw allow dnssudo ufw allow out to any port 53Maintenant ajoutons les règles de forwarding entre l’interface enp3s0 et
enp1s0 pour permettre la mise à jour des packages sur les machines du second
réseau. Il faut édider le fichier /etc/ufw/before.rules :
sudo vi /etc/ufw/before.ruleset ajouter ce bloc juste avant *filter :
*nat:POSTROUTING ACCEPT [0:0]
# Forward traffic through eth0 - Change to match you out-interface-A POSTROUTING -s 192.168.20.0/24 -o enp1s0 -j MASQUERADE
# don't delete the 'COMMIT' line or these nat table rules won't# be processedCOMMITActivons le service ufw :
sudo ufw enableVérifions son status :
Status: active
To Action From-- ------ ----22/tcp ALLOW AnywhereDNS ALLOW Anywhere22/tcp (v6) ALLOW Anywhere (v6)DNS (v6) ALLOW Anywhere (v6)
53 ALLOW OUT Anywhere53 (v6) ALLOW OUT Anywhere (v6)Mise en place de isc-dhcp-server
Après avoir configuré ufw pour permettre le routage sécurisé entre les
réseaux, l’étape suivante consiste à mettre en place isc-dhcp-server sur notre
serveur Debian. Ce serveur DHCP distribuera automatiquement des adresses IP, des
masques de sous-réseau, des gateways et des informations de serveurs DNS aux
dispositifs connectés au réseau secondaire. Voici comment je procède pour
configurer isc-dhcp-server.
Étape 1 : Installation de isc-dhcp-server
Tout d’abord, je commence par installer le paquet isc-dhcp-server :
sudo apt updatesudo apt install isc-dhcp-serverÉtape 2 : Configuration de l’interface réseau
Ensuite, je configure isc-dhcp-server pour spécifier sur quelle interface
écouter les requêtes DHCP. Dans notre cas, il s’agit de enp3s0, l’interface
connectée au réseau secondaire. Je modifie le fichier
/etc/default/isc-dhcp-server pour y ajouter l’interface :
INTERFACESv4="enp3s0"INTERFACESv6=""Étape 3 : Configuration du serveur DHCP
La partie la plus importante de la configuration de isc-dhcp-server consiste à
définir la plage d’adresses IP à distribuer, ainsi que d’autres options pour le
réseau. Pour cela, je modifie le fichier /etc/dhcp/dhcpd.conf pour ajouter la
configuration spécifique à notre réseau secondaire :
subnet 192.168.20.0 netmask 255.255.255.0 { range 192.168.20.10 192.168.20.100; option routers 192.168.20.1; option subnet-mask 255.255.255.0; option domain-name-servers 192.168.20.1; option domain-name "robert.priv"; default-lease-time 600; max-lease-time 7200;}Dans cette configuration, range spécifie la plage d’adresses IP disponibles
pour la distribution aux clients DHCP. option routers définit la passerelle
par défaut, qui est l’adresse IP de notre serveur sur enp3s0. option domain-name-servers spécifie le serveur DNS que les clients utiliseront, que
nous avons également configuré pour pointer vers notre serveur Debian, agissant
comme serveur DNS avec bind9. Les options default-lease-time et
max-lease-time définissent la durée de bail par défaut et maximale en
secondes.
Étape 4 : Démarrage et vérification du service
Après avoir configuré le serveur DHCP, je démarre le service et m’assure qu’il n’y a pas d’erreurs :
sudo systemctl restart isc-dhcp-serversudo systemctl status isc-dhcp-serverJe vérifie également les logs pour m’assurer que tout fonctionne comme prévu :
sudo journalctl -u isc-dhcp-serverÉtape 5 : Test de la configuration DHCP
Pour tester que le serveur DHCP fonctionne correctement, je connecte un dispositif au réseau secondaire et vérifie qu’il reçoit une adresse IP dans la plage définie, ainsi que les informations correctes de passerelle et de serveur DNS.
La mise en place de isc-dhcp-server permet non seulement de fournir
automatiquement des adresses IP aux dispositifs du réseau secondaire, mais
simplifie également la gestion du réseau en centralisant la distribution des
configurations réseau essentielles.
Configuration de bind9 pour la résolution de noms
Après avoir configuré notre serveur Debian pour distribuer des adresses IP via
isc-dhcp-server, il est temps de s’assurer que les dispositifs du réseau
secondaire peuvent résoudre les noms de domaine en adresses IP, en configurant
bind9 comme serveur DNS. bind9 est un logiciel de serveur DNS très répandu
et robuste, offrant une grande flexibilité pour gérer la résolution de noms dans
un réseau. Voici comment je procède pour configurer bind9.
Étape 1 : Installation de bind9
La première étape consiste à installer bind9 sur notre serveur Debian :
sudo apt updatesudo apt install bind9Étape 2 : Configuration des zones DNS
bind9 utilise des zones pour gérer la résolution de noms dans différents
domaines. Pour notre réseau secondaire, je crée une zone de recherche directe
pour résoudre les noms de domaine en adresses IP et une zone de recherche
inverse pour faire l’inverse.
Dans un premier temps nous allons générer une clé rndc pour sécuriser le service
bind9 :
sudo rndc-confgen -akey "rndc-key" { algorithm hmac-sha256; secret "rbt4zTrc2QO3cK/Y/cbn/EKtUat3Gn0jJXyYtKDgHtgI8w8PMkXcUN8DZLE95ANdZZScwEk/RVHa05S3IiaGrA==";};Cette commande crée automatiquement une clé rndc et stocke la configuration dans
/etc/bind/rndc.key. bind9 est configuré par défaut pour utiliser cette clé,
facilitant la gestion sécurisée du serveur DNS.
On poursuit en éditant le fichier de configuration principal de bind9,
/etc/bind/named.conf.local, pour y ajouter la clé et nos zones :
key "rndc-key" { algorithm hmac-sha256; secret "rbt4zTrc2QO3cK/Y/cbn/EKtUat3Gn0jJXyYtKDgHtgI8w8PMkXcUN8DZLE95ANdZZScwEk/RVHa05S3IiaGrA==";};
zone "robert.priv" { type master; file "/var/lib/bind/robert.priv.zone"; allow-update { key rndc-key; };};
zone "20.168.192.in-addr.arpa" { type master; file "/var/lib/bind/20.168.192.in-addr.arpa.zone"; allow-update { key rndc-key; };};Dans cet exemple, robert.priv est le domaine que j’utilise pour le réseau
secondaire. La zone de recherche inverse est nommée d’après le renversement de
l’adresse IP du réseau secondaire, suivie de in-addr.arpa, un domaine spécial
utilisé pour les requêtes de recherche inverse DNS.
Étape 3 : Création des fichiers de zone
Après avoir défini les zones dans le fichier de configuration, je crée les
fichiers de zone correspondants en m’inspirant des exemples fournis par bind9.
Pour la zone de recherche directe (robert.priv.zone) :
$TTL 604800 ; 1 weekrobert.priv IN SOA ddns.robert.priv. dnsadmin.robert.priv. ( 2018021369 ; serial 28800 ; refresh (8 hours) 3600 ; retry (1 hour) 302400 ; expire (3 days 12 hours) 43200 ; minimum (12 hours) ) NS ddns.robert.priv.$ORIGIN robert.priv.ddns A 192.168.20.1gw A 192.168.20.1rebond A 192.168.20.1Pour la zone de recherche inverse (20.168.192.in-addr.arpa.zone) :
$ORIGIN .$TTL 604800 ; 1 week20.168.192.in-addr.arpa IN SOA ddns.robert.priv. dnsadmin.robert.priv. ( 2018021412 ; serial 28800 ; refresh (8 hours) 3600 ; retry (1 hour) 302400 ; expire (3 days 12 hours) 43200 ; minimum (12 hours) ) NS ddns.robert.priv.$ORIGIN 20.168.192.in-addr.arpa.1 PTR gw.robert.priv.1 PTR ddns.robert.priv.1 PTR bastion.robert.priv.Ces fichiers définissent la structure de base pour notre résolution de noms, y compris un enregistrement SOA (Start of Authority), un enregistrement NS (nameserver) pointant vers notre serveur et des enregistrements A ou PTR pour associer des noms de domaine à des adresses IP et vice-versa.
Étape 4 : Vérification et redémarrage de bind9
Après avoir configuré les zones et créé les fichiers de zone, je vérifie la
syntaxe de la configuration avec named-checkconf et named-checkzone pour
m’assurer qu’il n’y a pas d’erreurs :
sudo named-checkconf
sudo named-checkzone robert.priv /var/lib/bind/robert.priv.zonezone robert.priv/IN: loaded serial 2018021369OK
sudo named-checkzone 20.168.192.in-addr.arpa.zoneSi tout est correct, je redémarre bind9 pour appliquer les changements :
sudo systemctl restart bind9Étape 5 : Test de la résolution DNS
Pour tester que la résolution DNS fonctionne comme prévu, je peux utiliser dig
ou nslookup depuis un dispositif du réseau secondaire :
dig rebond.robert.priv @192.168.20.1
; <<>> DiG 9.18.24-1-Debian <<>> rebond.robert.priv @192.168.20.1;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32170;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 1232; COOKIE: 1bf8e10680c977630100000065cceb538d7da520cb6397e8 (good);; QUESTION SECTION:;rebond.robert.priv. IN A
;; AUTHORITY SECTION:robert.priv. 43200 IN SOA ddns.robert.priv. dnsadmin.robert.priv. 2018021369 28800 3600 302400 43200
;; Query time: 0 msec;; SERVER: 192.168.20.1#53(192.168.20.1) (UDP);; WHEN: Wed Feb 14 17:33:23 CET 2024;; MSG SIZE rcvd: 125Cela devrait retourner l’adresse IP du serveur (192.168.20.1), confirmant que
la résolution DNS est correctement configurée.
Étape 6 : Autoriser isc-dhcp-server à ajouter dynamiquement les adresses IP
Modifiez le fichier /etc/dhcp/dhcpd.conf pour inclure la définition de la clé
et configurer les mises à jour dynamiques :
# my config for ddnsddns-updates on;ddns-update-style standard;authoritative;
include "/etc/dhcp/rndc-keys/rndc.key";
allow unknown-clients;default-lease-time 7200;max-lease-time 28800;log-facility local7;
zone robert.priv. { primary 192.168.20.1; key rndc-key;}
zone 20.168.192.in-addr.arpa. { primary 192.168.20.1; key rndc-key;}
subnet 192.168.20.0 netmask 255.255.255.0 { range 192.168.20.100 192.168.20.199; option subnet-mask 255.255.255.0; option domain-name-servers 192.168.20.1, 8.8.8.8; option domain-name "robert.priv"; option routers 192.168.20.1; option broadcast-address 192.168.20.255;}Après avoir configuré isc-dhcp-server pour les mises à jour dynamiques,
redémarrez le service:
sudo systemctl restart isc-dhcp-serverÉtape 7 : Tester la configuration
Pour tester que tout est configuré correctement, connectez un dispositif au
réseau secondaire. Il devrait recevoir une adresse IP de isc-dhcp-server et un
enregistrement DNS correspondant devrait être créé dans bind9 automatiquement.
Vous pouvez vérifier les enregistrements DNS avec dig ou consulter les logs de
bind9 et isc-dhcp-server.
Cette configuration permet à isc-dhcp-server de mettre à jour bind9 avec les
adresses IP attribuées dynamiquement, facilitant la gestion du réseau en
maintenant la correspondance entre les noms de dispositifs et leurs adresses IP
actuelles.
Etape 8 : Mise en place ProxyJump
Pour se connecter directement en ssh au second réseau depuis votre machine vous
servant de machine d’administration, dans mon cas un pc portable, il faut mettre
en place un ProxyJump :
Host * StrictHostKeyChecking no ControlMaster auto ControlPath ~/.ssh/sockets/%r@%h-%p ControlPersist 600
Host bastion.robert.local User bob Hostname 192.168.1.92 IdentityFile /home/bob/.ssh/id_ed25519.pub
Host *.robert.priv 192.168.20.* User bob ProxyJump bastion.robert.localJe sais me connecter à la machine de rebond, nommé bastion.robert.local, et
donc pour accéder aux machines du réseau 192.168.20.* il suffit de lui dire de
passer par ce bastion avec le paramètre ProxyJump. Ensuite, tester avec la
commande ssh d’accéder directement à cette machine et si vous avez bien fait
votre travail tout devrait fonctionner. Plus d’infos sur la configuration client
ssh
Conclusion
Au terme de ce guide, nous avons configuré avec succès un serveur Debian pour
qu’il serve de passerelle Internet à un réseau secondaire, tout en fournissant
des services DHCP et DNS via isc-dhcp-server et bind9. Grâce à cette
configuration, les dispositifs du réseau secondaire peuvent désormais obtenir
automatiquement des adresses IP, résoudre les noms de domaine et accéder à
Internet via la machine de rebond. La mise en place de ufw a permis de
sécuriser le trafic entre les réseaux, en veillant à ce que seules les
communications autorisées puissent transiter. Il ne reste qu’à écrire un
playbook
ansible
réalisant cette configuration.
J’espère que ce guide vous a été utile et qu’il vous a fourni les connaissances
nécessaires pour configurer votre propre serveur Debian comme une passerelle
Internet, ainsi que pour gérer les services DHCP et DNS. N’hésitez pas à adapter
les étapes à votre propre environnement réseau et à explorer davantage les
fonctionnalités avancées de ufw, isc-dhcp-server et bind9 pour répondre à
vos besoins spécifiques.
L’administration système et la gestion de réseau sous Linux sont des compétences précieuses et en constante évolution. Continuez à apprendre, à expérimenter et à partager vos découvertes avec la communauté. Bonne configuration!