Fichier hosts contre filtre du routeur : bloquer un site via un VPN

Une entrée dans le fichier hosts et un filtre du routeur bloquent le même site pour des raisons totalement différentes, c'est pourquoi l'un continue de fonctionner sous un VPN et l'autre s'arrête sans bruit. Le fichier hosts répond à un nom avant qu'aucun paquet ne quitte la machine. Le filtre du routeur inspecte le trafic qui le traverse. Placez un tunnel entre ces deux points et le second perd sa vue, tandis que le premier ne remarque rien.

L'endroit où le nom est résolu décide de tout

Chaque blocage commence par une question : qui transforme le nom en adresse ? Sur un poste de travail ordinaire, la réponse vient du résolveur système, qui suit son ordre configuré et lit habituellement le fichier hosts avant d'interroger le DNS. Sur un réseau filtré, la réponse peut venir du routeur, qui ne voit la requête que si le client l'envoie à travers lui sans protection. Changez le chemin et vous changez qui a le droit de répondre.

Un VPN fait ici deux choses à la fois : il déplace la route par défaut et il peut imposer son propre serveur DNS. L'un ou l'autre de ces changements suffit à éloigner la résolution de noms de l'appareil qui appliquait le blocage.

C'est le mécanisme derrière la plainte bien connue selon laquelle le filtre fonctionne jusqu'à ce que le VPN se connecte.

Une entrée hosts répond avant que le tunnel existe

Une ligne comme 127.0.0.1 www.example.com est lue par le résolveur local, donc la réponse est produite sur la machine sans réseau. Connectez un tunnel, changez le serveur DNS, changez de réseau : l'entrée renvoie toujours loopback. C'est pourquoi un blocage par hosts est le seul des deux qui ne dépend pas de l'endroit où le VPN se termine.

Ses angles morts sont tout aussi locaux. Une application qui embarque son propre résolveur, parle DNS over HTTPS ou se connecte à une adresse littérale ne demande jamais au système, donc l'entrée n'est pas consultée. Une adresse mise en cache dans un processus en cours a le même effet jusqu'à ce que ce processus redémarre.

Confirmez la réponse avec getent ahosts sous Linux ou Resolve-DnsName sous Windows plutôt qu'en faisant confiance à un onglet de navigateur.

Un filtre du routeur ne voit que ce qui le traverse

Un filtre de contenu ou d'URL sur un routeur domestique met en correspondance les noms et les requêtes qui le traversent sous une forme lisible. Quand le client construit un tunnel chiffré vers un serveur ailleurs, le routeur ne voit qu'un seul flux vers ce serveur et rien à l'intérieur. Le filtre n'a aucun nom à mettre en correspondance, il laisse donc passer le trafic, et cela ressemble à un échec du filtre, pas à un contournement.

La topologie qui fonctionne est l'autre : le routeur tient lui-même le tunnel, déchiffre au point de sortie et y applique le filtre. Dans cette conception, le filtre se trouve là où apparaît le texte en clair.

Si le tunnel se termine sur l'ordinateur portable, le routeur est par définition en dehors du chemin protégé, quelle que soit la façon dont la règle est écrite.

Quatre points d'application et ce que chacun rate

Quatre endroits peuvent appliquer un blocage, et chacun échoue différemment. Lisez la liste comme une carte de couverture, pas comme un classement.

• Fichier hosts ou résolveur local : fonctionne hors ligne et sous n'importe quel tunnel, mais est contourné par un résolveur intégré ou une adresse codée en dur.
• Filtrage DNS au niveau de la passerelle VPN : couvre les clients qui utilisent le résolveur imposé et manque les clients qui contournent le DNS.
• Règles de sortie de la passerelle par adresse ou par SNI : indépendantes du DNS du client, mais aveugles aux noms qu'elles ne peuvent pas lire et aux adresses qu'elles n'ont pas apprises.
• Politique gérée de navigateur ou d'appareil : forte sur le matériel géré, absente sur les appareils personnels.

Aucune de ces mesures n'est une frontière de sécurité face à un utilisateur déterminé sur un appareil non géré. Ce sont des contrôles de politique, et une description honnête dit quel trafic chacune couvre réellement.

Choisissez la couche qui correspond à l'intention : le confort domestique appartient à l'appareil, et une règle d'organisation appartient à la passerelle.

Testez les deux états avant de déclarer que c'est terminé

Exécutez les trois mêmes commandes avec le VPN connecté et déconnecté : getent ahosts pour voir la réponse du résolveur, nslookup pour voir ce que la requête renvoie, et curl -I vers le site pour voir si une connexion aboutit encore. Si la première renvoie loopback alors que la troisième se connecte à l'adresse réelle, quelque chose a contourné le résolveur et l'entrée hosts n'est pas le contrôle que vous croyez.

Sur le routeur, lisez les compteurs du filtre avant et après une requête. Un compteur qui ne bouge jamais signifie que le trafic n'a jamais atteint le filtre, et c'est une réponse de routage, pas une réponse de règle.

Notez le résultat avec la topologie, car le prochain changement de VPN déplacera encore le chemin.