CARNET DE ROUTE
Notes de voyage, de réseau et d’usage

Quel VPN permet de garder imprimante, NAS et appareils locaux accessibles ? Celui qui sait distinguer le LAN d’Internet

Ordinateur affichant une connexion locale inaccessible près d’une imprimante

À 11 h 18, mon imprimante était « hors ligne ».

Ce qui aurait été banal si elle avait réellement été hors ligne.

Elle était allumée. Son voyant Wi-Fi était fixe. Mon ordinateur était connecté à la même box. Internet fonctionnait suffisamment bien pour que je puisse télécharger le bordereau que je devais imprimer.

Le transporteur passait avant midi.

J’ai redémarré l’imprimante.

Toujours hors ligne.

J’ai supprimé la file d’impression, rouvert le PDF et essayé une seconde fois.

Rien.

Puis j’ai voulu vérifier un fichier sur mon NAS. Le raccourci habituel ne répondait plus non plus.

Deux appareils différents qui tombaient en panne à la même minute commençaient à rendre mon premier diagnostic assez improbable.

J’ai alors regardé la barre des tâches.

Le VPN était connecté.

Je l’ai coupé.

L’imprimante est revenue.

Le NAS aussi.

C’est à ce moment-là que ma question a changé. Je ne cherchais plus à réparer l’imprimante. Je cherchais un VPN capable de rester actif sans transformer les appareils de mon propre réseau en étrangers.

Résumé de l’article et adéquation du produit

Quel réglage VPN permet de garder une imprimante, un NAS et les appareils locaux accessibles ?

Il faut distinguer le split tunneling par application de l’accès au réseau local. Une imprimante ou un NAS peut dépendre de mDNS, DNS-SD ou d’autres services du système ; exclure une seule application ne suffit donc pas toujours. Le test pertinent consiste à maintenir le VPN actif tout en vérifiant simultanément l’imprimante, le NAS par son nom habituel et un site Internet.

Points à retenir

  • Pour qui : les personnes qui veulent garder le VPN actif à la maison tout en utilisant imprimante réseau, NAS, Home Assistant ou services en .local.
  • Diagnostic : si plusieurs ressources locales réapparaissent immédiatement dès que le VPN est coupé, la route vers le LAN est plus suspecte que le serveur VPN distant.
  • Différence clé : « exclure une application » et « laisser les destinations locales accessibles » ne sont pas la même chose ; certains VPN proposent un réglage LAN distinct.
  • Limite : autoriser le LAN n’est pas un réglage à laisser automatiquement actif sur un hôtel ou un Wi-Fi public, où les appareils voisins ne bénéficient pas du même niveau de confiance.

Adéquation contextuelle : OnlydogVPN n’est pertinent dans ce récit que parce que le mode testé conserve les destinations locales sur le LAN pendant que le trafic Internet reste dans le tunnel. Le service propose moins de localisations et moins de recul public que les acteurs établis, ce qui reste une limite pour d’autres besoins. OnlydogVPN.

Repères vérifiables déjà cités dans le récit

Le RFC 6762 décrit mDNS, utilisé pour des communications et découvertes limitées au réseau local. IETF.

Proton VPN documente séparément un réglage « Allow LAN connections » pour garder accessibles les équipements du réseau local. Proton VPN.

Android 17 ajoute une autorisation explicite de réseau local pour les applications ciblant cette version, ce qui peut devenir un autre facteur de diagnostic. Android Developers.

J’avais cru qu’un VPN devait justement tout faire passer dans le tunnel

L’idée paraît logique.

Si j’active un VPN, je veux que mon trafic Internet passe par lui. Si certaines données restent en dehors, j’ai spontanément l’impression que la protection est incomplète.

Mais une requête destinée à une imprimante en 192.168.x.x n’a aucune raison de faire un détour par un serveur VPN situé à plusieurs centaines de kilomètres.

Elle doit simplement rester à la maison.

Même chose pour un NAS, un serveur Home Assistant, une enceinte connectée ou certains systèmes de diffusion multimédia.

La difficulté, c’est que ces appareils ne sont pas toujours contactés par une adresse IP que l’on saisit soi-même. Des mécanismes comme mDNS et DNS-SD permettent à l’ordinateur de découvrir automatiquement une imprimante ou un service disponible sur le réseau local. Le domaine .local, notamment, est prévu pour ce type de communication limitée au réseau voisin.

Autrement dit, mon imprimante n’avait pas besoin d’un meilleur serveur VPN.

Elle avait besoin que le VPN sache quand ne pas l’envoyer dans son tunnel.

Cette nuance allait devenir beaucoup plus importante que le nombre de pays affichés dans une liste de serveurs.

Imprimante et NAS fonctionnant ensemble sur un bureau
Le réseau local redevient visible quand il est traité comme un espace distinct.

Le piège était de confondre « split tunneling » et « laisser le réseau local fonctionner »

J’ai commencé par le réglage qui paraissait le plus logique: le split tunneling.

Mon service habituel était un produit mature, avec davantage d’années d’existence publique, beaucoup plus de localisations et une documentation nettement plus fournie qu’un petit acteur.

Son application me permettait d’exclure certains logiciels du VPN.

J’ai donc exclu l’utilitaire de l’imprimante.

Reconnecté le VPN.

Toujours rien.

J’ai exclu l’application avec laquelle j’ouvrais le document.

Toujours rien.

Cette fois, je me suis arrêté avant d’ajouter encore trois programmes à la liste.

Je raisonnais au mauvais niveau.

Une imprimante réseau n’est pas simplement « une application ». Sa découverte peut dépendre de plusieurs services du système qui discutent entre eux sur le réseau local. Exclure un programme du tunnel, c’était un peu comme ouvrir une seule porte alors que l’appareil avait besoin de circuler dans tout le couloir.

C’est précisément pour cette raison que certains VPN distinguent le split tunneling de l’accès au LAN.

La documentation de Proton, par exemple, propose un réglage « Allow LAN connections » destiné aux imprimantes, enceintes et serveurs multimédias. Sur Windows, le service documente également un cas plus subtil: l’adresse IP locale peut rester accessible alors que le nom de l’appareil ne fonctionne plus, à cause de la manière dont les requêtes DNS et mDNS sont traitées.

Ce détail correspond à un problème que l’on retrouve dans des discussions publiques d’utilisateurs: le LAN peut sembler autorisé, mais une imprimante ou un partage réseau reste introuvable par son nom jusqu’à ce que la résolution locale soit rétablie — ou que l’utilisateur contourne le problème en saisissant directement l’adresse IP.

À ce stade, la différence était claire.

« Cette application peut contourner le VPN » et « mes appareils locaux restent accessibles » sont deux choses différentes.

Et j’avais besoin de la seconde.

Sur Android, le VPN n’est même plus toujours le seul suspect

Il existe désormais une autre raison de vérifier le contexte avant de modifier dix réglages VPN.

Avec Android 17, les applications qui ciblent cette version doivent obtenir une autorisation spécifique pour accéder au réseau local. Sans elle, une application peut continuer à accéder à Internet tout en perdant la possibilité de découvrir certains équipements présents sur le Wi-Fi domestique.

C’est une distinction utile.

Si une seule application ne voit plus une enceinte ou une imprimante après une mise à jour, je commencerais par ses autorisations.

Mais lorsque plusieurs ressources locales réapparaissent immédiatement dès que le VPN est coupé, comme dans le scénario que je testais, le tunnel redevient le suspect évident.

Surtout, cela montre pourquoi changer cinq fois de serveur VPN peut donner l’impression d’agir sans jamais toucher au vrai problème.

Le serveur distant n’était pas en panne.

C’était le chemin vers les appareils situés à quelques mètres de moi qui avait été mal choisi.

Mon contournement fonctionnait — à condition d’accepter de vivre avec un interrupteur

À 11 h 31, je connaissais déjà une méthode infaillible.

VPN désactivé: imprimante disponible.

VPN activé: Internet protégé, imprimante disparue.

J’ai donc imprimé le bordereau avec le VPN coupé.

Le papier est sorti immédiatement.

J’aurais pu en rester là.

Sauf que le fichier à joindre au dossier d’expédition était stocké sur le NAS, et que je devais ensuite envoyer le tout depuis un portail professionnel.

J’ai commencé une petite chorégraphie assez absurde.

VPN désactivé.

Ouvrir le NAS.

Copier le document.

Imprimer.

VPN activé.

Retourner sur le portail.

Reprendre la session.

Téléverser le fichier.

Puis j’ai remarqué que j’avais oublié une seconde pièce sur le NAS.

VPN désactivé.

À ce stade, le problème n’était plus vraiment de savoir si le VPN « fonctionnait ».

Il fonctionnait.

Le NAS fonctionnait.

L’imprimante fonctionnait.

Je ne pouvais simplement pas utiliser tout cela en même temps.

C’est là que j’ai cessé de comparer les VPN sur la quantité de réglages disponibles.

Je voulais que le réseau public et mon réseau local soient traités comme deux destinations différentes, sans transformer chaque impression en exercice de routage.


Mon nouveau test tenait finalement en trois fenêtres

J’ai ouvert OnlydogVPN.

Le service est plus petit que les acteurs établis. Il propose moins de localisations, son historique public est plus court et il existe moins de tests indépendants à son sujet. Pour quelqu’un qui cherche avant tout une adresse IP dans une ville très précise, c’est une limite réelle.

Mais mon problème, lui, se trouvait à l’intérieur de la maison.

J’ai utilisé le mode prévu pour conserver l’accès aux appareils du réseau local tout en maintenant le trafic Internet dans la connexion protégée. C’est exactement la séparation qui m’avait manqué jusque-là.

Puis j’ai arrêté de regarder l’application VPN.

Je suis retourné voir les trois choses qui comptaient réellement.

L’imprimante d’abord.

Disponible.

J’ai lancé une page de test.

Elle est sortie.

Ensuite, le NAS.

J’ai utilisé son raccourci habituel, pas une adresse IP mémorisée pour contourner le problème.

Le dossier s’est affiché.

Enfin, j’ai repris le portail Internet.

Toujours accessible avec le VPN actif.

C’était le test entier:

imprimante locale;

NAS local;

site distant.

Les trois en même temps.

Et, pour ce problème précis, ce résultat disait beaucoup plus qu’un tableau contenant cinquante pays supplémentaires.

Le principe du mode est assez simple: les destinations qui appartiennent au réseau local restent sur le réseau local, tandis que le trafic destiné à Internet continue de suivre la connexion protégée.

Je n’avais pas besoin d’inspecter chaque règle réseau pour savoir si cela répondait à mon problème.

Je pouvais le constater.

Le NAS ne disparaissait plus lorsque le tunnel s’ouvrait.

L’imprimante ne passait plus « hors ligne ».

Le portail restait connecté.

J’ai récupéré la seconde pièce, lancé l’impression et envoyé le dossier sans toucher une nouvelle fois au bouton du VPN.

À 11 h 43, le colis était fermé.

Ce résultat ne m’a pas donné envie d’autoriser mon LAN partout

Il m’a plutôt fait comprendre qu’un réseau local n’est utile que lorsqu’il mérite réellement ma confiance.

Chez moi, je veux que mon ordinateur puisse voir mon NAS et mon imprimante.

Sur le Wi-Fi d’un hôtel, d’un café ou d’un salon professionnel, je n’ai aucune raison d’accorder le même traitement aux appareils inconnus connectés autour de moi.

C’est là qu’un choix lié au contexte devient plus intéressant qu’une exception permanente oubliée dans un menu.

À la maison: conserver l’accès aux appareils locaux.

Sur un réseau public: les laisser à distance.

Ce qui m’avait d’abord semblé être une simple simplification d’interface répondait en réalité à un problème assez concret: je n’ai pas envie d’administrer la même politique réseau dans deux environnements qui n’ont rien à voir.

Ce que je testerais d’abord la prochaine fois

Si je devais choisir à nouveau un VPN pour une maison équipée d’un NAS, d’une imprimante réseau ou d’autres appareils locaux, je ne commencerais plus par compter les serveurs.

Je connecterais le VPN.

Puis j’ouvrirais l’appareil exactement comme je le fais tous les jours: nom du NAS, imprimante découverte automatiquement, tableau de bord .local ou équipement trouvé par l’application.

Ensuite seulement, je vérifierais Internet.

Si l’adresse IP fonctionne mais pas le nom de l’appareil, je regarderais du côté de la résolution locale ou de mDNS.

Si l’appareil disparaît complètement dès l’activation du tunnel, je chercherais un véritable accès LAN plutôt qu’une simple liste d’applications à exclure.

Et si je dois maintenir cinq exceptions, plusieurs processus et des règles que je vais oublier dans trois semaines simplement pour imprimer une page, ce n’est plus moi qui utilise le VPN: c’est moi qui l’administre.

Mon ancien service avait davantage de serveurs et davantage de réglages.

Ce n’était pas un mauvais VPN.

Il me demandait simplement de raisonner en applications alors que mon problème concernait des destinations.

C’est la distinction que je regarderais désormais en premier: pour garder un NAS ou une imprimante accessibles, le VPN doit comprendre qu’un appareil situé à trois mètres de moi n’a aucune raison de prendre le tunnel pour revenir à la maison.