Un kill switch bloque-t-il le trafic avant le démarrage de l'application VPN ?

Un kill switch peut couvrir ou non la fenêtre qui précède le démarrage de son application, et la différence est décidée par la politique du système d'exploitation plutôt que par la page marketing du client. Une case de lancement automatique prouve que quelque chose est programmé pour démarrer. Elle ne prouve pas que des règles de blocage existent au moment où le réseau monte. Ce sont deux événements, et un seul d'entre eux protège le trafic.

Déroulez la liste de contrôle dans l'ordre, car chaque étape resserre ce que vous testez réellement.

D'où vient réellement le blocage

Il existe deux familles d'implémentation. Soit la plateforme installe le blocage, parce qu'elle connaît le tunnel avant qu'aucune application ne s'exécute, soit le client installe lui-même le blocage après son démarrage. La première peut exister avant l'ouverture de session. La seconde ne peut pas exister avant son processus, aussi tôt ce processus soit-il planifié. Identifiez la famille sur laquelle vous comptez avant de tester quoi que ce soit.

Sur Android, le VPN toujours actif combiné au réglage qui bloque les connexions sans VPN relève de la politique de la plateforme, configurée dans les paramètres du système et pas seulement dans le client. Sur les appareils gérés, elle peut être réglée pour vous. Un client qui se contente de démarrer au boot n'est pas le même mécanisme.

Séparez la fenêtre du service

Une fenêtre fermée ne prouve pas que l'application de la règle s'est arrêtée, et une fenêtre ouverte ne prouve pas qu'un tunnel est prêt. Beaucoup de clients séparent l'interface, le démon et l'application de la zone de notification. La zone de notification est ce que vous voyez ; le démon est ce qui détient les règles.

Testez le composant, pas l'icône.

Testez l'intervalle de démarrage en sécurité

L'intervalle à tester commence au redémarrage ou à l'ouverture de session et se termine lorsque le tunnel s'authentifie. Les applications en arrière-plan se connectent pendant cette période, et les vérifications de mise à jour sont les coupables habituels. Utilisez une activité inoffensive et la procédure documentée du fournisseur plutôt que de bloquer votre propre accès. Répétez ensuite après une reconnexion normale, car le chemin de reconnexion et le chemin de démarrage à froid exécutent un code différent.

Un test effectué après que le tunnel est déjà monté ne prouve rien sur le démarrage.

Lisez le comportement au redémarrage si la persistance est l'exigence. Un réglage peut survivre dans la configuration alors que son application commence plus tard, et les deux faits comptent : la politique enregistrée et le moment où elle devient active.

Lisez la politique plateforme par plateforme

Android expose le mode toujours actif et le blocage comme des commutateurs distincts, et les deux doivent être activés pour la protection avant démarrage. Windows dispose d'un concept de tunnel d'appareil toujours actif configuré par stratégie, qui n'est pas la même chose qu'un client en mode utilisateur démarrant tôt. OpenVPN Connect documente son propre comportement de kill switch par plateforme, et c'est la portée documentée que vous testez. Ne transportez pas un nom de réglage d'un système à l'autre en supposant que la sémantique a voyagé avec lui.

Un profil exigeant un mot de passe interactif a des dépendances de démarrage différentes de celles d'un tunnel machine.

Ce qu'il faut consigner

Notez quel mécanisme est en vigueur, à quel stade il devient actif et quel trafic a été tenté avant ce stade. Consignez la version de la plateforme, car ce comportement change entre les versions et entre les configurations gérées et personnelles. Précisez si le client ou le système possède la politique, puisque cela décide qui peut corriger une lacune. Puis retestez après toute mise à jour du client ou du système d'exploitation.

Si la lacune compte, la correction durable est la politique de la plateforme, pas un délai de démarrage plus court.

C'est la réponse à la question initiale, formulée comme une condition : un kill switch protège le trafic avant le démarrage de l'application seulement lorsque le blocage est installé par quelque chose qui existe avant l'application.