Sortir le reverse proxy de son Synology : bascule vers Nginx Proxy Manager sur Proxmox

Votre NAS Synology fait office de reverse proxy pour votre domotique Home Assistant et d’autres serveurs de votre infra ? Il y a de fortes chances que la page de connexion DSM soit, elle aussi, accessible depuis Internet. C’est le cas dès que la box redirige le port 443 vers le port 5001 du NAS : la configuration la plus répandue, et celle que j’utilisais moi-même jusqu’à ce que je me repenche sur mon infra pour un petit côté “robustify”, d’autant qu’actuellement les attaques de NAS Synology se multiplient, il est plus que temps d’agir chez vous !

Dans ce guide, on sort le reverse proxy du NAS pour le confier à Nginx Proxy Manager (NPM), un service dédà dans cette tâche, installé dans un conteneur LXC sous Proxmox VE. Une suite logique si vous avez suivi mes autres guides et recommandations autour de la construction d’un cluster Proxmox.
Au passage, on remplace également les certificats Let’s Encrypt renouvelés à la main (port 80 ouvert le temps de l’opération) par un certificat wildcard renouvelé automatiquement, sans aucun port supplémentaire ouvert. Et surtout, on fait la bascule sans coupure et de façon réversible, même si vous verrez que vous supprimerez rapidement la configuration du Syno pour le couper complètement de tout accès extérieur et conserver vos données précieuses sur le LAN, là où elles sont plus en sécurité.

Prérequis

• Un serveur Proxmox, un nœud suffit, mais un cluster comme mon Dark-Cluster c’est mieux !
• Un nom de domaine dont la zone DNS est gérée chez un fournisseur doté d’une API (OVH dans ce guide pour rester dans la continuité de mon premier guide, mais bien d’autres sont pris en charge par NPM).
• Un accès à l’interface de votre box pour modifier la redirection de ports (Freebox Delta dans mon cas).
• Un ordinateur sur le réseau local avec un terminal, pour les tests.

---

Pourquoi sortir le reverse proxy du NAS ?

Le reverse proxy intégré à DSM est pratique, mais il expose l’équipement qui contient vos données. Avec une redirection 443 vers 5001, toute requête qui ne correspond à aucune règle (l’IP publique en direct, un sous-domaine inventé) tombe sur la page de login DSM. Votre NAS devient alors une cible pour les bots qui scannent Internet en permanence.

Sortir cette brique dans un conteneur dédié apporte alors quatre gains concrets :

• Le NAS n’est plus exposé. Plus aucun port ne pointe vers lui, un service compromis derrière le proxy ne donne pas d’accès direct au stockage.
• Des certificats sans effort. Le challenge DNS-01 permet un certificat wildcard renouvelé automatiquement, sans ouvrir le port 80.
• Une meilleure discrétion. Un seul certificat *.mondomaine.fr au lieu d’un certificat par service : vos noms de services n’apparaissent plus dans les journaux publics Certificate Transparency (consultables sur crt.sh).
• Une porte ouverte vers la suite. Logs exploitables, CrowdSec, WAF : tout ce que le nginx de DSM rend difficile devient possible.

Pourquoi NPM plutôt que Caddy ou Traefik ?

Question legitime, Caddy est bien plus leger, mais demande de la configuration par ligne de commande. Nginx Proxy manager (NPM) dispose d’une interface web : pas de fichier de configuration à écrire, et une prise en main en quelques minutes. Les deux autres restent d’excellents choix pour qui veut une configuration versionnée dans Git, mais la migration vers NPM fait plus sens pour une transition douce depuis DSM. Un conteneur LXC leger suffit pour le faire tourner alors pourquoi s’en priver ?

Architecture cible et méthode de bascule

La box ne redirige plus le port 443 vers le NAS mais vers un conteneur LXC dédié sous proxmox, le NAS ne reçoit alors plus aucun trafic venu d’Internet et ne sert plus que sur le reseau local.

La méthode repose sur un principe simple : l’ancien et le nouveau proxy cohabitent jusqu’à notre validation finale pour zero interruption de service et une transition tout en douceur.

1. On déploie et on configure NPM à côté du NAS, sans rien changer à la production.
2. On autorise NPM auprès des services, en plus du NAS.
3. On teste NPM depuis le réseau local.
4. On bascule la redirection de la box : c’est la seule action visible depuis l’extérieur, et elle s’annule en trente secondes.
5. On nettoie enfin la configuration du NAS Synology une fois la nouvelle configuration éprouvée.

Étape 1 : déployer Nginx Proxy Manager dans un LXC Proxmox

Les Proxmox VE Helper-Scripts (projet communautaire community-scripts) installent NPM nativement dans un conteneur Debian, sans Docker. Depuis le Shell du nœud Proxmox en une simple commande :

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/nginxproxymanager.sh)"

Choisissez le mode Advanced pour maîtriser les paramètres clés :

• IP statique en dehors de la plage DHCP de la box (ici 192.168.1.240) : elle deviendra la cible de la redirection 443
• conteneur non privilégié
• un hostname explicite, par exemple npm

À la fin, le script affiche l’URL d’administration sur le port 81. Il est temps de se connecter à NPM ppur entrer dans le vif du sujet. Pour cela utiliser l’URL : http://ip_de_npm:81

Étape 2 : sécuriser NPM avant toute configuration

Trois réglages à faire dès la première connexion sur http://IP-DE-NPM:81 :

1. Compte administrateur : Au premier lancement, NPM vous invite a créer un compte admin.

2. Settings > Default Site → No Response (444). Tout nom d’hôte non déclaré, ou l’IP publique en direct, reçoit une connexion fermée sans réponse. C’est exactement le trou qui exposait DSM : on le referme avant même de créer le premier proxy.

3. Port 81 : il ne doit jamais être redirigé sur la box internet ou le routeur. L’administration de NPM reste strictement locale (ou via votre VPN).

Pourquoi c’est important : si votre zone DNS contient un enregistrement wildcard (*.mondomaine.fr), n’importe quel sous-domaine, même inventé, arrive chez vous. Sans Default Site en 444, NPM répondrait avec sa page d’accueil.

Étape 3 : un certificat wildcard Let’s Encrypt via l’API OVH

Le challenge DNS-01 prouve à Let’s Encrypt que vous contrôlez le domaine en créant un enregistrement TXT temporaire via l’API de votre fournisseur DNS. C’est la seule méthode qui permet un certificat wildcard, et elle n’exige aucun port ouvert.

Créer le jeton API OVH

Sur https://eu.api.ovh.com/createToken/ :

• Validity : Unlimited. Avec une durée limitée, le renouvellement cassera sans prévenir à l’expiration du jeton.
• Rights, limités à votre seule zone :

Notez et conservez bien les trois valeurs générées : Application Key, Application Secret et Consumer Key.

Demander le certificat dans NPM

Toujours sur le portail web de Nginx Proxy manager, rendez-vous dans Certificates > Add SSL Certificate > Let’s Encrypt et choisissez Let’s Encrypt via DNS.

• Domain Names : *.mondomaine.fr et mondomaine.fr ;
• Key Type : ECDSA (plus léger que RSA à sécurité équivalente, pris en charge par tous les clients modernes, dont l’app compagnon Home Assistant) ;
• Use a DNS Challenge activé, fournisseur OVH ;
• Propagation Seconds : 120.

Le champ Credentials File Content est pré-rempli avec des valeurs d’exemple (MDAwMDAw…). Gardez les quatre lignes et remplacez uniquement les valeurs par celles de votre jeton API générés plus haut :

dns_ovh_endpoint = ovh-eu
dns_ovh_application_key = <Application Key>
dns_ovh_application_secret = <Application Secret>
dns_ovh_consumer_key = <Consumer Key>

Après une à deux minutes, le certificat apparaît dans la liste avec sa date d’expiration. On ne le crée qu’une seule fois : il sera réutilisé par tous les proxy hosts.

Étape 4 : préparer les services en amont

Certaines applications n’acceptent les en-têtes X-Forwarded-For que d’un proxy explicitement autorisé. On ajoute donc l’IP de NPM sans retirer celle du NAS : les deux proxys fonctionnent en parallèle pendant la transition, ce qui rend la bascule réversible.

Pour la domotique Home Assistant, c’est très simple, depuis quelques MAJ, la gestion du reverse proxy se fait dans l’interface graphique sous Parametres/Système/Réseau/Proxy inversé.

Ajoutez un nouveau proxy de confiance en plus de celui du Synology et enregistrez. Le système domotique demandera un redémarrage pour prendre en compte le changement.

Après redémarrage, Home Assistant demandera une confirmation de la nouvelle configuration.

Adaptez ce même principe à vos autres services qui doivent être joignable depuis l’exterieur : la plupart des applications auto-hébergées ont un réglage équivalent (« trusted proxies », « proxy hops », « base URL »).

Étape 5 : recréer les règles dans NPM

Repartez de l’inventaire de vos règles de proxy DSM (Portail de connexion > Avancé > Proxy inversé) et créez un proxy host par règle via Hosts > Proxy Hosts > Add Proxy Host.

Onglet Details

• Block Common Exploits : activé ;
• Websockets Support : activé. Cette case remplace les deux en-têtes personnalisés Upgrade / Connection qu’on ajoutait à la main dans DSM.

Les délais d’expiration de 60 secondes configurés côté DSM correspondent aux valeurs par défaut de nginx : rien à reporter.

Onglet SSL

• SSL Certificate : sélectionnez votre domaine dans la liste *.mondomaine.fr, mondomaine.fr. NPM ne l’appelle pas « wildcard », il affiche les domaines couverts, mais c’est le même principe.
  Surtout pas Request a new Certificate, qui créerait un certificat individuel visible publiquement.

• Force SSL : activé
• HTTP/2 Support : activé
• HSTS Enabled : activé
• HSTS Sub-domains : désactivé. Cette option s’appliquerait à tout le domaine, y compris un éventuel site www hébergé ailleurs.
• Advanced > Trust Upstream Forwarded Proto Headers : désactivé. Cette option ne sert que si NPM est lui-même derrière un autre proxy ou un CDN.

Étape 6 : tester en local, sans toucher à la box

À ce stade, Internet continue d’arriver sur le NAS. On valide NPM depuis un ordinateur du réseau local grâce à l’option --resolve de curl, qui force la résolution d’un nom vers une IP pour la seule commande en cours : pas de fichier hosts à modifier.

# 1. Chaque service répond-il via NPM ?
for h in ha server2 server3; do
  echo "== $h"
  curl -sI --resolve $h.mondomaine.fr:443:192.168.1.220 https://$h.mondomaine.fr | head -n 1
done

# 2. Le certificat servi est-il bien le wildcard ?
openssl s_client -connect 192.168.1.220:443 -servername ha.mondomaine.fr </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate

# 3. Un sous-domaine inconnu doit être rejeté (code 000 = connexion fermée sans réponse)
curl -sk --resolve test.mondomaine.fr:443:192.168.1.220 https://test.mondomaine.fr -o /dev/null -w '%{http_code}\n'

Les resultats en sortie doivent vous indiquer respectivement :

1. HTTP/2 405 pour le test 1 (HTTP/2 200 indique un service injoignable, il faudra verifier que les changement de proxy dans Home Assistant et les autres services on bien été appliqués).
2. subject=CN=*.mondomaine.fr pour le test 2. Le wildcard est servi ; l’émetteur commençant par « E » ou « YE » confirme une clé ECDSA.
3. 000 pour le test 3 indique que la regle Default Site 444 configuré plus haut fonctionne parfaitement.

Pour confirmer Home Assistant avec une vraie requête GET :

curl -s -o /dev/null -w '%{http_code}\n' --resolve ha.mondomaine.fr:443:192.168.1.220 https://ha.mondomaine.fr/
# attendu : 200

Sous Windows : curl est natif depuis Windows 10, mais pas openssl. Pour vérifier le certificat, ouvrez l’URL dans le navigateur et cliquez sur le cadenas.

Si vous avez passé les tests avec succès, il est temps d’operer la bascule.

Étape 7 : basculer la redirection sur la box

C’est la seule action visible depuis l’extérieur. Sur une Freebox : Freebox OS > Paramètres de la Freebox > Mode avancé > Gestion des ports, modifiez la règle existante pour ne plus rediriger le port 443 vers 5001 du NAS mais vers le port 443 de NPM.

Aucune redirection du port 80 n’est nécessaire : le certificat se renouvelle en DNS-01.

Retour arrière : en cas de problème, remettre la règle vers IP du NAS:5001 restaure l’ancienne configuration en trente secondes, puisque les règles DSM sont toujours en place.

Étape 8 : valider depuis l’extérieur

Depuis un smartphone en 4G/5G, Wi-Fi coupé :

• https://ha.mondomaine.fr dans le navigateur, puis dans l’app compagnon : les états doivent se mettre à jour en temps réel, ce qui valide les WebSockets.
• Même contrôle pour chaque autre instance
• https://<votre IP publique> : la connexion doit échouer. La page de login DSM n’est plus accessible depuis Internet.
• Test sur SSL Labs avec l’un de vos sous-domaines : avec HSTS activé, la note attendue est A+.

Étape 9 : nettoyer et durcir le Synology

Laissez tourner la nouvelle configuration quelques jours : les règles DSM ne reçoivent plus de trafic, mais elles restent votre plan de retour arrière. Une fois serein :

1. Supprimez les règles dans Portail de connexion > Avancé > Proxy inversé.
2. Retirez l’IP du NAS de trusted_proxies sur chaque instance Home Assistant, puis redémarrez.
3. Supprimez les certificats Let’s Encrypt par sous-domaine dans Sécurité > Certificat : ils ne seront plus renouvelés.
4. Restreignez le pare-feu DSM (Sécurité > Pare-feu) : autorisez le sous-réseau local (et votre VPN), puis une dernière règle Refuser tout.
5. Désactivez au passage ce qui ouvre le NAS vers l’extérieur sans que vous l’ayez choisi : QuickConnect (service cloud Synology) et UPnP s’ils ne servent pas.

Votre NAS redevient ce qu’il aurait toujours dû être : un équipement de sauvegarde et de stockage joignable uniquement depuis le réseau local.

---

Conclusion

En un peu moins d’une heure, le NAS a disparu de la surface d’attaque, les certificats se renouvellent seuls et chaque service exposé passe par une brique dédiée, facile à sauvegarder et à remplacer. Le tout sans coupure et avec un retour arrière possible à chaque étape.

NPM en frontal ouvre surtout la porte à la suite logique : analyser ses journaux avec CrowdSec pour bannir automatiquement les IP malveillantes avant même qu’elles atteignent vos services. Ce sera l’objet d’un prochain guide.

Enfin, n’oubliez pas de configurer la réplication de NPM au sein de votre cluster ainsi que le HA Proxmox pour garantir un proxy toujours up, même en cas de défaillance. Votre HomeLab vient de passer un nouveau cap, mais ce n’est pas fini !

LA FAQ