Attention, ça se complique…

Nous voudrions maintenant que notre réseau expérimental 192.168.61.0/24 puisse avoir un accès à l'internet.

Nous bricolons donc notre plateforme expérimentale de la façon suivante:

1. Ajout d'une interface Ethernet dans le demoserver, avec l'adresse 192.168.60.252. (Elle s'appellera logiquement enp1s0). La configuration devient alors dans le fichier /etc/network/interfaces:

   # The loopback network interface
   auto lo
   iface lo inet loopback
   
   allow-hotplug enp1s0
   iface enp1s0 inet static
     address 192.168.60.252/24
     gateway 192.168.60.254
    
   
   allow-hotplug enp7s0
   iface enp7s0 inet static
     address 192.168.61.1/24
   

2. Branchement de cette interface dans le réseau 192.168.60.0/24 qui dispose d'un routeur vers l'internet à l'adresse 192.168.60.254. C'est la «box» qui dispose également d'un résolveur DNS.
   Nous pouvons déjà vérifier que demoserver accède correctement à l'internet:

   ping -c1 www.debian.org
   
   PING www.debian.org(klecker.debian.org (2001:67c:2564:a119::77)) 56 data bytes
   64 bytes from klecker.debian.org (2001:67c:2564:a119::77): icmp_seq=1 ttl=46 time=29.8 ms
   
   --- www.debian.org ping statistics ---
   1 packets transmitted, 1 received, 0% packet loss, time 0ms
   rtt min/avg/max/mdev = 29.789/29.789/29.789/0.000 ms
   

   Jusque là, tout va bien.

1. Le kernel Linux sait parfaitement effectuer du routage entre interfaces réseau, encore faut-il activer cette fonction qui ne l'est pas par défaut pour des raisons de sécurité (administrateur requis):

   sysctl -w net.ipv4.ip_forward=1

Théoriquement, si demoserver a compris sa fonction de routage, democlient1 devrait pouvoir accéder à 192.168.60.254. Essayons avec un ping :

ping -c1 192.168.60.254

La réponse n'est pas sympathique:

ping: connect: Le réseau n'est pas accessible

Vérifions d'abord les routes que connaît demoserver:

ip route list

default via 192.168.60.254 dev enp1s0 onlink 
192.168.60.0/24 dev enp1s0 proto kernel scope link src 192.168.60.252 
192.168.61.0/24 dev enp7s0 proto kernel scope link src 192.168.61.1 

1. Il sait comment aller sur 192.168.60.0/24;
2. il sait comment aller sur 192.168.61.0/24;
3. il sait comment aller ailleurs en passant par 192.168.60.254 via l'interface enp1s0.

Est-ce que democlient1 sait comment sortir de son réseau ?

Sur democlient1:

ip roule list

192.168.61.0/24 dev enp1s0 proto kernel scope link src 192.168.61.101 

La seule route qu'il connaît est celle qui permet d'accéder aux nœuds du réseau 192.168.61.0/24. Aucune chance d'accéder à un autre réseau. Il faut donc lui expliquer comment sortir. Indiquons-lui une route par défaut (administrateur requis):

ip route add default via 192.168.61.1

Et vérifions:

ip route list

default via 192.168.61.1 dev enp1s0 
192.168.61.0/24 dev enp1s0 proto kernel scope link src 192.168.61.101

Voilà qui est mieux. Essayons encore…

ping -c1 192.168.60.254

PING 192.168.60.254 (192.168.60.254) 56(84) bytes of data.

--- 192.168.60.254 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Dans les cas désespérés, il faut sortir l'artillerie lourde. Voyons avec wireshark ce qu'il se passe sur les deux interfaces de demoserver. Relançons le ping et voyons:

No. Source          Destination     Protocol  Info
1  192.168.61.100   192.168.60.254  ICMP      Echo request (no response found!)

Nous devrions voir cet Echo request 2 fois s'il traversait le routeur, Sur l'interface dans 192.168.61.0 puis sur l'interface dans 192.168.60.0 !

Le routeur ne route pas… Il fallait savoir que si le kernel Linux sait faire le routage, cette fonction est désactivée par défaut pour des raisons de sécurité. La commande sysctl permet de configurer les paramètres du noyau à chaud (cf. man sysctl). En l'occurence:

Vérifions:

sysctl net.ipv4.ip_forward

net.ipv4.ip_forward = 0

Il faut mettre ce paramètre à 1:

sysctl -w net.ipv4.ip_forward=1

net.ipv4.ip_forward = 1

Essayons encore en laissant Wireshark espionner le tout:

No. Source          Destination           Protocol Info
 1  192.168.61.100  192.168.60.254        ICMP     Echo request (no response found!)
 2  192.168.61.100  192.168.60.254        ICMP     Echo request (no response found!)

Il y a du mieux. Le paquet traverse bien le routeur, mais aucune réponse n'arrive… Supposons alors que le paquet est bien arrivé sur 192.168.60.254 ce qui est bien légitime puisque le paquet est arrivé sur 192.168.60.0. La Box a donc certainement répondu à 192.168.61.100 Sauf qu'elle ne connaît pas la route vers ce réseau. Elle connaît 192.168.60.0 sinon elle route vers l'internet ! Il faudrait ajouter la route vers 192.168.61.0/24 à la Box, malheureusement la Box n'est pas configurable en ce qui concerne ses routes et il n'y a aucune raison qu'elle soit au courant de nos bidouillages internes. C'est du matériel «grand public»!

Au final, nous avons bien une route qui permet d'aller de 192.168.61.0/24 vers 192.168.60.254, mais il n'y a pas de route pour le retour. Alors, comment faire ?

Il y a deux solutions plus ou moins simples, plus ou moins élégantes.

C'est possible au moins avec les Freebox . Il faut alors la configurer en mode «bridge». Dans ce cas, elle va fonctionner comme un simple modem, et placer derrière un routeur «maison» comme nous faisions au bon vieux temps, lorsque les fournisseurs d'accès ne proposaient qu'un simple modem. Nous aurions alors un montage de cette forme:

Le routeur R1 assure les mêmes fonctions que celui qui est intégré dans la Box, à ceci près que nous pouvons lui ajouter une route vers 192.168.61.0/24.

Mais nous ne détaillerons pas d'avantage cette solution. Consultez les archives du site pour voir ça de près.

C'est-à-dire sur demoserver masquer l'adresse source dans tous les paquets sortant du réseau 192.168.61.0/24 par celle de l'interface ayant l'adresse 192.168.60.252, c'est-à-dire faire finalement la même chose que la Box entre le réseau 192.168.60.0/24 et l'internet. Ainsi, les cibles verront 192.168.60.252 comme adresse source et y répondront en toute bonne foi. À charge pour demoserver de replacer la bonne adresse de destination des les réponses qu'il reçoit, puis de les router convenablement. Le processus est largement décrit dans le chapitre dédié.

C'est cette solution que nous allons adopter. Prenons pour l'instant la solution comme une recette de cuisine. Sur demoserver, l'interface ayant pour adresse 192.168.60.252 s'appelle enp1s0. Après avoir installé le paquet iptables, voici la commande magique (administrateur requis):

iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE

ping -c1 192.168.60.254

Donne à présent:

PING 192.168.60.254 (192.168.60.254) 56(84) bytes of data.
64 bytes from 192.168.60.254: icmp_seq=1 ttl=63 time=1.23 ms

Nous avons la réponse au ping. Un coup de sniffeur pour vérifier tout ça nous donne en résumé classé de façon chronologique:

No. Time           Source          Destination       Info
 1  0.000000000    192.168.61.101  192.168.60.254    Echo (ping) request   (reply in 2)
 3  0.000427949    192.168.60.252  192.168.60.254    Echo (ping) request   (reply in 4)   
 4  0.000760552    192.168.60.254  192.168.60.252    Echo (ping) reply     (request in 3)         
 2  0.001019194    192.168.60.254  192.168.61.101    Echo (ping) reply     (request in 1)

Les trames jaunes sont capturées sur sw1 et les bleues le sont sur sw2.

Nous voyons sur la trame n°1 (ping request):

• l'adresse source est celle de democmlient1
• l'adresse cible est celle du routeur dans 192.168.60.0/24

Dans la trame n°3 nous retrouvons le ping request mais:

• l'adresse source est désormais celle de demoserver sur enp1s0. C'est le travail du «masquerade».
• l'adresse cible reste bien sûr la même.

Dans la trame n°4, nous avons le «ping reply» de 192.168.60.254 qui est envoyée à 192.168.60.252 (demoserver) Dans la trame n°2, nous retrouvons le «ping reply», mais cette fois-ci adressée à 192.168.61.101 c'est-à-dire democlient1, re-travail du «masquerade»

Dans les faits, la Box fait également du masquage d'adresse vers l'internet pour IPv4, ce qui était prévisible puisque nous utilisons le réseau 192.168.60.0/24 qui n'est pas routable directement sur l'internet (adresses réservées à l'usage privé).

Est-ce que dans ce cas, 192.168.61.0/24 serait alors capable lui aussi de communiquer avec l'internet ?

 ping -c1 51.68.121.59
PING 51.68.121.59 (51.68.121.59) 56(84) bytes of data.
64 bytes from 51.68.121.59: icmp_seq=1 ttl=52 time=19.8 ms

Yesssssssssssssssss!

Dans ce genre de situation, il faut toujours vérifier que:

1. Le routeur intermédiaire a bien une interface dans chaque réseau,
2. qu'il est configuré pour effectuer le routage,
3. que les routes de retour existent bien, d'une manière ou d'une autre,
4. que tous les éléments des réseaux sachent à quel routeur s'adresser pour sortir de leur réseau.
5. lorsque quelque chose ne fonctionne pas comme prévu, les sondes d'observation du réseau, Wireshark par exemple, peuvent bien aider à démasquer le bug.

Notre réseau virtuel 192.168.61.0/24 est donc capable de communiquer avec 192.168.60.0/24 qui lui-même est capable de communiquer avec l'internet.

Ceci dit, tous les aménagements de configuration que nous avons bricolé l'ont été de manière temporaire:

1. la route par défaut pour les clients du réseau 192.168.61.0/24 pourra être dynamiquement ajoutée à la configuration IP par l'intermédiaire du serveur DHCP.
2. l'activation du routage sur demoserver.
3. le masquage d'adresse mis en place sur demoserver devra être reconstitué à chaque démarrage de ce dernier. Un paquet Debian iptables-persistent prévu pour, devra être installé sur demoserver

Pour activer le routage de façon permanente il faut créer dans le répertoire /etc/sysctl.d un fichier nommé par exemple activationRoutage.conf qui contiendra cette unique ligne:

net.ipv4.ip_forward=1

Au prochain démarrage, systemd lancera un service nommé systemd-sysctl qui s'occupera d'ajuster les variables système en fonction de ce nouveau fichier. Les plus curieux pourront consulter le manuel de la commande sysctl.

Pour le serveur DHCP, revenons sur son fichier de configuration

{
    "Dhcp4": {
        "interfaces-config": {
            "interfaces": [
                "enp7s0"
            ]
        },
        "valid-lifetime": 360,
        "renew-timer": 180,
        "rebind-timer": 350,
        "authoritative": true,
        "lease-database": {
            "type": "memfile",
            "persist": true,
            "name": "/var/lib/kea/kea-leases4.csv",
            "lfc-interval": 3600
        },
        "subnet4": [
            {
                "subnet": "192.168.61.0/24",
                "pools": [
                    {
                        "pool": "192.168.61.100 - 192.168.61.120"
                    }
                ],
                "option-data": [
                   {
                        "name": "routers",
                        "data": "192.168.61.1"
                   }
               ],
            }
        ]
    }
}

Il suffit d'ajouter le paragraphe surligné dans le fichier /etc/kea/kea-dhcp4.conf et de relancer le serveur.

Après redémarrage de demoserver, nous pouvons vérifier:

ip route list
default via 192.168.60.254 dev enp1s0 onlink 
192.168.60.0/24 dev enp1s0 proto kernel scope link src 192.168.60.252 
192.168.61.0/24 dev enp7s0 proto kernel scope link src 192.168.61.1 

Le serveur connaît la route par défaut, celle qui mène à l'internet.

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Le kernel a retenu qu'il devait effectuer le routage.

iptables -t nat -L POSTROUTING -v
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target      prot opt in     out     source           destination         
   22  1568 MASQUERADE  all  --  any    enp1s0  anywhere         anywhere

Le masquage d'adresse est bien actif pour tout ce qui sort par enp1s0.

Du côté du democlient1 il faut juste vérifier qu'il connaît après redémarrage la route par défaut:

ip route ls
default via 192.168.61.1 dev enp1s0
192.168.61.0/24 dev enp1s0 proto kernel scope link src 192.168.61.101 

Et voilà le travail !

Nous verrons plus loin que tout ceci devient obsolète si l'on utilise exclusivement IPv6, mais ce n'est pas encore possible.