Linux IPVLAN vs MACVLAN : Isolation réseau haute performance pour passerelles VPN

Les microservices conteneurisés et la virtualisation multi-entités constituent le standard moderne des infrastructures réseau de bordure. Lors du déploiement de passerelles VPN mutualisées—où différentes organisations clientes ou flottes d'agents requièrent des domaines de routage strictement séparés—les ingénieurs isolent traditionnellement le trafic à l'aide des espaces de noms réseau Linux (netns).

Toutefois, le mécanisme reliant ces espaces de noms isolés aux cartes d'interface physique (NIC) détermine directement la scalabilité du système. Les environnements d'exécution classiques connectent les conteneurs au moyen de paires d'Ethernet virtuel (veth) raccordées à un pont logiciel (br0). Sous une charge réseau soutenue de plusieurs gigabits, cette approche historique génère une lourde surcharge CPU, une double traversée du sous-système réseau et des hausses notables de latence de queue (p99).

Pour s'affranchir de ce coût de virtualisation, le noyau Linux propose deux technologies d'interface avancées : MACVLAN et IPVLAN. En maîtrisant les fondements architecturaux de ces pilotes, les architectes réseau peuvent concevoir des passerelles VPN conteneurisées à très haut débit garantissant une isolation cryptographique irréprochable.

---

Container Networking Bottlenecks: Le coût structurel de l'Ethernet virtuel (VETH)

Dans une configuration conteneur standard de type Docker ou Kubernetes, les paquets franchissent un parcours complexe entre l'interface réseau physique et le démon VPN hébergé :

1. Sortie de l'Espace de Noms : Le paquet émis quitte le conteneur par l'une des extrémités de la paire veth (eth0 dans l'espace de noms).
2. Commutation de Contexte : Le noyau intercepte le paquet et bascule le contexte d'exécution vers l'espace hôte où réside l'interface homologue (vethXXXX).
3. Transmission par le Pont Logiciel : L'interface veth hôte achemine le paquet vers un pont logiciel (br0). Celui-ci consulte les adresses MAC cibles, met à jour sa table de transmission (FDB) et applique les règles du protocole Spanning Tree.
4. Sortie sur la Carte Physique : Enfin, le pont transmet la trame à l'interface physique (eth0), impliquant un passage supplémentaire par le contrôle de trafic (tc) et les tampons en anneau du pilote.

Architecture classique VETH et Pont logiciel (Double traversée du sous-système réseau) :

[ Espace de noms Conteneur ]
              │
    (eth0 : extrémité veth)
              │
[ Espace de noms Hôte ]
              ▼
    (vethXXXX homologue)
              │
              ▼
[ Pont logiciel : br0 ] ──► (Recherches FDB, apprentissage MAC, verrous)
              │
              ▼
[ Carte réseau physique : eth0 ] ──► Câble réseau

Ce circuit à étapes multiples impose des contraintes sévères :

• Double Traitement Réseau : Chaque paquet subit deux fois les routines netif_rx() et dev_queue_xmit(), doublant les instructions processeur requises par trame.
• Contention des Verrous du Pont : Le pont Linux utilise des verrous tournants pour protéger sa table MAC. À des cadences atteignant plusieurs millions de paquets par seconde (Mpps), la contention dégrade l'efficacité globale.
• Perte de Localité de Cache : La migration répétée des structures de tampons (sk_buff) entre interfaces virtuelles dégrade la mémoire cache L1/L2, saturant le bus mémoire.

---

MACVLAN Architecture: Adresses MAC dédiées et suppression du pont virtuel

Introduit dans Linux 2.6.23, MACVLAN supprime entièrement le pont logiciel. Au lieu d'assembler des câbles virtuels, MACVLAN crée plusieurs sous-interfaces directement rattachées à une carte physique parente (comme eth0).

Chaque sous-interface MACVLAN dispose de sa propre adresse MAC matérielle. Une fois assignée à un espace de noms réseau, elle fonctionne comme une véritable interface réseau physique autonome.

1. Modes de fonctionnement de MACVLAN (Bridge, VEPA, Private, Passthru)

MACVLAN propose quatre modes de commutation distincts lors de sa configuration :

• Private : La sous-interface ne peut communiquer avec aucune autre sous-interface MACVLAN rattachée à la même interface parente. Tout le trafic est émis directement sur le réseau physique extérieur. Idéal pour séparer rigoureusement des clients distincts.
• VEPA (Virtual Ethernet Port Aggregator) : Les sous-interfaces ne peuvent échanger des flux que si le commutateur physique amont prend en charge le mode réflexion ("hairpin"), renvoyant les trames sur le port source.
• Bridge : Les sous-interfaces communiquent directement entre elles via un commutateur L2 interne au noyau, hautement optimisé et infiniment plus léger qu'un pont logiciel classique.
• Passthru : Octroie le contrôle exclusif de la carte physique à une unique sous-interface fille, utile pour déléguer une carte entière à un conteneur dédié.

2. Le problème de saturation MAC : Sécurité des ports et blocages Wi-Fi

Bien que MACVLAN offre des performances proches du matériel brut, cette approche présente deux limitations opérationnelles majeures :

1. Saturation des Tables MAC des Commutateurs : Étant donné que chaque interface MACVLAN annonce une adresse MAC unique, déployer des centaines de passerelles VPN sature la table CAM des commutateurs physiques. Les équipements d'entreprise appliquant la sécurité des ports (Port Security) bloquent le port dès qu'ils détectent plusieurs adresses MAC.
2. Incompatibilité Wi-Fi : La norme sans fil IEEE 802.11 interdit strictement l'utilisation de plusieurs adresses MAC sur une association cliente standard. En conséquence, MACVLAN est inutilisable sur les passerelles périphériques connectées en Wi-Fi.

---

IPVLAN Mechanics: Identité L2 partagée et routage multicouche

Pour surmonter les contraintes de MACVLAN, le noyau Linux a introduit la technologie IPVLAN à partir de la version 3.19. Au lieu d'attribuer une adresse MAC distincte à chaque point de terminaison, IPVLAN partage l'unique adresse MAC de l'interface parente physique entre toutes les interfaces filles.

L'aiguillage des paquets vers le conteneur adéquat s'effectue en inspectant l'adresse IP de destination de couche 3 (Layer 3), sans modifier la trame Ethernet.

Architecture IPVLAN (Adresse MAC unifiée, aiguillage par adresse IP) :

[ Espace VPN A ]             [ Espace VPN B ]
(ipv0 : 10.0.1.2)           (ipv1 : 10.0.1.3)
        │                           │
        └─────────────┬─────────────┘
                      │
           [ Pilote cœur IPVLAN ]
(MAC partagée : 52:54:00:12:34:56, Filtrage par IP cible)
                      │
                      ▼
        [ Carte physique : eth0 ] ──► Câble réseau

1. Comparaison entre les modes IPVLAN L2 et IPVLAN L3

IPVLAN se décline en deux modes fondamentaux de transmission :

• IPVLAN Mode L2 : Se comporte comme un commutateur L2. Les interfaces filles appartiennent au même sous-réseau que l'interface parente. Le trafic de diffusion (ARP, NDP) pénètre dans les conteneurs. Le commutateur extérieur ne perçoit qu'une seule adresse MAC physique, respectant ainsi les politiques de sécurité du réseau local.
• IPVLAN Mode L3 : Transforme l'interface en un routeur L3 interne. La carte parente applique des décisions de routage pur sans relayer les diffusions Ethernet ni les requêtes ARP. Les interfaces filles doivent résider dans des sous-réseaux distincts. En supprimant les tempêtes de diffusion, le mode L3 offre un rendement maximal, constituant le choix privilégié pour les passerelles VPN denses.

2. Pare-feu d'état et suivi de connexions avec le mode L3S

Dans les premières implémentations du mode L3, les flux échangés avec les conteneurs ne déclenchaient pas le suivi de connexion netfilter (conntrack) de l'hôte, compliquant la gestion centralisée des règles de sécurité.

Linux 4.15 a apporté le mode IPVLAN L3S (Symmetric). En mode L3S, les paquets entrants et sortants traversent les points d'ancrage netfilter de l'espace hôte avant d'atteindre le conteneur, autorisant un filtrage d'état complet (iptables / nftables) et la translation NAT sans nécessiter de pont virtuel.

---

Performances et niveau d'isolation : Comparatif VETH vs. MACVLAN vs. IPVLAN

Le tableau suivant récapitule les compromis techniques entre ces trois solutions de virtualisation :

---

Configuration en production : Déploiement d'IPVLAN pour conteneurs VPN

La mise en œuvre d'un espace de noms VPN haute performance exploitant le mode IPVLAN L3 se réalise simplement au moyen de la suite iproute2 :

# 1. Créer l'espace de noms dédié à la passerelle VPN client
sudo ip netns add vpn-tenant-alpha

# 2. Créer l'interface IPVLAN fille sur la carte eth0 en mode L3
sudo ip link add link eth0 name ipv0 type ipvlan mode l3

# 3. Transférer l'interface IPVLAN dans l'espace de noms cible
sudo ip link set dev ipv0 netns vpn-tenant-alpha

# 4. Assigner l'adresse IP interne au conteneur
sudo ip -n vpn-tenant-alpha addr add 10.200.1.2/24 dev ipv0
sudo ip -n vpn-tenant-alpha link set dev ipv0 up
sudo ip -n vpn-tenant-alpha link set dev lo up

# 5. Définir la passerelle par défaut dans l'espace de noms
sudo ip -n vpn-tenant-alpha route add default dev ipv0

# 6. Vérifier l'interface directe sans pont logiciel
sudo ip netns exec vpn-tenant-alpha ip addr show dev ipv0

Pour activer le filtrage d'état symétrique au niveau de l'hôte, il suffit d'ajuster le paramètre mode l3s lors de l'instanciation :

sudo ip link add link eth0 name ipv0 type ipvlan mode l3s

---

Architecture RiceGuard : Isolation multi-entités haute densité

Dans l'infrastructure VPNRice, les passerelles d'entreprise agrègent des milliers de sessions chiffrées issues d'organisations totalement indépendantes. Déployer une machine virtuelle par organisation entraînerait une empreinte mémoire excessive, tandis que le réseau conteneur VETH classique bride les débits sous chiffrement intensif.

RiceGuard tire parti d'IPVLAN en mode L3/L3S pour assurer une virtualisation à très forte densité :

/* Provisionnement de l'interface IPVLAN d'un espace client dans RiceGuard */
int provision_tenant_ipvlan_interface(const char *parent_dev, const char *child_dev, 
                                      int netns_fd, int l3s_mode) {
    /* Sélection du mode IPVLAN : IPVLAN_MODE_L3 ou IPVLAN_MODE_L3S */
    uint16_t mode = l3s_mode ? IPVLAN_MODE_L3S : IPVLAN_MODE_L3;
    
    /* Émission d'une requête Netlink RTM_NEWLINK pour créer l'interface fille */
    if (netlink_create_ipvlan(parent_dev, child_dev, mode) < 0) {
        perror("netlink_create_ipvlan");
        return -1;
    }

    /* Déplacement de l'interface fille dans l'espace de noms du client */
    return netlink_move_device_to_netns(child_dev, netns_fd);
}

Grâce à IPVLAN L3, chaque environnement client RiceGuard s'exécute dans un espace de noms isolé doté de tables de routage et de filtrage propres. Les trames circulent directement entre la carte réseau physique et les sockets WireGuard sans intermédiaire logiciel superflu, sans prolifération d'adresses MAC, et avec une latence inférieure à la milliseconde.