Port 445 et VPN : comment j’ai accédé à mon NAS sans rendre SMB public sur Internet

J’avais déjà rempli les trois cases.

Port externe: 445.

Adresse: celle de mon NAS.

Port interne: 445.

Il ne restait qu’à cliquer sur Enregistrer.

J’étais dans un espace de coworking à Bruxelles et j’avais besoin d’un dossier de travail resté sur mon NAS en France. Dans l’Explorateur Windows, j’avais l’habitude d’ouvrir:

\\NAS-BUREAU\Clients

À la maison, le partage apparaissait immédiatement.

À distance, rien.

J’avais vingt-cinq minutes avant qu’un client me demande deux fichiers sources pendant une revue, et la solution semblait presque insultante de simplicité: transférer le port SMB du routeur vers le NAS, récupérer les fichiers, puis refermer le port après.

J’ai laissé le curseur au-dessus du bouton.

Puis je me suis demandé pourquoi tant de réseaux bloquaient précisément ce port.

Le port 445 n’était pas une porte que j’avais envie de mettre sur la rue

SMB utilise principalement TCP 445 pour les partages de fichiers modernes.

À l’intérieur de mon réseau local, c’était exactement ce que je voulais. Mon ordinateur devait pouvoir parler directement au NAS.

Internet change complètement le contexte.

Microsoft recommande de bloquer les communications SMB externes en TCP 445 aux frontières du réseau et considère qu’un trafic SMB directement entrant depuis Internet ou sortant vers Internet est rarement nécessaire en dehors de quelques scénarios spécifiques.

CISA recommande elle aussi de bloquer l’accès SMB externe inutile et de limiter ces communications aux systèmes qui en ont réellement besoin.

Ce n’était donc pas simplement une vieille superstition autour de SMB1.

Mon NAS était à jour. J’utilisais une version moderne de SMB. Mes mots de passe n’étaient pas triviaux.

Mais ouvrir 445 revenait quand même à prendre un service jusque-là caché derrière mon réseau privé et à poser sa porte directement sur Internet.

Et quelques mois plus tôt, Synology avait publié un avis DSM classé « Important » corrigeant plusieurs vulnérabilités pouvant permettre, selon les cas, à des attaquants distants ou authentifiés de lire ou modifier des fichiers, obtenir des informations ou provoquer un déni de service.

Cet avis ne disait pas que « mon port 445 allait être piraté ».

Il rappelait quelque chose de plus utile: je ne peux pas prévoir la prochaine vulnérabilité du NAS, mais je peux décider combien de services de ce NAS sont directement visibles depuis Internet lorsqu’elle apparaît.

J’ai fermé la fenêtre de redirection sans enregistrer.

Le fichier était toujours inaccessible.

Mais l’urgence de vingt-cinq minutes n’allait pas devenir une ouverture permanente sur mon routeur.

Ce que je voulais vraiment, ce n’était pas SMB sur Internet

J’avais formulé mon problème de la mauvaise façon.

Je pensais:

« Comment rendre le port 445 accessible depuis Bruxelles? »

La vraie question était:

« Comment faire en sorte que mon ordinateur soit de nouveau sur un réseau autorisé à atteindre le port 445? »

La différence semble petite.

Elle change toute l’architecture.

Au lieu d’exposer SMB, je pouvais établir un tunnel privé jusqu’à mon réseau domestique. Le NAS garderait son adresse privée et SMB resterait exactement là où je le voulais: derrière le routeur.

Une fois le tunnel établi, mon ordinateur ne demanderait plus à Internet:

« Où est le port 445 de mon NAS? »

Il demanderait simplement au réseau privé:

\\192.168.1.32\Clients

QNAP recommande d’ailleurs cette logique pour réduire le nombre de services NAS exposés: utiliser un VPN, notamment WireGuard, puis accéder aux services internes à travers ce tunnel plutôt que publier séparément SMB et d’autres ports du NAS.

J’avais déjà WireGuard disponible sur mon routeur.

J’ai créé le profil d’accès distant, laissé SMB fermé côté Internet et autorisé le réseau VPN à rejoindre l’adresse privée du NAS.

Puis j’ai fait le test le plus simple possible.

J’ai coupé le Wi-Fi du coworking.

Hotspot 5G.

WireGuard connecté.

J’ai saisi l’adresse privée du NAS.

Le dossier est apparu.

C’était exactement le comportement que je voulais.

Depuis Internet, le partage SMB n’était pas une destination publique.

Une fois dans mon tunnel domestique, il redevenait simplement un partage du réseau local.

J’avais trouvé la bonne architecture.

Je n’avais pas encore récupéré mes fichiers.

Le coworking m’a rappelé pourquoi une bonne architecture peut encore échouer

Je suis revenu sur son Wi-Fi.

Internet fonctionnait parfaitement.

J’ai lancé le tunnel WireGuard vers la maison.

Attente.

Nouvelle tentative.

Toujours rien d’utilisable.

J’ai vérifié le NAS depuis mon téléphone en 5G.

Il répondait.

J’ai remis l’ordinateur sur le hotspot.

Le tunnel domestique revenait.

Coworking: non.

Hotspot: oui.

À ce moment-là, je savais au moins où regarder.

Le NAS fonctionnait.

Le profil WireGuard fonctionnait.

Le changement décisif était le réseau devant moi.

Et ouvrir directement 445 n’aurait pas été une échappatoire très intelligente. Microsoft rappelle encore dans sa documentation Azure Files que de nombreuses organisations et de nombreux fournisseurs d’accès bloquent le trafic SMB sortant en TCP 445.

J’aurais donc pu prendre davantage de risque et me retrouver malgré tout sans accès.

Mon problème avait changé.

Je ne cherchais plus à faire traverser SMB directement.

Je cherchais à faire traverser le tunnel qui me donnait accès à SMB.

J’ai enfin séparé deux choses que j’appelais toutes les deux « VPN »

Une discussion publique sur r/Synology m’a rappelé à quel point cette confusion est fréquente.

Un utilisateur avait correctement configuré OpenVPN pour accéder à son NAS à distance, puis se demandait s’il pouvait en même temps utiliser un VPN commercial pour sa navigation.

La question m’a paru beaucoup moins étrange qu’elle ne l’aurait été une heure plus tôt.

Les deux outils portaient le même nom.

Ils n’avaient pas le même travail.

Le VPN de ma maison devait me donner une route vers un réseau privé précis: celui où vivait mon NAS.

Le VPN de voyage devait d’abord donner à mon ordinateur une connexion utilisable à travers le réseau devant moi.

Je ne voulais surtout pas que le second remplace mon tunnel domestique.

Je voulais qu’il lui donne une route praticable jusqu’à son point de départ.

C’est là que j’ai ouvert la petite application installée sur le portable.

Un tunnel a simplement donné une route à l’autre

Je suis resté sur le Wi-Fi qui posait problème.

Passer en 5G aurait seulement confirmé une troisième fois que mon NAS fonctionnait. Ce n’était pas ce que je voulais résoudre.

J’ai sélectionné le mode prévu pour un réseau restrictif et lancé la connexion.

Elle s’est établie.

Je n’ai pas ouvert un Speedtest.

Je n’en avais plus besoin.

J’ai relancé mon profil WireGuard domestique.

Quelques secondes plus tard, le handshake est apparu.

Puis j’ai tapé:

\\192.168.1.32\Clients

Le dossier s’est ouvert.

Voilà le résultat que je cherchais depuis le début.

Pas une adresse IP publique supplémentaire.

Pas un port 445 visible depuis l’extérieur.

Mon partage SMB privé.

J’ai ouvert le dossier du projet, copié les deux fichiers sources et surveillé la progression.

18 %.

46 %.

73 %.

100 %.

J’ai ouvert le premier fichier directement depuis le disque local pour vérifier qu’il était complet, puis le second.

Il me restait assez de temps pour les importer avant la revue.

La petite application n’avait jamais « ouvert SMB ».

Elle n’avait pas besoin de connaître mon NAS.

Son travail se passait avant: établir une connexion utilisable à travers le Wi-Fi du coworking. Une fois cette route en place, mon tunnel WireGuard vers la maison pouvait à son tour s’établir et me remettre sur le réseau où SMB était autorisé.

Le service utilise dans ce mode un transport basé sur HTTP/3 avec une couche d’obfuscation supplémentaire.

Je l’ai compris comme deux portes successives.

La première me faisait sortir correctement du coworking.

La seconde me faisait entrer chez moi.

Et derrière cette seconde porte se trouvait le NAS.

Je ne pouvais pas voir la règle exacte du réseau du coworking qui perturbait la connexion directe.

Je pouvais voir le résultat:

Hotspot + WireGuard domestique: NAS accessible.

Wi-Fi du coworking + WireGuard domestique direct: échec.

Même Wi-Fi + première connexion, puis WireGuard domestique: partage ouvert et fichiers copiés.

Pour moi, la décision était prise.

Ce que la petite application ne remplace pas compte justement beaucoup

Cette configuration a une limite claire.

Un VPN commercial ne transforme pas automatiquement un NAS domestique en ressource privée accessible à distance.

Il faut toujours une vraie porte côté maison: WireGuard sur le routeur, un serveur VPN sur le NAS, une solution de réseau maillé appropriée ou une architecture équivalente.

C’est ce tunnel domestique qui autorise mon ordinateur à atteindre 192.168.1.32:445.

La petite application intervient avant.

Elle devient utile lorsque le réseau sur lequel je me trouve empêche ce tunnel privé de fonctionner correctement.

Cette séparation me convient mieux qu’une solution qui prétendrait tout faire.

Le NAS garde son propre contrôle d’accès.

SMB reste privé.

La connexion de voyage s’occupe du réseau devant mon ordinateur.

Et lorsque ce réseau devient compliqué, je peux changer la manière de l’emprunter sans changer la façon dont mon NAS est exposé.

Le service a aussi une limite plus classique: il propose moins de régions de sortie et possède moins d’historique public que les plus grands fournisseurs. Pour choisir manuellement parmi des dizaines de pays, cela compte.

Dans ce scénario, je ne cherchais pas un pays.

Je cherchais juste une route assez fiable pour atteindre mon propre tunnel.

J’ai finalement fermé un port au lieu d’en ouvrir un

Après la réunion, je suis retourné dans l’interface du routeur.

La règle TCP 445 que j’avais failli créer n’existait toujours pas.

Je l’ai vérifié une deuxième fois.

Depuis Internet, mon NAS n’avait donc pas acquis une nouvelle porte SMB publique simplement parce que j’avais eu besoin de deux fichiers à Bruxelles.

Depuis le tunnel domestique, en revanche, le partage continuait à fonctionner exactement comme à la maison.

C’est désormais la distinction que je garde en tête.

Si je dois connaître mon adresse IP publique et taper directement \\adresse-publique\partage, je suis en train d’essayer de rendre SMB accessible depuis Internet.

Si je connecte d’abord mon réseau privé puis utilise l’adresse privée habituelle du NAS, SMB reste derrière la frontière que j’avais prévue.

Et si un hôtel, un coworking ou le réseau d’un client refuse le tunnel privé lui-même, je préfère changer la manière dont ce tunnel atteint la maison plutôt que rouvrir 445 par frustration.

J’avais commencé avec le curseur posé sur Enregistrer à côté d’une règle TCP 445.

J’ai terminé avec les deux fichiers sur mon ordinateur et aucune nouvelle règle SMB publique sur mon routeur.

Pour accéder à mon NAS depuis Bruxelles, je n’avais finalement pas besoin de mettre le port 445 sur Internet.

J’avais besoin d’un chemin qui me ramène jusqu’à lui sans jamais l’y exposer.