Inclusion seule ou exclusion seule : quel choix par défaut ?
Choisissez la valeur par défaut avant de construire la liste : ne tunneliser que ce que vous nommez, ou tout tunneliser et retrancher des exceptions. Testez ensuite l'application que personne n'avait inscrite.
Ouvrez la section de routage de votre client VPN et vous voyez deux contrôles de forme différente qui portent souvent la même étiquette. L'un vous demande de lister les destinations qui appartiennent au tunnel, et tout le reste continue d'utiliser le réseau local. L'autre suppose que tout est tunnelisé et demande ce qu'il faut retrancher. Les deux donnent un tunnel fonctionnel au premier test, et les deux s'entretiennent en ajoutant des lignes à une liste, ce qui explique pourquoi la différence reste invisible jusqu'à ce que quelqu'un installe quelque chose de nouveau.
Le choix est une valeur par défaut, pas une fonctionnalité. Tranchez-le avant que la liste ne compte vingt entrées.
Lire la valeur par défaut sur le client, pas dans la brochure
WireGuard rend la décision inhabituellement visible, parce que AllowedIPs est une liste d'inclusion et rien d'autre. Un pair avec 0.0.0.0/0, ::/0 tunnelise tout ; un pair avec 10.20.0.0/16 ne tunnelise que cela. Il n'existe pas de syntaxe d'exclusion, donc pour laisser un sous-réseau de côté, il faut soit énumérer tous les autres préfixes, soit ajouter du routage de politique en dehors de l'interface.
OpenVPN parvient au même endroit par l'autre bout, avec redirect-gateway def1 qui installe un tunnel complet et des directives route explicites qui ajoutent ou écrasent des préfixes précis. Les clients commerciaux cachent généralement les deux derrière une case à cocher et un tableau de destinations, alors lisez bien lequel des deux le tableau modifie réellement avant de faire confiance à l'étiquette.
La question n'est pas le nom de la case à cocher. La question est ce qui arrive à un paquet dont la destination ne figure dans aucune des deux listes. Répondez par écrit, et le reste de la configuration en découle. Si vous sautez la question, la première panne inexpliquée sera tranchée par celui qui ce jour-là se trouve le plus près du client.
Suivre une application que personne n'a inscrite
Dans une conception en inclusion seule, cette application passe en direct, sur le réseau local, avec le DNS local. Dans une conception en exclusion seule, elle passe par le tunnel, selon ce que le serveur autorise, et c'est souvent la différence entre un nouvel outil SaaS qui fonctionne dès le premier jour et un ticket affirmant que le VPN l'a cassé.
Aucune des deux valeurs n'est plus sûre en soi. L'inclusion restreint ce que le tunnel transporte et fait du réseau local le chemin de moindre résistance ; l'exclusion prend le tunnel comme chemin normal et traite les exceptions comme des exceptions, ce qui est plus proche de ce que la plupart des politiques d'entreprise veulent réellement dire.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
Repérer le type d'objet que la plateforme liste
Le VpnService.Builder d'Android expose une liste d'applications autorisées et une liste d'applications interdites comme deux modèles distincts, et les règles par application choisissent par paquet plutôt que par destination. Un navigateur placé dans une telle liste transporte chaque destination qu'il ouvre, ce qui est une granularité différente d'une table de routage et ne peut pas réparer un seul site cassé à l'intérieur d'une application qui fonctionne.
Les clients de bureau mélangent généralement les deux types dans une même interface, alors vérifiez si la ligne que vous ajoutez est un paquet, un nom d'hôte ou un préfixe. Ils échouent de manières différentes et se règlent à des endroits différents. Une ligne de nom d'hôte devient généralement une route plus un nom, tandis qu'une ligne de paquet devient une décision de politique dans le client. Notez laquelle des deux vous avez ajoutée, car la personne qui déboguer plus tard supposera l'autre.
Tester l'état d'échec, pas seulement le chemin heureux
Une application exclue du tunnel n'obtient pas automatiquement un accès direct propre. Si le client applique en plus une règle de blocage sans VPN, le trafic exclu peut être purement abandonné, ce qui ressemble à une application cassée plutôt qu'à une décision de routage. Testez ce cas volontairement au lieu de le découvrir dans un rapport d'utilisateur.
Vérifiez ensuite le DNS et IPv6 comme deux points séparés. Un tunnel qui ne transporte que de l'IPv4 laisse à une application capable de v6 un chemin pour le contourner, et le DNS scindé décide si les noms internes se résolvent pour un trafic qui n'est pas tunnelisé du tout. Lancez une application listée, une application non listée, une résolution de nom et une reconnexion, et conservez les résultats avec la configuration.
Écrire la valeur par défaut là où la personne suivante la trouvera
Consignez la valeur retenue, les exceptions et leur responsable au même endroit que le profil du client, car le prochain administrateur ajoutera une entrée sans lire ce raisonnement. Notez la date et la raison de chaque exception, afin qu'une exception devenue obsolète pour un site depuis réparé puisse être retirée en confiance. Une liste sans raisons grossit indéfiniment.
Quand quelqu'un signale une seule destination cassée, modifiez l'exception et non la base. Inverser la valeur par défaut pour réparer un site déplace silencieusement chaque application non listée de l'autre côté du tunnel.