VPN always-on ou kill switch : lequel avez-vous vraiment activé ?

Always-on et kill switch sont à deux lignes sur le même écran de réglages, d’où on les lit comme deux noms d’une même fonction. Ce n’est pas le cas. Always-on est une politique de reconnexion : ouvrir le tunnel au démarrage, le rétablir après un plantage ou un changement de réseau, et réessayer tant que cela échoue. Un kill switch est une politique de trafic : il nomme les paquets qui peuvent encore quitter la machine quand le tunnel est coupé. On peut activer le premier sans le second, et sur la plupart des plateformes le résultat d’origine laisse encore sortir du trafic pendant la coupure.

Vérification 1 : le blocage est-il un interrupteur à part ?

Sur Android 10 et versions ultérieures, un profil VPN enregistré ouvre derrière l’icône d’engrenage deux interrupteurs indépendants : VPN always-on et Bloquer les connexions sans VPN. Seul le second est le kill switch. Avec always-on seul, le tunnel revient après une coupure, mais toute application au milieu d’une requête atteint le réseau en Wi-Fi ou en données mobiles avant cela.

Les appareils gérés gardent la même séparation dans l’API de stratégie. setAlwaysOnVpnPackage() prend le nom du paquet et un indicateur lockdownEnabled ; un administrateur qui définit le paquet et laisse l’indicateur à faux a bâti un tunnel persistant, pas un appareil fermé. La formulation de la console rend rarement cette différence visible.

Lisez l’état depuis l’appareil et non depuis la console : adb shell settings get global always_on_vpn_app et adb shell settings get global always_on_vpn_lockdown. Si la première renvoie null, aucun paquet n’est imposé au niveau de la plateforme ; si la seconde renvoie 0, la plateforme ne bloque rien. Le guide VPN Android décrit ces éléments comme des capacités distinctes et non comme un mode unique.

Vérification 2 : quelle couche possède le blocage ?

Les étiquettes vivent dans le client et les blocages généralement dans le pare-feu, d’où le même mot signifie autre chose sur chaque plateforme. Les lignes ci-dessous méritent confirmation avant d’en croire une seule.

Windows est l’exemple le plus clair d’une étiquette qui ne bloque pas. Always On y décrit la persistance du tunnel : un tunnel d’appareil pour l’authentification de la machine, un tunnel utilisateur pour le compte connecté, configurés par XML de profil ou Add-VpnConnection. Rien dans ce profil n’arrête un paquet sortant quand le tunnel manque, et le filtrage sortant n’est pas actif par défaut : un portable en Wi-Fi continue donc de fonctionner alors que le VPN est coupé.

WireGuard se divise pareillement, mais par client. WireGuard pour Windows porte une option par tunnel, Bloquer le trafic hors tunnel, qui installe des règles de filtre ; les outils Linux n’ont pas d’équivalent. wg-quick ajoute une route pour chaque entrée AllowedIPs plus une règle fwmark, et wg-quick down retire les deux, si bien que la route physique par défaut reprend sans paquet perdu entre-temps.

Sur les plateformes Apple, always-on arrive comme fonction de profil de gestion pour les appareils supervisés et s’exprime en règles à la demande, non en case à cocher. La question à trancher depuis la charge est celle-ci : un tunnel en échec refuse-t-il le trafic ou demande-t-il seulement une autre connexion ? Le titre du menu ne vous le dira pas.

Vérification 3 : mesurez la coupure, pas l’icône

Quatre transitions comptent, et elles échouent différemment : le démarrage avant toute connexion, la veille et la reprise, un passage du Wi-Fi aux données mobiles, et un plantage du client qui laisse l’interface du tunnel à moitié configurée. Une reconnexion propre sur l’une d’elles ne prouve rien pour les trois autres.

Le test le moins coûteux arrête le tunnel exprès, puis tente de sortir. Tunnel coupé, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com renvoyant 200 signifie que la politique est fail-open ; un délai dépassé ou une connexion refusée signifie que quelque chose bloque encore. ip route get 1.1.1.1 nomme l’interface qui porterait le paquet, ce qui en dit souvent plus que l’icône de la barre, et systemctl status wg-quick@wg0 montre si l’interface a été retirée proprement.

Lancez la même sonde dans une seconde fenêtre pendant que le réseau change, pas seulement après. L’intervalle entre la coupure et la nouvelle tentative est la partie qui compte, et une résolution de nom est le moyen le plus rapide de remarquer un trafic évadé : si le résolveur local répond alors que le tunnel est coupé, le blocage n’est pas complet.

Vérification 4 : décidez des exceptions avant de verrouiller

Deux exceptions sont structurelles. Le client doit joindre le serveur VPN lui-même : un jeu de règles qui abandonne tout empêche donc aussi la reconnexion qui rétablirait la protection. Un portail captif n’est pas joignable non plus par un tunnel qui n’est pas monté : un appareil verrouillé sur le Wi-Fi d’un hôtel a besoin d’un moyen documenté d’ouvrir le portail, pas improvisé.

Une forme minimale, point de sortie autorisé et tout le reste abandonné :

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Traitez cette ligne de point de sortie comme une variable, non comme une constante. Les fournisseurs changent d’adresses, et une exception périmée est la raison habituelle pour laquelle un kill switch qui marchait devient un appareil incapable de se reconnecter. Les imprimantes locales, les partages NAS et les services de développement appartiennent à la même liste écrite, sinon ils se découvrent un ticket de support à la fois.

Vérification 5 : consignez ce que vous avez réellement prouvé

Tenez un tableau à quatre colonnes et remplissez-le en testant : état, comportement attendu, comportement observé, preuve. Les lignes sont les transitions de la vérification 3 plus un échec délibéré. Une ligne que vous ne pouvez pas remplir avec une sortie de commande est une ligne que vous n’avez pas testée, et un appareil qui passe la ligne de reconnexion en échouant celle du démarrage est assez courant pour valoir les dix minutes supplémentaires.

Avant de déclarer terminé :

• Confirmez que le réglage de blocage est distinct de celui de reconnexion, et lisez sa valeur sur l’appareil.
• Sachez quelle couche applique le blocage - option du client, stratégie de l’appareil ou pare-feu - et où elle se configure.
• Gardez une commande de test qui prouve le blocage, et exécutez-la pendant une transition plutôt qu’après.
• Écrivez la liste des exceptions, point de sortie compris, et notez qui la met à jour.
• Sur du matériel géré, laissez la stratégie imposée tranquille ; retirer le blocage change l’exigence au lieu de réparer le tunnel.