Kill switch VPN sans magie : comment le noyau du système d'exploitation interrompt le trafic et protège votre vie privée

Introduction : pourquoi un kill switch VPN est indispensable en 2026

Objectifs et réalité : ce que nous protégeons vraiment

Une question simple, mais lourde de sens : que seriez-vous prêt à perdre en une seconde sans VPN ? Votre adresse IP, l’historique de vos requêtes, les données de vos applications ? En 2026, avec des applications qui synchronisent tout et des navigateurs qui maintiennent des dizaines de connexions en arrière-plan, le seul vrai rempart est le kill switch VPN. Il impose une règle stricte : dès que le tunnel tombe, tout le trafic est bloqué sans exception. Pas de « peut-être », pas de « ça tiendra probablement ». On coupe tout, sauf le flux passant par l’interface sécurisée. Ça paraît simple ? En réalité, sous le capot, c’est une élégante chorégraphie entre le noyau OS, les tables de routage, les marquages de paquets, les pilotes et les règles du firewall.

Pourquoi c’est crucial maintenant

Les risques ont explosé. Caméras domestiques, messagerie cloud, messageries ultra-sensibles, portefeuilles cryptos — tout se connecte automatiquement et en permanence. Le moindre tremblement du tunnel, une seule seconde, et une fuite DNS survient, ou une API dévoile votre IP réelle. Oui, une seconde suffit. On a vu des cas concrets : mise à jour du pilote réseau sous Windows 11 24H2, micro-lags sur le Wi-Fi, changement de réseau sur un portable — et voilà. Le kill switch ne discute pas, il agit : il coupe net. Et tient bon jusqu’à la stabilisation du tunnel.

En bref : que fait le kill switch

Le kill switch, ce n’est pas un simple bouton « couper Internet ». C’est un ensemble de règles intégrées dans la pile réseau et le firewall du système, qui garantissent que seuls les paquets transitant via l’interface VPN (tun, tap, utun, wg, ikev2) peuvent accéder au réseau ; les paquets contournant le tunnel sont immédiatement jetés aux premières interceptions. Il y a aussi un contrôle strict du DNS : les résolutions passent par le VPN, les résolveurs locaux hors tunnel sont interdits. Et tout cela doit tourner au niveau du noyau, pas dans une « appli à boutons ». Sinon, c’est la course aux conditions, et la confidentialité part en fumée.

Fonctionnement du kill switch au niveau du noyau : anatomie de la pile réseau

Routage, sockets et hooks : où les paquets sont interceptés

Dans le noyau OS, les paquets traversent plusieurs étapes : création du socket par l’application, choix du chemin, application des règles firewall, traitement par l’interface, envoi. Le kill switch insère habilement un « barrage » à deux endroits : dans les tables de routage (pour orienter tout le trafic par défaut vers le tunnel) et dans le firewall (pour rejeter immédiatement tout ce qui n’est pas marqué « via VPN »). Cette double interception évite les ratés : si la route clignote, le firewall sauve la mise ; si le firewall n’a pas encore pris en compte l’interface, c’est la route qui empêche la fuite.

Noyau Windows : WFP et filtres NDIS

Sur Windows, c’est Windows Filtering Platform (WFP) qui joue ce rôle crucial. Le client VPN installe un pilote callout ou utilise les couches systèmes pour filtrer aux niveaux transport et réseau, marquer le trafic VPN et bloquer le reste. Des profils firewall sont aussi configurés : règle « bloquer les sorties sauf via l’interface VPN ». Au niveau de la pile NIC, des pilotes NDIS LWF peuvent intervenir, mais en 2026, la tendance est au WFP seul, pour préserver la compatibilité avec Windows 11 24H2 et HVCI.

Linux : netfilter, nftables et cgroup-bpf

Sur Linux, le kill switch repose généralement sur netfilter. La recommandation moderne est nftables (noyaux 5.10+ voire 6.x) : on crée des chaînes output/forward avec politique drop, on autorise uniquement les paquets marqués ou via interface spécifique (par exemple wg0). La policy routing est ajoutée : le trafic avec fwmark suit une table dédiée vers le tunnel, le défaut passe par le tunnel, tout le reste est renvoyé dans un trou noir. Pour les config avancées, cgroup-bpf (BPF_CGROUP_INET_EGRESS) permet de filtrer par processus — par exemple, votre ssh admin peut sortir du kill switch pour le debug, les autres non. Flexible et rapide.

macOS : Network Extension et PF

Sur macOS, on se repose sur Network Extension (NE) et le Packet Filter (PF). Le client NE contrôle le tunnel (interface utun), tandis que PF, via des anchors, applique une politique restrictive : blocage total des sorties sauf sur utunX et services autorisés. Le DNS est forcé via NEAppProxyProvider ou les réglages systèmes, pour que les requêtes passent par le VPN. Depuis macOS 14+, Apple a stabilisé NE, et en 2026, les clients matures maintiennent des règles PF stables même lors de changements de réseau.

Tables de routage : la clé pour casser ou sauver la confidentialité

Route par défaut : centre névralgique

L’erreur classique : deux routes par défaut, vers le réseau physique et vers le tunnel. Le système choisit la « meilleure » selon la métrique. Lors de reconnexions, changement de Wi-Fi ou réveil, ces métriques varient. Résultat : certains paquets passent hors VPN, souvent les requêtes DNS rapides. Un kill switch bien fait configure la route par défaut vers le VPN, le reste est bloqué, et l’ajout d’une interface physique ne doit pas restaurer la route précédente.

Policy routing et fwmark : la chirurgie Linux

Sur Linux, la recette est claire et fiable. On marque les paquets des applis devant passer par le tunnel (ou tout le trafic si le kill switch est total), on crée une table de routage séparée avec défaut vers le tunnel, l’original est vide ou mène à un trou noir. En cas de chute d’interface, le trafic hors tunnel n’a plus de sortie. C’est un système “béton”, surtout combiné à nftables qui permet des conditions fines : interface, groupe de processus, UID, ports, domaines (via sets et maps).

Windows : métriques et profils d’interface

Windows aime l’« autonomie ». On fixe donc les métriques d’interface : VPN a la plus basse, physiques plus hautes. On crée des règles firewall autorisant les sorties uniquement via l’interface VPN (par InterfaceAlias ou InterfaceType). En cas de chute, le firewall bloque tout, sauf peut-être les adresses locales 127.0.0.0/8 et link-local pour maintenir la stabilité OS. En 2026, beaucoup de clients corrigent automatiquement ces métriques et restaurent les règles après redémarrage du service BFE, un point faible auparavant.

macOS : routes persistantes et anchors PF

Sur macOS, la stratégie PF fonctionne solide : on crée un anchor avec politique par défaut bloquante, n’autorisant que les règles où l’interface est utunX. Les routes persistantes VPN sont configurées via NE automatiquement ; PF empêche toute « fuite » hors tunnel. Important : après sommeil ou changement de réseau, il faut mettre à jour le numéro utun, qui peut changer. Les bons clients gèrent ça automatiquement en écoutant les événements NE.

Règles firewall : comment se construit le blocage

Linux : nftables remplace iptables

En 2026, iptables est toujours là, mais dépassé. On procède ainsi : créer une table inet vpn avec chaînes input, forward, output où output a une politique drop. On autorise : connexions établies et liées, interface wg0 (ou tun0), DNS via wg0, localhost si besoin. Ajout d’une règle : si l’interface n’est pas wg0, drop, sinon accept. Pour sécuriser, les règles nftables peuvent aussi jongler finement avec la direction du trafic quand l’interface est down, mais souvent le strict output suffit.

Windows : AdvFirewall et WFP

Procédure : créer une règle block-outbound globale, puis une exception pour l’interface VPN. L’interface graphique est laborieuse, donc PowerShell est préféré. On ajoute New-NetFirewallRule avec paramètres Direction=Outbound, Action=Block pour tous les profils, puis des Allow ciblés par InterfaceAlias. Les clients modernes vont plus loin : ils installent un callout WFP qui bloque les paquets avant la pile TCP, marque les paquets VPN, assurant qu’aucune règle Allow accidentelle ne passe. C’est plus rapide et fiable que les règles classiques.

macOS : PF avec anchors et states

PF domine : set block-policy drop, set skip on lo0, anchor vpn-killswitch avec des règles allow out strictes sur utunX, blocages sur toutes les autres interfaces. Le traitement stateful rend la vie agréable aux applications. Protection DNS également : bloquer udp/53 sur toutes interfaces sauf utun. Si vous utilisez DoH dans le tunnel, parfait, bloquez globalement le 53 et laissez tcp/443 via utun.

DNS : un front à part

Le DNS est le canal de fuite le plus sournois. La règle est simple : résolution soit via VPN, soit pas du tout. Sous Linux, on redirige resolv.conf vers un résolveur local n’écoutant que sur l’interface tun, ou on utilise systemd-resolved avec routage par domaine. Sous Windows, on active « Block outside DNS » (flag OpenVPN disponible) et le firewall bloque udp/53 en dehors du VPN. Sur macOS, on configure DNS scoped via NE, et PF bloque le 53 hors utun. Et oui, vérifiez vos clients DoH (les navigateurs savent être malins) : ils doivent utiliser la pile système ou un endpoint DoH accessible uniquement via le tunnel.

Comment les clients VPN implémentent le kill switch : analyse pratique

WireGuard : marquages et AllowedIPs

WireGuard est rapide, simple et fiable. Couplé à wg-quick, le kill switch repose sur deux idées : AllowedIPs couvre tout le trafic (0.0.0.0/0, ::/0) et les tables de routage plus fwmark forcent le trafic vers l’interface wg. En cas de chute, nftables bloque toute sortie. À la demande, Table=off permet une policy routing manuelle, flexible et prévisible. Sur mobile, la recréation instantanée de l’interface avec conservation des règles drop est indispensable.

OpenVPN : blocage hors tunnel et routes

OpenVPN est un vétéran. Sous Windows, le paramètre block-outside-dns corrige la faille DNS, client-config-dir et route-pre-down script facilitent la gestion des routes. Linux privilégie nftables : blocage total sauf sur tun0. macOS combine PF et lancement via launchd avec gestion atomique des règles. Lors d’un reconnect actif, OpenVPN doit bloquer tout trafic avant la levée de l’interface TUN : les clients avancés appliquent « abort total » puis montent le tunnel, enfin ouvrent le trafic via interface.

IKEv2/IPsec : piles système et sélecteurs

IKEv2 sur Windows et macOS repose sur la pile IPsec système. Le kill switch s’appuie souvent sur la couche OS : restriction des sorties via l’adaptateur virtuel, blocage 0.0.0.0/0 vers l’extérieur, routes explicitement définies pour les exceptions (split-tunnel). En policy no-split, tout passe par tunnel, les autres interfaces sont totalement bloquées. Sur Linux, strongSwan lie les politiques xfrm à nftables et policy routing, consommant tout trafic non-matché.

Clients hybrides 2026 : eBPF, NE et WFP

La tendance 2026 : moins de bidouille, plus d’intégration. Linux utilise eBPF pour filtrer au niveau cgroup, macOS repose sur Network Extension avec config PF soignée et suivi des événements, Windows mise sur WFP sans astuces maison. La télémétrie détecte l’état du tunnel : en cas de fluctuations, le client n’enchaîne pas les changements de route à la milliseconde mais utilise délais et transactions pour éviter toute fenêtre de fuite.

Configuration pas à pas : Windows, Linux, macOS

Windows 11 : firewall et routage

Plan de base : on active d’abord un blocage global des sorties, puis on ajoute les exceptions pour l’interface VPN. En PowerShell, cela donne : création d’une règle blocage globale sur tous les profils ; ajout d’une règle autorisant InterfaceAlias VPN (ex. « WireGuard Tunnel » ou « Ethernet 5 » selon pilote) ; réglage prioritaire des interfaces — Set-NetIPInterface avec AutomaticMetric Désactivé et InterfaceMetric VPN plus basse. Résultat : même en cas de chute, le trafic ne sort pas grâce au bloc global. Un détail utile : une règle spécifique pour le loopback, sinon certaines applis râlent.

Linux (nftables + policy routing)

Processus : on crée une table inet vpn avec chaîne output en politique drop. On autorise oifname « wg0 » ou « tun0 », connexions établies, localhost. On marque le trafic via fwmark (par ex. 0x1), ajoute ip rule lookup 100 pour fwmark 0x1, puis dans table 100, route par défaut vers VPN. La table principale ne doit pas avoir de route par défaut ou pointer vers blackhole. Optionnel : cgroup-bpf pour listes blanches de services d’administration. Testez avec ping, curl bindé à l’interface et le trafic système (NTP, sync horaire), tout doit passer par tunnel.

macOS (PF + NE)

Procédure : démarrez le client VPN Network Extension, identifiez l’interface utunX. Dans /etc/pf.conf, créez l’anchor « vpn-killswitch », activez block drop par défaut, skip sur lo0. Dans l’anchor, autorisez uniquement le trafic sur utunX. Activez pfctl en rechargeant l’anchor. Configurez DNS scoped pour éviter toute sortie hors VPN. Après sommeil, traquez et mettez à jour utunX dans les règles si besoin. Cette méthode évite toute fuite, même sur changements brusques de Wi-Fi.

Gestion des applications et exceptions

Parfois, des exceptions sont nécessaires : mises à jour OS, agents corporate, VoIP hors VPN. Faites-les en toute conscience. Sur Linux, isolez une cgroup avec politique dédiée. Sur Windows, utilisez WFP callout ou règles par AppPath et services. Sur macOS, optez pour NEFilterDataProvider avec règles apps. Conservez un journal complet : qui a accédé au réseau et pourquoi. Le kill switch reste strict par défaut, les exceptions ciblées et contrôlées.

Vérifications et tests : s’assurer que le kill switch fonctionne vraiment

Tests rapides d’IP et DNS

1) Coupez le VPN : y a-t-il un accès internet ? Ça doit être non. 2) Activez VPN et ouvrez une page d’identification IP : l’adresse doit être celle du fournisseur VPN. 3) Forcez la coupure du tunnel : stop service, baisser interface. L’internet doit disparaître. 4) Testez DNS : lancez des résolutions et vérifiez qu’elles passent par l’interface VPN. Si le réseau revient lors de la chute, le barrage laisse passer quelque part.

Inspecter routes et interfaces

Windows : route print, Get-NetRoute, Get-NetIPInterface pour voir métriques, routes par défaut, NextHop VPN. Linux : ip route, ip rule, ip -4 -6 route show table 100 pour la politique. macOS : netstat -rn, scutil --dns pour vérifier routes par défaut et scopes DNS. Baissez le tunnel et vérifiez : la route par défaut a-t-elle disparu ? A-t-il surgi une route extérieure non bloquée ? Si oui, corrigez la politique.

Sniffer minimaliste

Linux : tcpdump -i any not host adresse_VPN — aucun paquet sortant ne doit être visible. Windows : outil intégré pktmon ou Wireshark avec filtre not ip.addr==VPN_IP et not interface==VPN. macOS : tcpdump -i en0 ou en1 — silence complet lors de la chute du tunnel. Le sniffer est le test sans faille : s’il y a des paquets, il y a une fuite.

Test de courses et veille-réveil

Scénario complexe et révélateur : téléchargements en cours, appel vidéo, dix onglets ouverts, passage en veille puis réveil, changement de Wi-Fi vers point d’accès mobile, portable rapide en dock. Un vrai kill switch tiendra : aucun paquet ne filera hors tunnel. Si vos logs montrent de brèves sorties, renforcez les règles noyau, réduisez les fenêtres entre levée et application des règles pendant le reconnect.

Erreurs courantes et cas réels

Double route par défaut et métriques

Erreur classique : sous Windows, la métrique pour l’interface physique est plus basse que celle du VPN. Après mise à jour pilote, les métriques ont été « optimisées automatiquement » et du trafic est passé hors tunnel. Solution : fixez les métriques à la main et surveillez les règles firewall qui référencent explicitement l’InterfaceAlias VPN.

Fuites DNS via DoH

Le navigateur utilise DoH via sa liste propre de résolveurs. Bloquer le port 53/udp, c’est bien, mais le navigateur continue d’envoyer DoH sur le port 443 hors tunnel. La solution : forcer l’app à utiliser le résolveur système via politique et autoriser le DoH uniquement si l'interface est VPN. Sous Linux, nftables sets pour IP des fournisseurs DoH accessibles via tunnel et blocage global des autres.

Split-tunnel et facteur humain

Les politiques d’entreprise laissent parfois passer du trafic direct. C’est un grand risque : une seule mauvaise exception peut ruiner la confidentialité. L’approche : un split minimaliste, audit rigoureux. Les listes blanches de domaines sont mieux résolues par VPN puis libérées en IP seulement si indispensable.

Réseaux mobiles et NAT64

En LTE/5G, NAT64 et mécanismes transitoires peuvent laisser passer du trafic IPv6 hors contrôle si vous filtrez seulement IPv4. Assurez-vous que le kill switch couvre IPv4 et IPv6. Dans AllowedIPs, mettez 0.0.0.0/0 et ::/0. En nftables, privilégiez les tables inet pour gérer les deux piles simultanément.

Techniques avancées et tendances 2026

eBPF sur Linux : filtrage au niveau processus

Avec eBPF, on délaisse les blocages globaux lourds pour des politiques intelligentes. cgroup-bpf permet de dire : tous les processus sont bloqués hors wg0, sauf le service « mise à jour temps » autorisé dans un pool IP dédié. Ça atténue les soucis quand une politique stricte casse quelque chose. Et rend le kill switch plus souple sans perdre en sécurité.

Windows : WFP avec télémétrie d’état

Les clients modernes utilisent des callouts WFP qui ne se contentent pas de bloquer mais « comprennent » l’état du tunnel. Pas d’interface établie = blocage dur, tunnel prêt = passage via interface. Ça réduit les fenêtres où les règles sont appliquées tardivement alors que le trafic commute déjà. Plus un journal détaillé : quel process a tenté quoi, où, quel protocole — indispensable pour enquêtes.

macOS : NE + PF avec mises à jour atomiques

En 2026, beaucoup de clients basculent vers des mises à jour atomiques des anchors PF : nouveau config généré, chargé dans un nouvel anchor, échange propre. Plus de ruptures, plus de conflits. Ajoutez les capacités NE de détection d’état réseau : changement Wi-Fi — le client met à jour instantanément interface et scopes DNS.

Protection contre les canaux « cachés »

Certaines applis exploitent QUIC, uTP, proxy intégrés pour « optimiser » le réseau. Le kill switch doit les considérer comme des contournements possibles. Solution : bloquer les sorties sur toutes interfaces sauf VPN, non selon ports, mais selon état socket ; autorisation uniquement si interface ou marquage concorde. Le masquage par port ne contournant plus la politique.

Checklist de déploiement : étapes à ne pas sauter

Conception de la politique

Définissez : tunnel total ou partiel. Liste d’exceptions inévitables. Exigences DNS (DoH, DoT). OS supportés et versions (Windows 11 24H2+, noyau Linux 6.x, macOS 14+). Scénarios de veille, roaming Wi-Fi/Ethernet, réseaux mobiles.

Implémentation technique

Windows : règles AdvFirewall + WFP ; Linux : nftables + policy routing +, si besoin, eBPF ; macOS : NE + anchors PF. Obligations : bloc total sauf oif VPN ; interdiction DNS hors VPN ; route par défaut via tunnel ; trou noir en cas de chute.

Tests et surveillance

Sniffer, tests de charge reconnect, journalisation des processus, vérification IPv6, tests DoH, applications « compliquées » (lanceurs jeux, torrents, agents d’entreprise). Surveiller alertes sur route hors VPN, alertes chute interface, télémétrie tentatives contournement.

Exploitation et retour arrière

Préparez « clé de secours » : comment désactiver le kill switch si le client VPN plante et que internet est impératif. Sous Windows, script de suppression règles à l’avance ; Linux, fichier nft flush ruleset + backup config ; macOS, pfctl -d avec prudence et rollback profil NE. N’opérez cela qu’en mode offline ou accordé, pour ne pas briser la sécurité.

Commandes pratiques et exemples : aide-mémoire compact

Windows PowerShell

Ajouter un blocage complet sortie : New-NetFirewallRule -DisplayName "Block All Outbound" -Direction Outbound -Action Block -Profile Any. Autoriser interface VPN : New-NetFirewallRule -DisplayName "Allow VPN Outbound" -Direction Outbound -Action Allow -InterfaceAlias "Nom_Interface_VPN" -Profile Any. Fixer métriques : Set-NetIPInterface -InterfaceAlias "Nom_Interface_VPN" -AutomaticMetric Disabled -InterfaceMetric 5 ; physiques à 50+.

Linux nftables

Créer table et politique : add table inet vpn ; add chain inet vpn output { type filter hook output priority 0; policy drop; }; add rule inet vpn output oifname "wg0" accept ; add rule inet vpn output meta oifname "lo" accept ; add rule inet vpn output ct state established,related accept. Policy routing : ip rule add fwmark 0x1 table 100 ; ip route add default dev wg0 table 100. Table principale : sans défaut ou blackhole default dev lo.

macOS PF

Dans pf.conf : set block-policy drop ; set skip on lo0 ; anchor "vpn-killswitch" ; dans l’anchor : block out on ! utunX from any to any ; pass out on utunX from any to any keep state ; block out proto { udp, tcp } to port 53 on ! utunX. Activer : pfctl -f /etc/pf.conf ; pfctl -E. Mettre à jour utunX lors du reconnect client.

Diagnostic DNS

Windows : Resolve-DnsName avec trace ; vérifiez que serveurs dans Get-DnsClientServerAddress appartiennent au VPN. Linux : resolvectl dns et resolvectl status ; vérifiez interface tun/wg. macOS : scutil --dns — vérifiez résolveurs scoped ; services système pointent vers utun.

Pourquoi le kill switch ne s’active parfois « soudainement » pas, et comment corriger

Courses lors du reconnect

Si le client retire les règles avant que le tunnel soit prêt, une fenêtre de quelques millisecondes à secondes apparaît. Solution : transactions atomiques. D’abord maintien du bloc global, mise en place du tunnel, puis ouverture des règles interface. C’est la seule manière fiable.

Services OS à statut spécial

Antivirus, agents d’entreprise, mises à jour système peuvent avoir des privilèges pour contourner les règles classiques. Il faut les attraper au niveau noyau : callout WFP Windows, cgroup-bpf Linux, NEFilterDataProvider macOS. Sinon, un service « magique » ouvre une brèche.

Discordance IPv6

Filtrer seulement IPv4, c’est à moitié fait. En 2026, IPv6 est partout. Vérifiez systématiquement ::/0, RA, SLAAC, et bloquez sorties sur interface physique pour les deux familles. Les tables inet sous nftables vous aident ; PF et WFP aussi.

Navigateurs et piles réseau propres

Certains navigateurs utilisent leur propre pile DNS, QUIC, proxies. Désactivez « DNS-over-HTTPS toujours » si votre scénario ne gère pas ce tunnel. Sinon, le DoH peut s’échapper. L’idéal : DoH vers votre résolveur dans VPN et bloc strict du reste.

En résumé : comment savoir si votre kill switch est « correct »

Signes d’une implémentation mature

Pas d’internet hors VPN lors de la chute. Route par défaut pointant vers tunnel. DNS uniquement via VPN. IPv6 pris en compte. Exceptions rares, ciblées et enregistrées. Validation sniffing réussie. Sommeil, roaming, reconnect sans fuite.

Ce que ça vous apporte

Tranquillité d’esprit. Vraiment. Savoir que même si l’interface bouge, pas un octet ne sort. Vous pouvez bosser, regarder des vidéos, synchroniser vos archives, sans craindre la « seconde fatale ». Le kill switch est un vrai garant fiable.

Action à prendre

Vérifiez votre config dès aujourd’hui. Corrigez les doubles routes par défaut. Durcissez les règles. Fermez le DNS. Et avec l’analyse des logs, assurez-vous que quand le VPN se tait, le trafic aussi. Tout le reste n’est que détail.

FAQ : questions fréquentes sur le kill switch VPN

Peut-on faire un kill switch sans droits administrateur ?

Fiable, non. Il faut des droits pour modifier routes et firewall. Sinon, c’est joué à la légère, pas une vraie protection.

Quelle différence entre un kill switch et simplement « bloquer Internet quand le tunnel casse » dans le client ?

Un kill switch sérieux est en noyau et firewall. Un simple blocage appli se déclenche trop tard et perd les courses. Il faut WFP, nftables, PF.

Si j’ai un split-tunnel, le kill switch perd-il son sens ?

Non. Il bloque toujours le trafic non autorisé. Mais les risques montent : le split complique et demande un paramétrage précis.

Faut-il bloquer IPv6 si l’opérateur ne le fournit pas ?

Oui. Les applis peuvent créer des sessions IPv6 locales via des réseaux voisins. Bloquez sur les deux piles.

Comment vérifier que DoH ne fuit pas hors VPN ?

Sniffer sur l’interface physique et politiques firewall : autoriser DoH uniquement via interface VPN, bloquer le reste.

WireGuard lui-même assure-t-il un kill switch ?

Presque. Si AllowedIPs = 0.0.0.0/0, ::/0 et routes bien configurées. Mais sans firewall, des fenêtres de fuite au reconnect restent possibles. Les règles drop hors wg sont indispensables.

Pourquoi ai-je toujours accès au réseau local quand le VPN tombe ?

Les règles sont configurées ainsi. Autoriser link-local et LAN est parfois nécessaire. Pour plus de rigueur, bloquez-les aussi, mais soyez prêt à perdre imprimantes et partages.