Interrupteur d'urgence VPN : quel trafic il bloque et quand

Deux fonctions portent le même nom et font un travail différent. La reconnexion automatique tente de rétablir le tunnel, et elle peut y parvenir en une seconde pendant que les requêtes échouent dans cet intervalle. L'interrupteur décide de ce qui arrive au trafic pendant cet intervalle. Lire un client comme si les deux n'étaient qu'un réglage, c'est ainsi que l'on finit par faire confiance à une icône plutôt qu'à une politique.

Bloquer et se reconnecter sont deux décisions distinctes

Un client ne bloque que lorsque la coupure est imprévue, puis se reconnecte et lève le blocage. Un autre maintient un blocage au niveau du système jusqu'à ce que quelqu'un modifie un réglage à la main, et un troisième considère une déconnexion volontaire comme une autorisation de rétablir l'accès ordinaire. Ce sont trois comportements différents, et la documentation de l'éditeur indique lequel votre version applique.

L'importation d'un profil ne tranche rien sur cette question. Le même profil de serveur se charge dans deux clients au comportement de blocage opposé, parce que le profil transporte des réglages et non une promesse. C'est aussi pourquoi une case à cocher sur ordinateur et un commutateur mobile aux libellés similaires peuvent appliquer des règles différentes. Lisez la description associée au contrôle de votre plateforme, puis testez ce qu'il fait.

Le même profil se comporte différemment dans deux clients

Les réglages de l'application OpenVPN Connect décrivent un mode tunnel qui retient le trafic ordinaire seulement tant que le client signale un état de pause ou de reconnexion, ce qui est plus étroit qu'une promesse générale sur chaque événement et sur chaque plateforme. Lisez les états énumérés plutôt que le nom du produit. Une description écrite pour une version de client ne se transpose pas au client d'un autre éditeur.

Android affiche le même mot pour deux contrôles, car le VPN toujours actif et le blocage des connexions sans VPN sont documentés séparément. Un client de bureau doté d'une case au nom similaire peut appliquer quelque chose de plus étroit ou de plus large que l'un ou l'autre. Considérez un libellé commun dans deux menus comme une coïncidence jusqu'à ce que les deux descriptions aient été lues. Les appareils gérés ajoutent une troisième couche, car un profil d'appareil peut imposer un réglage que l'utilisateur ne voit pas et ne peut pas annuler.

Des réglages de plateforme qui se ressemblent ne sont pas équivalents

Comparez le contrôle que vous voyez à la politique qui s'applique réellement. Sur un appareil géré, le commutateur visible peut être grisé, ou activé alors qu'un profil de niveau supérieur impose l'inverse. Demandez la politique effective plutôt que la politique locale, et obtenez la réponse par écrit.

Notez ce que chaque couche affirme avant de tester quoi que ce soit, car les deux sont souvent en désaccord et ce désaccord se perd facilement dès que les tests commencent. Un appareil qui bloque correctement pendant un test bloque peut-être pour une raison que personne n'a documentée.

Exécutez un événement à la fois et notez le code

Testez un événement par exécution, avec une requête inoffensive, et faites de chaque tentative une nouvelle requête plutôt qu'une page peut-être déjà en cache. Les commandes ci-dessous font tomber le tunnel, demandent une page et montrent si l'interface est revenue.

ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0

Le tableau associe chaque action à l'observation qui compte et à la preuve qu'il vaut la peine de conserver. Une requête qui échoue dans le délai indique que le blocage s'est activé ; une requête qui passe indique que le trafic a trouvé un autre chemin, qui peut être une route exclue plutôt qu'un blocage désactivé. Répétez l'ensemble après une mise à jour logicielle importante ou un changement de politique de routage, car l'un comme l'autre peut modifier la branche sans qu'aucun réglage visible ne bouge. À la fin, vous voulez un comportement de panne prévisible, pas une icône rassurante.

Exceptions, portails d'invités et ce qu'un blocage ne peut pas faire

L'accès au réseau local est l'exception courante, et elle change la portée de la promesse. Un client peut joindre une imprimante du même sous-réseau tout en bloquant le reste, ce qui est raisonnable à la maison et discutable sur un réseau d'invités. Décidez si cette exception est souhaitée avant qu'un incident ne la découvre pour vous.

Un blocage strict rend aussi la connexion au portail d'un réseau d'invités malaisée, car le portail est exactement le trafic direct que le blocage existe pour arrêter. Apprenez la manière prise en charge d'autoriser le réseau, puis rétablissez la politique délibérément au lieu de désactiver des contrôles jusqu'à ce qu'une page se charge. Gardez la réponse du résolveur et la table de routage dans la même note, comme ci-dessous. Ce qu'un interrupteur ne peut pas faire, c'est rendre le service anonyme, car bloquer le trafic hors du tunnel ne dit rien de ce qui se passe à l'intérieur.

resolvectl query example.com
ss -tunp | grep -v tun0