Configuration de mon NAS QNAP

Gratz · Février 5, 2024, 8:44

Bon, j’ai pas tout compris, c’est pas faute d’essayer, mais j’ai vraiment des lacunes en réseau et y’a des concepts que je capte pas… merci en tous cas de prendre du temps pour moi

Aujourd’hui :

J’ai des IPs différentes sur chacun de mes services, services qui tournent dans des containers sur le NAS, qui a une IP fixe (192.168.0.10).
Mes services vont de 192.168.0.201 à 192.168.0.2XX, ils ont des IP fixes que j’ai définies dans chaque container. Ça fonctionne bien, RAS de ce côté, je tape donc sur mes services en allant sur http://192.168.0.2XX:port.
Mon Pi Hole n’est pas mon serveur DHCP, je n’ai pas vraiment réussi à aller jusque-là, j’ai donc laissé mon routeur en serveur DHCP (ce qui ne me dérange pas vraiment puisque je peux y faire ce que je veux).
La Livebox qui fournit la fibre elle, n’a qu’une plage d’IP restreinte à une seule IP, que j’attribue au [stroke]NAS[/stroke] routeur Archer directement (un truc que j’ai vu sur le net, je sais pas si c’est vraiment une bonne idée, j’me dis que comme ça rien d’autre ne peut se voir attribuer une IP s’il tape sur la livebox).

Rapport à cela, sur le Pi-Hole, j’ai ajouté mon premier local DNS, qui tape sur l’ip dudit service. Exemple :

service1.local / 192.168.0.201

Je vois pas bien le concept après. J’ai essayé d’ajouter un proxy host dans nginx (mais du coup j’ai… ajouté service1.local sur cette même ip ??), mais ça marche pas du tout…

Qu’est ce que je rate ?

pr7 · Février 5, 2024, 10:56

En fait le service que tu vas appeler sera majoritairement ton reverse proxy.
C’est toujours cette IP (via la résolution de nom) que tu va appeler sur le port 80 (http) ou 443 (https).
Et le reverse proxy va rediriger le flux vers le service de ton choix en fonction de l’adresse appelée (que tu auras bien entendu paramétrée au préalable sur Nginx).
Par exemple si tu appel service1.reverseproxy.local il va chercher dans sa conf à quelle IP et port correspond « service1 » et renvoyer vers 192.168.0.201:2345
Et service2.reverseproxy.local va renvoyer vers 192.168.0.202:3456

Vu que tu as choisi d’avoir des IP fixe dédiées pour tes containers, et qu’ils sont en plus en mode bridge (pas vraiment standard comme conf), tu peux bien entendu les parametrer directement sur tes DNS local. Tu sera par contre obliger de spécifier manuellement les ports dans l’URL que tu va appeler. Dans ce cas aucun flux ne passera par le reverse-proxy. Mais tu pourra joindre les services sur servicex.local:1234

J’espère que c’est un peu plus clair.

Au préalable, il faut bien entendu que tu ai configuré l’IP de ton PiHole comme DNS sur ton serveur DHCP pour que tes terminaux puisse récupérer le bon DNS.
Tu peux déjà vérifier si la résolution de nom fonctionne en faisant un ping ou un nslookup depuis un terminal : nslookup service.local.

J’espère que c’est un peu plus clair.

Petit aparté, un standard semble enfin pointer le bout de son nez sur un TLD purement local (oui, y’a rien de définit pour le moment) : .internal

Sarbian · Février 6, 2024, 9:13

Alors non, ce n’est pas vraiment une bonne idée. Ça expose tout tout NAS sur le net, dont sa page d’admin et tes partages (modulo le fait que le firewall Livebox bloque ce port par defaut il me semble)
Pour juste exposer un port il faut faire une redirection dans l’onglet Réseau=> NAT/PAT de la livebox. Là tu ajoute une redirection pour HTTPS et HTTP vers ton NAS. Ca donne deux lignes de ce style (de mémoire:
HTTPS 443 443 TCP TonIPNginx vide
HTTP 80 80 TCP TonIPNginx vide

pr7 · Février 6, 2024, 5:35

Cette partie est pas super claire et pas trop racord avec les informations précédentes.
J’avais compris initialement que c’était le DHCP du routeur « Archer » qui donnait l’IP au NAS. Je vois pas bien ce que viens faire la Livebox dans cette histoire.
Et il me semblait que le portable du fils était lui sur la Livebox (il a donc besoin d’une IP en DHCP).
Je connais pas la Livebox mais à moins qu’il ai mis son NAS dans une patte « DMZ » rien ne sera exposé par défaut. Au contraire, il lui faudra faire du double NAT …

Gratz · Février 6, 2024, 7:09

Pour la livebox désormais tout est sur le routeur derrière. Je me suis mal exprimé dans mon précédent message : la livebox n’attribue qu’une seule IP sur son DHCP, c’est l’IP du routeur Archer.

C’est ensuite le DHCP du Archer qui donner les IP aux différents terminaux.

Pour le reverse proxy je regarde ce soir.

Gratz · Février 6, 2024, 9:07

En fait quand j’ai commencé à les mettre en conf « par défaut » (en NAT donc), ça ne fonctionnait pas : je les ai donc tous passés en Bridge avec leur IP fixe et rulez.

Je viens de réessayer et ça fonctionne : j’ai donc changé les 3 services que j’ai actuellement en NAT.

Désormais j’suis donc plus dans une conf’ « standard » selon ce que tu entends @pr7 ?

Est-ce que par contre je peux / dois laisser Pi-Hole sur une IP fixe pour permettre au routeur de taper directement dessus ?

Je pense avoir compris le principe. Je comprends juste pas comment l’implémenter.

Côté reverse proxy / local DNS : dans Pi Hole, je déclare quoi ?
Si je reprends tes exemples, faut que je mette un domaine, n’importe lequel genre « reverseproxy.local » ? Et l’IP du NAS en face ?

Sans rien mettre côté NGinx & PiHole, actuellement sur

« http://192.168.0.10:8080/ » j’tombe bien sur l’admin web QNAP.
« http://192.168.0.10:32768/ » j’tombe sur l’admin NGInx.
« http://192.168.0.10:38080/ » j’tombe sur le front NGInx. Est-ce que c’est plutôt sur le 80 que je devrais tomber là-dessus ?
« http://192.168.0.10 » j’tombe sur rien. C’est « normal » que sur le port 80 pour l’instant y’ait rien, parce que j’ai rien mis ni sur PiHole, ni sur NGinx ?

Gratz · Février 6, 2024, 9:22

Je réponds à côté pour pas créer de confusion dans mon avancement.

Si je mets dans le local DNS service1.local qui tape sur l’IP fourni en NAT par le container, alors je peux ping depuis le NAS l’adresse service1.local, qui me répond bien par l’IP qui lui est associée (en 10.x.x.x) => je suppose qu’à ce niveau c’est « ok ».

Deux questions par rapport à ça :

Quand depuis mon browser je tape sur « http://service1.local », je n’ai rien. Ca me paraît normal, je ne ping pas le 10.x.x.x depuis mon Windows. C’est côté NGinx que je dois ajouter quelque chose ? Mais quoi du coup ?
Si je mets la conf par défaut en NAT de mes containers, alors lors de la création c’est lui qui lui attribue une IP en fonction de son ordre de création (10.0.3.2, puis .3, etc). Comment je peux être sûr qu’au reboot du NAS ces IP sont les mêmes ??

pr7 · Février 6, 2024, 10:26

Oui. Je me demande même si ils ne recommandent pas d’executer le container en mode « network host ». Idéalement ton NAS devrait être en IP fixe également.

Tu as plusieurs possibilités.
L’important c’est qu’à chaque fois cela renvoi vers l’IP de Nginx.
Tu peux aussi créer plusieurs entrées service1.local, service2.local, etc… qui renvoient toutes vers le reverse§proxy (l’IP de ton NAS donc).
Personnellement je préfère suivre la nomenclature service.nas.local car je connais tous les services portés par mon NAS et cela m’évite d’avoir à changer ma conf sur le PiHole à chaque fois que je rajoute un nouveau service.

C’est difficile de te répondre sans savoir ce que tu as configuré sur ton NAS.
Si sur docker tu as exposé Nginx sur le port 80 et 443, cela devrait te mettre une page du genre « Bienvenue sur Nginx ».

En fait les IP de tes container sur le réseau virtuel de container station tu en as rien à faire pour des cas d’usages simples.
Lors de la création d’un container, tu choisis d’associer un ou plusieurs ports de tes container sur un port de ton host (ton NAS ici). C’est docker qui s’occupe de tout après. Par défaut ce sont les mêmes ports qui sont mappés. Donc au delà des Nginx, tu dois pouvoir retrouver tous tes services sur leur propres port, sur l’IP de ton NAS.

Sur l’interface de container station cela ressemble à ça :

A la création d’un container avec l’interface, cela ressemble à ça :

Dans des cas plus compliqués, tu peux envisager de ne pas Nater les accès vers tes containers avec Docker, hormis ton reverse proxy. Mais comme tu l’as indiqué, cela nécessite que les IP soient fixes. La meilleure solution que j’ai trouvé dans mon cas c’est plutôt d’utiliser Traefik comme reverse proxy. Il a l’avantage de pouvoir s’auto-paramétrer dynamiquement. Mais il a d’autres inconvénients par ailleurs (conf complexe).

Edit : Je viens de trouver un tutoriel assez court avec la conf à suivre. Il répond même au pb de l’IP fixe via Nginx en utilisant le hostname du container (ça ne m’étais pas venu à l’esprit) … Cela devrait t’aider.

Gratz · Février 7, 2024, 12:29

Oui, c’est ce qui est noté, c’est le mieux pour qu’il puisse faire serveur DHCP. Mais comme j’ai un routeur dédié pour ça, a priori ce n’est pas forcément nécessaire : le fait de le laisser en bridge fait qu’a priori, bosser avec Nginx est plus simple. Comme mon Pi-Hole fonctionne a priori (je n’ai que 5,6% « bloqués », je sais pas si c’est bien ou faible comme ratio, j’ai pourtant 5M de domaines en adlists…).

Pi-Hole = 192.168.0.210. J’ai fait pointer mon routeur sur ça en DNS, comme vu plus haut.

J’ai souvent des « long term load alerts » dans Pi-Hole, je pense que c’est lié au vieux NAS sur lequel il est installé. Je verrai quand tout sera clean s’il faudrait pas que je le foute un ptit raspberry à côté, même si je ne vois pas d’emmerdements à ce jour au quotidien.

Oui c’est le cas. NAS = 192.168.0.10.

Effectivement les transferts de ports « par défaut » du container étaient à la rue, et m’avaient proposé tout autre chose (ports 38xxx). J’ai tout reparamétré sur le port 80 & 443, et donc maintenant quand je tape sur l’IP du NAS, j’arrive effectivement sur le front NGinx.

Et en ajoutant un domaine nas.local, j’ai désormais bien accès à ce même front : cela fonctionne donc bien.

Tel que j’ai fait la suite :

Sur le Pi Hole, j’ai créé autant de service1.nas.local que de services, qui pointent tous sur l’IP du NAS (qui tape sur le NGinx donc).
Sur le NGinx, j’ai créé autant de Proxy Host que de service, en pointant à chaque fois le domaine vers l’ip du NAS et le port du service.

J’ai bon ? Dans l’histoire le NGinx il sert à quoi, « juste » à rediriger vers le bon port au final ?

J’étais sur le même, mais je ne comprends pas d’où sort son « unify-controller » dans le Forward Hostname / IP, là où moi j’ai une IP à chaque fois (celle du NAS où tourne le NGinx).

Ah, et j’ai pas compris l’histoire de supprimer les ports exposés dans la création des containers. Je vois bien qu’à priori je peux mettre un port d’url Web par défaut - exemple ici avec Overseer :

Mais si je n’expose pas les ports, bah il le trouve pas ? Du coup j’ai pas capté ce qu’il entend par « supprimer les ports sur les containers », donc je les ai laissé. Je suis pas certain que ce soit très grave ?

Gratz · Février 7, 2024, 1:34

Bon, j’ai presque tout bon… sur mon PC.

Bien sûr depuis mon tel en wifi, rien ne fonctionne (les ip:port si)

Edit : ok fallait reboot :]

pr7 · Février 9, 2024, 6:07

nas.local est suffisant normalement.
Les redirections vers les services seront gérés par Nginx.

Comme dis dans mon edit, l’utilisation des hostname semble plus interessantes que les IP. Cela permet d’adresser directement les container de manière dynamique (donc si ils changent d’IP, c’est pas grave).

D’une manière oui. Cela sert aussi à simplifier largement les règles de NAT en amont si tu souhaites ouvrir tes services sur Internet (non recommandé). Tu peux aussi y associer des règles de sécurité (liste blanche, authentification, …). Cela simplifie également énormément la mise en oeuvre du HTTPS car il te suffit d’avoir un certificat unique pour adresser tous tes services. Le renouvellement est aussi simplifié du coup.

Cela vise à ne permettre l’accès aux services qu’à travers le reverse Proxy, et non pas via le NAT intégré à docker. Pour cela il faut dans Nginx adresser directement les container et ne pas « reboucler » sur le host.

C’est le hostname du container.

→ Pour terminer je t’invite à utiliser Organizr pour simplifier l’utilisation de tous tes services avec une gestion par onglet. C’est vraiment pratique et cela permet de tout avoir à partir de la même page.

Gratz · Février 9, 2024, 8:37

mmmm j’ai testé et je n’ai pas réussi, du coup j’ai tout doublonné

Mais j’ai pas testé en mettant les noms des hostname, je testerai. Le domain name en haut, du coup je suppose qu’en suivant ton exemple je dois mettre « nas.local » ?

Enfin pour avoir accès à tous mes services, je trouve que Lunasea répond à mon besoin, et à terme j’espère pouvoir configurer correctement Overseer pour pas avoir à y aller (dans ces services). Pour l’instant, je me bats pour avoir un radarr aux ptits oignons (et c’est pas gagné, je suis les trash guides).

Prenons l’exemple que je viens de tester, bah je tombe sur un 502 en tapant sonarr.nas.local

Le container s’appelle bien sonarr
Dans le Pi Hole, j’ai juste mis un « nas.local » qui pointe vers l’IP du NAS

Je n’ai pas mis de « cname records » par contre… mais du coup, si je dois en spécifier ici, je vois pas la plus value par rapport à les mettre direct dans les local DNS ?

pr7 · Février 9, 2024, 11:31

My bad, je ne me souvenais plus du truc.
J’ai suivi ce paramétrage dnsmasq.
Je ne sais pas si tu peux le faire passer dans un fichier de conf du container par contre (je suis sur un raspberry perso).

Gratz · Février 10, 2024, 9:52

Mouais, ça me paraît bien complexe alors que les doublonner des deux côtés fonctionne. Mais merci des infos !

pr7 · Février 10, 2024, 5:03

En cherchant sur le doc de Docker, le réseau bridge par défaut ne semble pas faire de la résolution de nom. Ils recommandent de créer un réseau dédié.

Gratz · Février 21, 2024, 8:28

Bon, j’ai essayé de jouer avec un VPN. Vu que je n’ai jamais fait ça, j’ai creusé pendant une petite heure et force est de constater que je ne m’en sors pas, j’aurais donc besoin d’un coup de main explicatif.

Je pense qu’il y a deux buts ici, qui sont distincts (corrigez-moi si je me trompe) :

Accéder au NAS depuis des devices certifiés (genre, mon smartphone)
Permettre à un client type Deluge / Transmission de fonctionner.

Pour le premier point, j’ai donc tenté d’activer Wireguard sur l’appli dédiée du NAS, à savoir QVPN Service 3. Je lui ai donné un ptit nom, les clés privées / public qui vont bien, changé le port par défaut, mis un serveur DNS Cloudflare (doit-on mettre ici le DNS du Pi-Hole ?)… Et vient ensuite l’adresse IP (que je ne peux pas modifier) : à quoi correspond elle in fine ?

Ensuite, les pairs : j’imagine que je dois mettre, sur le NAS, les devices « certifiés » en collant la clé publique du NAS dans le client du device ? Et inversement, sur le device, ajouter le pair « NAS » avec sa clé publique ?

Pour le second point, je vais déjà essayer d’aller au bout du premier pour ensuite jouer avec le second.

Merci

Ylrahc · Février 21, 2024, 11:58

Autant le 1er point est vrai, autant le 2ème point généralement tu utilises un client VPN pour te connecter à un serveur VPN dans un pays distant un peu moins regardant sur les pratiques de partage de fichiers en torrent.

Là en effet ton serveur VPN va permettre à des clients, quels qu’ils soient pourvu qu’ils soit appairés avec le serveur, de dialoguer avec celui-ci au travers d’un flux entièrement chiffré. L’autre intérêt est que les clients auront l’impression d’être sur le même sous-réseau que celui du serveur VPN chez toi donc pourront accéder aux divers services de ton réseau privé. (VPN à la base ça veut dire réseau privé virtuel).
Faut voir un VPN comme un gros tuyau (symétrique) dans lequel tu envoies des trucs d’un coté et ça ressort de l’autre sans que personne puisse voir à l’intérieur, comme si un câble réseau ethernet reliait les deux devices connectés en fait.

L’adresse IP est je suppose l’IP « publique » sur laquelle les clients vont taper pour se connecter au VPN. Le trafic venant des clients sera ensuite redirigé sur le réseau privé (pas sûr de ça, y autre chose en 198.X.Y.Z sur ton réseau ? en gros un serveur VPN utilise deux IPs, l’IP WAN qui lui sert à communiquer avec les autres serveurs VPNs avec qui il souhaite monter des tunnels, et une IP LAN qui lui sert à transmettre le trafic arrivant sur le réseau privé)
Pour l’appairage soit t’as une clef symétrique que tu mets de chaque coté, et client et serveur dialoguent avec cette clef symétrique pour mettre en place le chiffrement asymétrique en s’échangeant leurs clefs publiques, ce qui n’a pas l’air d’être le cas ici, soit les deux cotés du tunnel VPN s’échangent directement leurs clefs publiques et les utilisent pour chiffrer le trafic.

Ah, et configurer un serveur VPN et appairer les clients, c’est toujours la merde. Bon courage (et lis la doc de wireguard )

Edit : pour le point 2 je crois comprendre, c’est possiblement utile si tu as un client torrent derrière du double NAT qui le rend plus ou moins inaccessible aux clients torrent hors de ton réseau privé qui chercheraient à le joindre. Dans ce cas tu fais passer le trafic du client torrent dans un VPN qui lui offre une IP « publique », mais ça me parait pas vraiment ce que tu essaies de faire ici.

Edit 2 : j’ai trouvé ça qui explique le concept de Wireguard :

avec les points clefs qui répondent à tes questions (et je racontais donc probablement de la merde sur l’IP, c’est celle sur le réseau privé virtuel que tu crées avec ton serveur Wireguard) :

Each device on the virtual network has a unique “Private/Public Key Pair” (this is how WireGuard verifies identity, like SSH)
Each device on the virtual network has its own “Virtual Interface”, with its own unique IP address
Addresses are not assigned via DHCP. You must configure each interface to have its unique static IP address on the virtual network that you are creating (10.0.0.3/24 for example)
Each client must have their public key added to the server’s configuration file (this is you authorizing who is allowed to be on the virtual network)

pr7 · Février 22, 2024, 6:57

Pour cela le plus simple (de loin) c’est d’utiliser un container avec un client OpenVPN intégré. L’image la plus connue est celle-ci. Il faut l’abonnement VPN également par contre.
Il faut jeter un oeil à leur documentation pour tout paramétrer correctement.
C’est un peu plus compliqué qu’une image Transmission standard.

mono · Février 22, 2024, 8:29

Elle est connue car elle fonctionne très bien depuis une belle paire d’années

Gratz · Février 29, 2024, 10:36

J’ai pas encore pris le temps de tout regarder, mais j’ai une question : quand mon NAS est KO, le DNS est KO, comment il fallback ? Parce que mon PC il considère que le DNS il n’arrive pas à le joindre et de fait, j’ai plus de réseau… J’ai mis un Secondary DNS sur 1.1.1.1 mais j’ai pas l’impression que ça suffit ?