Linux SO_BINDTODEVICE et SO_BINDTOIFINDEX : sockets et étanchéité VPN

Le défi de la liaison d'interface sur les hôtes VPN multiréseaux

Les architectures réseau Linux modernes fonctionnent fréquemment dans des configurations multiréseaux (multi-homed), où interfaces physiques (eth0, wlan0), connexions cellulaires (wwan0) et adaptateurs virtuels (wg0, tun0) cohabitent sur la même machine. Par défaut, la sélection du chemin de sortie (egress) repose sur la base d'informations de routage FIB (Forwarding Information Base) et les règles de politique de routage (ip rule). Lorsqu'une application invoque connect() ou sendto(), le sous-système de routage du noyau sélectionne la passerelle en fonction de l'adresse IP de destination, de l'adresse source, des marques de paquets (fwmark) et de métriques définies.

Néanmoins, une dépendance exclusive envers les tables de routage générales expose les déploiements VPN à des vulnérabilités critiques. Si le tunnel virtuel subit une interruption transitoire, si le bail DHCP met à jour la passerelle par défaut, ou si un administrateur réinitialise les tables de routage, les paquets applicatifs peuvent s'échapper silencieusement via la carte physique en clair. Ce phénomène de fuite de routage (routing leak) expose directement les données utilisateur et les requêtes DNS aux fournisseurs d'accès Internet.

En outre, les démons VPN clients doivent gérer l'épineux problème de la récursion de routage : le processus VPN doit émettre ses paquets UDP encapsulés via l'interface physique externe, tandis que les autres applications locales doivent transmettre leur trafic exclusivement dans le tunnel virtuel. Si la configuration de routage fléchit, les paquets chiffrés sont réinjectés dans l'interface virtuelle, saturant immédiatement les mémoires tampons et provoquant l'interruption du service.

Le noyau Linux répond à ces vulnérabilités au niveau de la couche d'abstraction des sockets grâce aux options SO_BINDTODEVICE et SO_BINDTOIFINDEX. En ancrant directement une socket réseau à un indice de périphérique donné, la décision de routage est verrouillée à la source, prévalant sur les recherches générales de tables.

+-------------------------------------------------------------------------+
|                         Application Utilisateur                         |
+-------------------------------------------------------------------------+
                                     |
               setsockopt(..., SOL_SOCKET, SO_BINDTODEVICE, "wg0", ...)
                                     |
+------------------------------------+------------------------------------+
| Couche Socket du Noyau Linux (net/core/sock.c)                          |
| -> Assigne sk->sk_bound_dev_if = ifindex("wg0")                         |
+-------------------------------------------------------------------------+
                                     |
         +---------------------------+---------------------------+
         |                                                       |
         v                                                       v
+-----------------------------+             +-----------------------------+
|    Recherche de route FIB   |             |   Défaillance de liaison    |
| (FIB restreint la recherche |             | (L'interface wg0 est arrêtée|
|  à la seule interface wg0)  |             |                             |
+-----------------------------+             +-----------------------------+
         |                                                       |
         v                                                       v
Transmission sécurisée via wg0              Le noyau renvoie ENETUNREACH / ENODEV
(Aucune fuite de données)                   (Aucun paquet transmis sur eth0)

Mécanismes internes du noyau : SO_BINDTODEVICE vs SO_BINDTOIFINDEX

Dans le code source du noyau Linux (net/core/sock.c), l'information de liaison d'interface est stockée directement dans la structure socket :

struct sock {
    ...
    int sk_bound_dev_if; /* Indice du périphérique lié si > 0 */
    ...
};

Lorsqu'une application fait appel à setsockopt avec l'option SO_BINDTODEVICE, elle transmet une chaîne de caractères représentant le nom de l'interface (comme "wg0" ou "eth0"). La fonction interne sock_setbindtodevice() applique les étapes suivantes :

1. Acquisition du verrou exclusif de la socket (lock_sock).
2. Si la chaîne est vide, réinitialisation de sk->sk_bound_dev_if = 0 pour détacher la socket.
3. Si un nom est fourni, appel de dev_get_by_name(net, devname) pour identifier le périphérique réseau au sein du namespace réseau de la socket.
4. En cas de succès, l'indice entier 32 bits (dev->ifindex) est copié dans sk->sk_bound_dev_if.
5. Gestion rigoureuse des compteurs de référence de périphérique afin d'éviter les fuites de mémoire.

Depuis la version 5.0 du noyau Linux, l'option SO_BINDTOIFINDEX offre une alternative optimisée. Au lieu de transmettre un tampon textuel nécessitant une copie mémoire et une résolution de nom, l'espace utilisateur transmet directement l'entier numérique ifindex :

int ifindex = if_nametoindex("wg0");
if (ifindex > 0) {
    setsockopt(sockfd, SOL_SOCKET, SO_BINDTOIFINDEX, &ifindex, sizeof(ifindex));
}

Cette amélioration supprime les opérations de manipulation de chaînes dans les passerelles réseau et serveurs mandataires à haut débit, où des milliers de sockets sont créées et associées simultanément.

Évaluation des routes FIB et contraintes d'interface

Lorsqu'un datagramme sortant est produit sur une socket liée, la pile réseau initialise une structure de flux (struct flowi4 pour IPv4 ou struct flowi6 pour IPv6). La valeur de sk->sk_bound_dev_if est affectée directement au champ flowi4_oif :

struct flowi4 fl4 = {
    .flowi4_oif = sk->sk_bound_dev_if,
    .daddr = dst_ip,
    .saddr = src_ip,
    ...
};

Lors de l'interrogation de la base FIB (fib_lookup() dans net/ipv4/fib_frontend.c), le sous-système de routage rejette systématiquement toutes les routes qui ne concordent pas avec flowi4_oif :

• Même si une route par défaut 0.0.0.0/0 existe sur eth0 avec une métrique avantageuse, le moteur de routage l'ignore si flowi4_oif cible l'interface wg0.
• Le noyau ne retient que les entrées dont le périphérique de sortie correspond strictement à wg0.
• Si l'interface virtuelle est désactivée administrativement (ip link set wg0 down), la résolution de route échoue instantanément. Le noyau renvoie l'erreur -ENETUNREACH (Network is unreachable) à l'application.

En aucun cas le noyau Linux ne redirige automatiquement les paquets vers une autre interface physique lorsque sk_bound_dev_if est actif. Cette garantie forme le pilier des systèmes anti-fuite.

Prévention des boucles de routage sans dépendre de Fwmark

Pour empêcher le trafic chiffré du démon VPN d'être réinjecté dans son propre tunnel, la méthode classique utilise le routage par politiques :

1. Définir une règle ip rule ciblant la marque fwmark 51820.
2. Diriger l'ensemble du trafic non marqué vers la table de routage du VPN.
3. Configurer le démon pour apposer SO_MARK = 51820 sur ses paquets UDP externes.

Bien que fonctionnelle, cette architecture reste vulnérable aux conflits entre scripts iptables, règles nftables et priorités ip rule. Si un outil de sécurité réinitialise les chaînes de filtrage, la protection contre les boucles s'effondre.

Routage par politiques classique (Vulnérable aux conflits de règles) :
Paquet -> Marquage Netfilter -> Règle ip rule -> Table VPN ou Table WAN

Verrouillage au niveau socket (Garanti par le noyau) :
Démon VPN externe  -> SO_BINDTOIFINDEX(eth0) -> Transmission directe sur eth0
Sockets applicatives -> SO_BINDTOIFINDEX(wg0)  -> Transmission directe dans wg0

Grâce à SO_BINDTODEVICE ou SO_BINDTOIFINDEX, le comportement devient déterministe :

• Le démon VPN détermine l'indice de l'interface physique active reliée à Internet (eth0_idx).
• Il applique setsockopt(tunnel_fd, SOL_SOCKET, SO_BINDTOIFINDEX, &eth0_idx, sizeof(eth0_idx)).
• Tous les paquets UDP sortant de cette socket sont transmis à eth0, ignorant la route par défaut pointant sur wg0.

Fonction d'arrêt d'urgence (Killswitch) au niveau du système d'exploitation

Les mécanismes d'arrêt d'urgence (Killswitch) surveillant le réseau en espace utilisateur introduisent inévitablement un délai de détection. Lorsqu'un lien tombe, le démon de surveillance met plusieurs dizaines à plusieurs centaines de millisecondes pour analyser l'événement netlink et déployer des règles de pare-feu. Durant cet intervalle, des sessions TCP existantes peuvent basculer sur l'interface physique et diffuser des données non protégées.

Le verrouillage de socket opère de façon synchrone au cœur du noyau :

L'association étant directement rattachée au descripteur de fichier de la socket, les processus enfants et les connexions actives restent protégés pendant toute leur durée de vie.

Implémentation pratique en C et intégration VRF

1. Création d'une socket verrouillée en langage C

Le fragment de code ci-dessous montre comment une application associe fermement sa socket à une interface de tunnel :

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <net/if.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <errno.h>

int create_pinned_socket(const char *interface_name) {
    int fd = socket(AF_INET, SOCK_STREAM, 0);
    if (fd < 0) {
        perror("Erreur socket");
        return -1;
    }

    /* Résolution de l'indice numérique de l'interface */
    unsigned int ifindex = if_nametoindex(interface_name);
    if (ifindex == 0) {
        fprintf(stderr, "Interface %s inexistante : %s\n",
                interface_name, strerror(errno));
        close(fd);
        return -1;
    }

    /* Méthode recommandée : SO_BINDTOIFINDEX (Linux 5.0+) */
    if (setsockopt(fd, SOL_SOCKET, SO_BINDTOIFINDEX,
                   &ifindex, sizeof(ifindex)) < 0) {
        /* Solution de repli pour noyaux plus anciens */
        if (setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE,
                       interface_name, strlen(interface_name) + 1) < 0) {
            perror("Erreur setsockopt SO_BINDTODEVICE");
            close(fd);
            return -1;
        }
    }

    return fd;
}

2. Évolution des privilèges dans les noyaux récents

Historiquement, l'appel à SO_BINDTODEVICE exigeait les privilèges root ou la capacité CAP_NET_RAW. Dans les architectures conteneurisées, accorder CAP_NET_RAW élargit la surface d'attaque.

Depuis Linux 5.7, le noyau a assoupli cette exigence :

• Un processus standard peut lier sa socket si celle-ci appartient à un namespace utilisateur possédant le namespace réseau cible (ns_capable(net->user_ns, CAP_NET_RAW)).
• Les applications peuvent s'associer aux interfaces de leur propre environnement réseau sans privilèges élevés, dès lors qu'elles ne franchissent pas de frontière d'isolation.
• Les démons système peuvent configurer la socket lors de l'initialisation, puis renoncer à leurs privilèges (setuid()) tout en conservant le descripteur verrouillé.

3. Synergie avec les domaines de routage virtuel VRF

Dans les architectures exploitant Linux VRF (l3mdev), les périphériques maîtres VRF fonctionnent comme des interfaces réseau complètes. Assigner SO_BINDTODEVICE à un équipement maître VRF (ex. vrf-secure) dirige toutes les requêtes vers la table FIB dédiée de ce domaine.

Si la socket est liée à une interface esclave (comme wg0 intégrée dans vrf-secure), une double contrainte s'applique : l'émission est restreinte au périphérique physique wg0 tout en respectant l'isolation stricte du domaine VRF.

Architecture de verrouillage à deux niveaux dans RiceGuard

VPNRice intègre l'ancrage d'interface comme une composante structurelle de son protocole RiceGuard. Au lieu de dissocier les règles de pare-feu et les états de connexion, l'architecture établit un modèle à deux niveaux :

[ Processus Applicatifs et Résolveur DNS ]
       |
       v
  Couche Socket : Verrouillage sur l'interface RiceGuard (wg0 / rice0)
  Bénéfice : Suppression intégrale des fuites DNS et des détournements locaux
       |
[ Moteur Cryptographique de Transport RiceGuard ]
       |
       v
  Socket de Transport : Verrouillage sur l'ifindex du port WAN physique actif
  Bénéfice : Acheminement fluide sans risque de boucle récursive

1. Isolation stricte des flux applicatifs : Le client VPNRice verrouille les sockets de résolution DNS et les flux applicatifs sur l'interface virtuelle du tunnel. Même en cas de reconnexion intempestive au réseau sans fil, aucun paquet non chiffré ne peut franchir les interfaces physiques.
2. Transition dynamique transparente : Lors d'un basculement de liaison physique (du Wi-Fi vers un réseau filaire), le module de transport de RiceGuard identifie l'indice du nouvel équipement et met à jour la socket via SO_BINDTOIFINDEX sans interrompre la session chiffrée.
3. Protection contre les altérations en réseau public : En validant les indices de périphériques directement dans la socket, le système neutralise les tentatives de détournement de passerelle par des serveurs DHCP compromis sur les bornes publiques.

L'exploitation des fonctions natives du noyau Linux confère aux passerelles modernes une étanchéité de routage vérifiable et des débits optimaux.