Linux eBPF Sockmap et sk_msg : Redirection de sockets pour proxy VPN

Les infrastructures modernes dédiées à la confidentialité et à la sécurité réseau reposent fréquemment sur des démons proxy locaux, des relais applicatifs ou des conteneurs sidecars cohabitant sur le même serveur. Dans une architecture VPN modulaire, les logiciels clients établissent d'abord une connexion vers un socket proxy local chargé d'inspecter, d'encapsuler ou de chiffrer le flux avant sa transmission dans un tunnel sécurisé. Bien que cette approche favorise la modularité, la pile réseau Linux standard génère une pénalité notable : chaque octet doit traverser la totalité de la pile TCP/IP à deux reprises.

Le noyau Linux fournit une solution novatrice grâce aux technologies eBPF (extended Berkeley Packet Filter) : la combinaison d'une table BPF_MAP_TYPE_SOCKMAP (ou SOCKHASH) et d'un programme BPF_PROG_TYPE_SK_MSG. En intervenant directement au niveau de l'interface des sockets plutôt qu'au niveau des paquets réseau physiques, eBPF sockmap transfère les charges utiles depuis la mémoire du socket émetteur vers la file de réception du socket récepteur, sans nécessiter de segmentation TCP, de routage IP ni de traitement d'interruptions logicielles sur l'interface loopback.

Le fardeau de la double traversée dans les architectures proxy

Pour appréhender le gain opérationnel offert par sockmap, examinons le cheminement d'un flux classique traversant un proxy VPN local :

[ Application cliente ]
       | write() / sendmsg()
[ Couche Socket : File d'émission (TX Queue) ]
       v
[ Machine d'états TCP (Contrôle d'encombrement, acquittements) ]
       v
[ Couche IP (Consultation des tables de routage, calcul MTU) ]
       v
[ Filtrage Netfilter / iptables (Tables PREROUTING, FORWARD) ]
       v
[ Interface Loopback (Appels dev_queue_xmit, ordonnancement ksoftirqd) ]
       v
[ Filtrage Netfilter / iptables (Tables PREROUTING, INPUT) ]
       v
[ Couche IP (Acheminement vers l'hôte local) ]
       v
[ Machine d'états TCP (Vérification des séquences et réassemblage) ]
       v
[ Couche Socket : File de réception (RX Queue) du proxy VPN ]
[ Démon proxy VPN ]

Lorsqu'une application envoie un bloc de 64 Ko vers 127.0.0.1:1080 (port d'écoute SOCKS5 ou HTTP CONNECT du proxy), le système d'exploitation alloue des structures sk_buff, calcule les sommes de contrôle, consulte les tables de routage et déclenche des interruptions douces (NET_RX_SOFTIRQ). Lorsque le proxy lit ce bloc pour l'injecter dans un tunnel chiffré (tel que WireGuard ou RiceGuard), cette séquence s'exécute une seconde fois.

Sur des passerelles gérant des milliers de connexions simultanées, cette redondance consomme plus de 25 % des cycles du processeur central, réduisant l'efficacité de la mémoire cache et dégradant la latence de queue (tail latency).

Architecture eBPF Sockmap et programmes sk_msg

Le mécanisme de commutation directe de sockets associe deux programmes eBPF complémentaires via une table de hachage interne du noyau :

1. Enregistrement des connexions via BPF_PROG_TYPE_SOCK_OPS

Le programme de supervision des sockets est rattaché à une hiérarchie de groupes de contrôle (cgroups). Chaque fois qu'un socket TCP subit un changement d'état, le noyau exécute ce programme eBPF avec le contexte bpf_sock_ops.

Lors de la finalisation des liaisons—précisément lors des événements BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB (connexion sortante de l'application) et BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB (connexion entrante acceptée par le proxy)—le programme extrait la clé d'identification à quatre éléments :

struct sock_key {
    __u32 sip4;
    __u32 dip4;
    __u32 sport;
    __u32 dport;
};

struct {
    __uint(type, BPF_MAP_TYPE_SOCKHASH);
    __uint(max_entries, 65536);
    __type(key, struct sock_key);
    __type(value, __u64);
} proxy_sock_map SEC(".maps");

SEC("sockops")
int bpf_sockmap_ops(struct bpf_sock_ops *skops) {
    if (skops->family != AF_INET)
        return 1;

    switch (skops->op) {
    case BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB:
    case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB: {
        struct sock_key key = {
            .sip4  = skops->local_ip4,
            .dip4  = skops->remote_ip4,
            .sport = bpf_ntohl(skops->local_port),
            .dport = skops->remote_port,
        };
        /* Enregistrement de la structure socket dans la table du noyau */
        bpf_sock_hash_update(skops, &proxy_sock_map, &key, BPF_ANY);
        break;
    }
    default:
        break;
    }
    return 1;
}

L'appel à la fonction bpf_sock_hash_update() insère la référence du socket (struct sock *) dans la table proxy_sock_map. Les applications continuent d'utiliser leurs descripteurs de fichiers habituels en espace utilisateur sans modification de code.

2. Redirection instantanée via BPF_PROG_TYPE_SK_MSG

La seconde composante est attachée au point de verdict BPF_SK_MSG_VERDICT de la table proxy_sock_map. Lorsqu'un processus effectue l'appel système sendmsg() ou write(), le noyau déclenche ce programme avant toute mise en paquet :

SEC("sk_msg")
int bpf_sk_msg_redirect(struct sk_msg_md *msg) {
    struct sock_key lookup_key = {
        .sip4  = msg->remote_ip4,
        .dip4  = msg->local_ip4,
        .sport = msg->remote_port,
        .dport = bpf_ntohl(msg->local_port),
    };

    /* Raccordement direct vers la file de réception du socket distant */
    int ret = bpf_msg_redirect_hash(msg, &proxy_sock_map, &lookup_key, BPF_F_INGRESS);
    if (ret == SK_PASS)
        return SK_PASS;

    return SK_PASS;
}

Dès que la fonction bpf_msg_redirect_hash() localise le socket correspondant, elle déplace les tampons mémoire de données directement dans la file de réception (sk_receive_queue) du socket partenaire :

• Aucune structure de paquet sk_buff n'est allouée.
• Les numéros de séquence TCP et les fenêtres sont maintenus au niveau transport sans émission sur le réseau physique.
• Les chaînes de règles Netfilter et iptables ne sont pas évaluées.
• Les interruptions logicielles liées au loopback sont éliminées.

Évaluation quantitative des gains de performance

Les tests comparatifs menés sur des passerelles VPN sous environnement Linux mettent en évidence un saut qualitatif majeur :

En évitant les encapsulations intermédiaires, les cœurs CPU préservent leurs données actives en cache, limitant les changements de contexte pénalisants.

Déploiement au sein de VPNRice et RiceGuard

Au sein de l'écosystème VPNRice, l'accélération sockmap est mise à profit sur les serveurs passerelles et les postes clients pour plusieurs fonctions critiques :

[ Navigateur de travail ]
       |
       | (Commutation directe de sockets via eBPF sk_msg)
       v
[ Relais local RiceGuard ]
       |
       | Chiffrement ChaCha20-Poly1305 AEAD
       v
[ Nœud d'accès Anycast VPNRice ]

1. Relais locaux RiceGuard : Les transferts entre les applications clientes et le démon local s'opèrent à la vitesse de la mémoire partagée, permettant au moteur cryptographique de RiceGuard de saturer les liaisons sans saturer le processeur hôte.
2. Prévention des fuites DNS : Les requêtes transmises sur le port 53 sont interceptées localement et dirigées vers les résolveurs DoH/DoT sans ajouter de latence lors du passage entre les espaces de noms réseau (network namespaces).
3. Interopérabilité en conteneurs : Sur les passerelles multi-locataires, sockmap autorise des communications inter-conteneurs fluides, sans surcharger les ponts virtuels (veth bridges).

Prérequis du noyau et diagnostic système

L'exploitation du mécanisme eBPF sockmap nécessite un noyau Linux (version 5.10 ou supérieure recommandée) intégrant les options d'analyse de flux :

# Vérification des options du noyau actif
zcat /proc/config.gz | grep -E "CONFIG_BPF_STREAM_PARSER|CONFIG_NET_SOCK_MSG"
# Résultat attendu :
# CONFIG_BPF_STREAM_PARSER = y
# CONFIG_NET_SOCK_MSG = y

Les administrateurs peuvent inspecter l'état des tables en mémoire et observer les événements en temps réel :

# Afficher les tables sockhash enregistrées
sudo bpftool map list type sockhash

# Consulter les traces d'exécution du noyau
sudo bpftool prog tracelog

L'orchestration programmable des sockets au cœur du noyau et les protocoles légers créent une passerelle performante, démontrant que rigueur cryptographique et réactivité maximale peuvent s'accorder harmonieusement.