Configurer un routage statique entre deux réseaux

Temps de lecture estimé : 4 minutes

Une architecture réseau digne de ce nom applique le principe de moindre privilège : chaque réseau est de préférence isolé et spécifique à un usage. Mais parfois, il existe des serveurs à mi-chemin entre deux réseaux, comme par exemple un serveur web1 devant accéder à son propre réseau « web », mais également au réseau « backend ». Dans ce cas, nous devons mettre en place un routage.

Pour un contexte aussi simple, le routage le plus rapide et le plus pratique est le routage statique. Pour en créer un de toute pièce, imaginons donc que nous ayons une topologie de réseau comme suit :

Separated networks

En l’état, ces deux réseaux n’ont aucun moyen de communiquer ensemble, disons qu’il manque un câble. Mais puisque les serveurs existants sont orientés application, aucun d’eux ne peut faire office de liaison. Rajoutons donc un serveur tiers :

Routed networks

Routeur

Configuré de la bonne façon, ce nouveau serveur est le noyau dur de notre architecture réseau : via les interfaces qui vont bien, il peut contacter n’importe lequel de nos sous-réseaux.

$ traceroute web1
traceroute to web1 (192.168.150.3), 30 hops max, 46 byte packets
 1  web1 (192.168.150.3)  2.099 ms  0.803 ms  0.855 ms

$ traceroute backend1
traceroute to backend1 (192.168.200.3), 30 hops max, 46 byte packets
 1  backend1 (192.168.200.3)  2.583 ms  0.763 ms  0.735 ms

Pour que ce serveur joue effectivement le rôle d’un routeur, et qu’il permette la communication entre ses différents réseaux, il est nécessaire de le forcer à re-transmettre les paquets qui ne le concernent pas directement. Pour cela, on se dirige dans le répertoire /proc pour activer la redirection d’IP :

$ echo 1 > /proc/sys/net/ipv4/ip_forward

NB: Cette configuration ne survit pas au redémarrage. Dès qu’elle est satisfaisante, il faudra la pérenniser dans la configuration systemd :

$ echo -e "\nnet.ipv4.ip_forward=1" >> /etc/sysctl.conf
$ sysctl -p

Selon la configuration pré-existante de routeur, il peut aussi être utile d’ouvrir le pare-feu :

$ iptables -A FORWARD -j ACCEPT

Ensuite, puisque la communication est unidirectionnelle, on doit faire croire au réseau backend que les communications de web proviennent du routeur afin de recevoir sa réponse. On doit donc masquer l’IP source dans la requête routeur -> backend et cela se passe toujours sur le pare-feu :

$ iptables -t nat -A POSTROUTING -s 192.168.150.0/24 -d 192.168.200.0/24 -j MASQUERADE

Pour un serveur, savoir comment se connecter à autrui se trouve dans la table de routage. On dégaine la commande ip route pour l’afficher, ce qui donne sur mon propre poste :

$ ip r
default via 192.168.1.254 dev wlp4s0 proto dhcp metric 600 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.37 metric 600 

Comme on le voit, j’ai actuellement 2 interfaces (ou « devices »), une définition de routage pour les IPs de docker (« 172.17.0.0/16 »), une définition de routage pour les IPs locales (« 192.168.1.0/24 ») mais aussi une définition de routage par défaut, pour tout ce qui n’est pas explicitement décrit. Grâce à cette dernière, si je veux accéder à https://redwatch.io, c’est mon routeur domestique qui prendra le relai et m’enverra sur Internet.

NB: La commande route est aussi disponible, elle a l’avantage de résoudre les domaines.

Ce moyen pour faire des rebonds et changer de réseau est appelé une gateway et c’est cela qu’on va utiliser pour contacter backend1 depuis web1.

À présent, rendons-nous sur le serveur web1, c’est là que la magie va opérer.

Web1

La règle que l’on veut ajouter dans la table de routage se traduirait en français : « je veux que toutes les tentatives de communication au réseau “backend” transitent par “routeur” » et elle s’écrit de façon quasi transparente :

$ ip route add 192.168.200.0/24 via 192.168.150.10

Pour vérifier la prise en compte, étudions les rebonds de la traceroute :

$ traceroute backend1
traceroute to backend1 (192.168.200.3), 30 hops max, 46 byte packets
 1  web_router (192.168.150.2)  1.366 ms  0.975 ms  0.861 ms
 2  backend1 (192.168.200.3)  3.066 ms  1.924 ms  2.433 ms

La communication est pleinement fonctionnelle ! Comme attendu, notre réseau web peut atteindre backend mais pas l’inverse. Si par contre la communication est bidirectionnelle, on place simplement un autre routage sur backend1 et le masquage d’IP n’est plus nécessaire. Toutes ces configurations sont aisées pour quelques serveurs, mais deviennent rapidement chronophages quand votre parc devient conséquent. Dans cette autre situation, on privilégiera le routage dynamique.

Comme d’habitude, vous pouvez retrouver le code pour essayer par vous-même sur le dépôt d’exemple.


Source :


    Ce billet vous a plu ? Partagez-le sur les réseaux…


    … Ou inscrivez-vous à la newsletter pour ne manquer aucun article (Si vous ne voyez pas le formulaire, désactivez temporairement uBlock).

    Voir aussi