Wi-Fi public et VPN : ce que le tunnel ne couvre pas

Badge vert, portail satisfait, navigateur opérationnel : c'est toute l'histoire visible. Ce que le badge omet, c'est que la connexion chiffrée est portée par la liaison sans fil même dont elle est censée vous protéger. Cette liaison livre encore chaque paquet, voit encore l'adresse de destination et décide encore si quoi que ce soit arrive. Parcourir le côté ordinateur portable d'une connexion d'hôtel montre quelles parties le tunnel couvre et lesquelles il vous laisse.

La liaison d'accès transporte tout

Un tunnel IPsec ESP enveloppe un paquet interne protégé dans un en-tête externe que le réseau peut router, et RFC 4303 section 3.1.2 expose cette séparation. Le paquet interne est ce que le tunnel protège. L'en-tête externe est ce que le point d'accès lit pour le transmettre. D'autres conceptions encapsulent différemment, mais la question de planification est identique : quel chemin d'accès transporte cette connexion ?

Une panne de passerelle ou une liaison qui perd des paquets arrête la livraison sans révéler le contenu. Passer à un chiffrement plus fort n'y change rien, car la pièce manquante est le transport et non la cryptographie. Une livraison réussie prouve tout aussi peu dans l'autre sens, puisqu'un chemin qui fonctionne ne dit rien de l'état de l'une ou l'autre machine.

Votre ordinateur portable a encore ses propres portes

Rejoindre un segment non fiable change qui peut atteindre les ports sur lesquels votre machine écoute. Un service de partage de fichiers, un agent d'administration à distance ou un serveur de développement lié à toutes les interfaces est joignable par quiconque sur ce segment, sauf si quelque chose l'arrête. Le trafic qui n'entre jamais dans le tunnel n'est pas protégé par lui. Un écouteur qui répond avant que le tunnel soit monté est exposé exactement pendant cette fenêtre.

L'exigence est étroite et mérite d'être énoncée précisément : l'ordinateur portable doit atteindre le point de terminaison VPN, et les appareils sans rapport sur le point d'accès ne doivent pas atteindre les services locaux. Les règles de pare-feu de l'hôte expriment cette frontière, et les réglages de partage de la plateforme en expriment aussi une partie. Une imprimante ou une étape de portail est une exception circonscrite que vous ajoutez délibérément, et non la preuve que tout le point d'accès mérite la confiance d'un LAN de bureau.

Certaines organisations restreignent aussi l'accès local pendant qu'une connexion professionnelle est active, ce qui relève de la politique et non de l'ingénierie. Lisez cette politique avant de désactiver un pare-feu pour faire fonctionner un périphérique.

Vérifiez ce qui écoute réellement

Regardez les sockets plutôt que la page de réglages, car la page décrit l'intention et la table des sockets décrit la machine. Les deux listes ci-dessous séparent chaque socket en écoute de ceux qu'un voisin pourrait atteindre. Exécutez-les sur le segment non fiable avant de connecter le tunnel.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

La première commande affiche chaque socket, et la seconde filtre ceux liés au-delà de la boucle locale. Un service sur 0.0.0.0 ou :: est disponible sur toutes les interfaces, y compris la sans fil, tandis que le même service sur 127.0.0.1 n'est pas du tout joignable depuis le segment. La requête du résolveur confirme quel chemin prend le nom avant que le tunnel existe, et c'est là que les portails captifs interfèrent. Répétez la liste après la connexion, car certains clients montent des interfaces qui changent la réponse.

Un port qui n'apparaît que pendant que le tunnel est monté est moins exposé, même s'il vaut encore la peine de le connaître. Notez la différence plutôt que la liste absolue, car le delta est ce que le tunnel a ajouté.

N'acceptez pas une nouvelle identité en cours de session

Un changement de route inattendu, une reconnexion ou une redirection de portail n'est pas une autorisation d'accepter une autre identité de serveur. Si le client signale une incohérence de certificat ou de clé, traitez-la comme une constatation d'identité et non comme une connectivité à contourner. Installer un certificat racine inexpliqué pour faire fonctionner un portail transforme un problème de livraison en problème de confiance. Le problème de confiance survit ensuite au voyage qui l'a créé.

Utilisez le parcours navigateur propre au portail, puis reconnectez le tunnel et lisez le journal du client pour l'identité qu'il a vérifiée. Un échec d'identité signifie que le pair n'est pas celui que vous attendiez, tandis qu'un échec de livraison signifie que le pair n'a jamais répondu. Le premier est une raison de s'arrêter, et le second une raison d'essayer un autre chemin.

Décidez d'abord le comportement en cas de panne

Deux fonctions différentes sont confondues ici. La reconnexion tente de rétablir le service, tandis qu'une politique de blocage contrôle quel trafic est autorisé pendant que le tunnel est en panne. Ni l'une ni l'autre ne fournit une liaison sans fil fonctionnelle, et ni l'une ni l'autre ne prouve que le point de terminaison est propre. Choisissez explicitement : échec fermé pour les applications qui ne doivent jamais utiliser le chemin local, et autoriser la navigation ordinaire hors du tunnel si cela est acceptable.

Notez le choix, car la valeur par défaut de la plupart des clients n'est ni l'un ni l'autre, et elle varie selon la version. Prévoyez ensuite un chemin d'accès de secours si la disponibilité compte, comme un partage de connexion téléphonique avec son propre forfait de données. Un test d'acceptation acceptable comporte trois résultats distincts : le trafic prévu utilise le tunnel vérifié, les écouteurs locaux sans rapport sont inaccessibles, et une panne produit le comportement que vous avez choisi.