Avec quelques notions de routage en tête après quelques cours de réseau, il était temps de scinder le réseau en deux: VMs, containers et le reste. En effet, la box du FAI semblait galérer un peu à garder une trace de toutes ces connexions qui vont et viennent et finit par jouer des tours.

Cet article me servira plus de référence dans le futur. Ceci dit, je pense qu'il est intéressant de partager son expérience sur la séparation de son réseau en deux et de la mise en place d'un routeur au milieu.

Le résultat final est probant et permet d'alléger considérablement la liste des hôtes dans le panel admin de la fameuse box et c'est toujours ça de pris.

Le coup d'essai

Histoire de me faire la main avec les routes, j'ai pris une Debian buster toute simple, sans artifices.

Je me suis aussi pris un container de test pour voir si j'arrive à faire en sorte qu'un paquet ICMP arrive à passer au dela du routeur virtuel et du routeur à la frontière entre moi et intertubes.

J'ai connecté deux cartes réseau au routeur virtuel: le LAN et le WAN. J'ai ensuite été configurer les interfaces parce qu'elles ne vont pas se configurer d'elle-même !

La configuration réseau

Elle est toute simple. La carte du côté WAN reçoit une IP statique avec son masque et sa gateway qui permettra de passer les paquets en dehors du réseau local des VMs.

La carte sur le LAN est aussi assignée une IP statique et un masque. Rien d'autre.

Un coup de ip route montre que je suis sur la bonne voie puisque les routes des interfaces sont présentes:

default via 192.168.1.1 dev ens18 onlink
172.16.0.0/24 dev ens19 proto kernel scope link src 172.16.0.1
192.168.0.0/22 dev ens18 proto kernel scope link src 192.168.0.255

Le kernel a déjà inséré les routes qui vont bien pour les interfaces et c'est un bon début. On peut voir que la passerelle par défaut se situe à une adresse desservie sur l'interface ens18 (WAN). Cela signifie que si le paquet à une adresse de destination inconnue des routes, au lieu de dropper le paquet, le routeur va le balancer sur l'interface ens18 à destination de 192.168.1.1

Ce sera ensuite au tour du routeur 192.168.1.1 de faire suivre le paquet à l'extérieur ou sur son LAN.

Il fallait ensuite dire au routeur qui me sépare des intertubes de router les paquets du réseau 172.16.0.0/24 vers le routeur virtuel. Le paquet sera donc injecté sur l'interface ens19 du routeur virtuel à destination de l'hôte virtuel qui est concerné.

Cela va sans dire qu'il faut activer le forwarding IPv4 dans les paramètres du kernel.

En pratique

En théorie, ça marche. En pratique, un peu moins. J'ai tenté plein de trucs pour faire sortir ce fichu paquet ICMP du "grand" réseau, rien.

J'ai même fini par casser le réseau derrière Proxmox et rendu les containers et VMs inaccessibles. J'ai aussi tout réparé tant qu'à faire.

Je me suis repris le lendemain matin avec un peu plus de calme et des questions auquelles il fallait répondre.

Le second et dernier essai

Le problème était le NAT / le firewall du routeur principal qui droppait les paquets dont l'adresse source ne fait pas partie de son réseau. Cela explique pourquoi les paquets n'arrivaient pas à sortir. Un coup de SNAT sur l'interface WAN avec iptables et... WOAHHHH ÇA MARCHE ! \o/

Aun final, la séparation a pu être opérée avec un grand succès et les paquets sont capables de circuler dans les deux sens.

Cette séparation a permis de fix un petit bug très désagréable au passage, ce qui n'est pas plus mal. En plus, je comprends beaucoup mieux comment faire si je voulais router un paquet autre part et comment le routage se passe "en pratique".