Swag ou Nginx Proxy Manager sont-ils plus puissants que le reverse-proxy de DSM ?

[CyberFr]

Bonjour,

J'ai échoué à mettre en œuvre le tuto sur Swag à cause d'un sombre problème de certificats SSL qu'il installe lors du premier lancement mais ne trouve plus par la suite. Je me rabats donc sur Nginx Proxy Manager.

La question que je me pose est toute simple. Des solutions comme celles que j'ai citées apportent-elles un vrai plus par rapport à DNS Server que j'utilise par

ailleurs ?

Modifié hier à 10:21 par CyberFr

[PiwiLAbruti]

Un proxy inversé et un serveur DNS n'ont pas du tout le même rôle, s'ils sont complémentaires. Donc il n'y a pas de comparaison à faire entre les deux.

Pourquoi ne pas utiliser le proxy inversé intégré à DSM ? (Panneau de configuration > Portail de connexion)

[CyberFr]

il y a 24 minutes, PiwiLAbruti a dit :

Pourquoi ne pas utiliser le proxy inversé intégré à DSM ? (Panneau de configuration > Portail de connexion)

C'est ce que je fais en complément de DNS Server. Mais effectivement j'ai mélangé reverse-proxy et serveur DNS parce que je considérais à tort qu'ils étaient imbriqués. Lorsque je crée une nouvelle entrée dans le reverse-proxy (HTTPS calendar.ndd.fr --> localhost:port), celle-ci doit être traitée dans DNS Server (calendar.ndd.fr --> ns.ndd.fr) d'où ma confusion. Je reformule donc la question en tenant compte de mon erreur : des outils comme Swag ou Nginx Proxy Manager apportent-ils un plus par rapport au proxy inversé de DSM ? Le fait que DNS Server ne serve plus à rien est-il un recul ?

Modifié hier à 12:04 par CyberFr
Le coup est parti trop vite en cours de rédaction

[Mic13710]

il y a 15 minutes, CyberFr a dit :

Le fait que DNS Server ne serve plus à rien est-il un recul ?

Je ne vois pas en quoi le serveur DNS ne servirait plus. Certes, il y a le portail de connexion qui permet à présent de faire la même chose que le reverse proxy pour les applications intégrées, mais il reste encore tous les services externes au NAS qui peuvent être associés à des ndd dans le reverse proxy. Par exemple d'autres NAS, la domotique, pihole, la box, un routeur externe, ... Bref, il reste encore de quoi largement justifier le reverse proxy

[CyberFr]

il y a 39 minutes, Mic13710 a dit :

Je ne vois pas en quoi le serveur DNS ne servirait plus.

Je sous-entendais que DNS Server ne servirait plus à rien en cas d'utilisation de Swag ou de Nginx Proxy Manager. Parce que ces derniers écoutent sur le port 443 des requêtes du type https://calendar.ndd.fr qu'ils transforment en http://localhost:port. À quoi servirait alors DNS Server ?

 

il y a 41 minutes, Mic13710 a dit :

Certes, il y a le portail de connexion qui permet à présent de faire la même chose que le reverse proxy pour les applications intégrées, mais il reste encore tous les services externes au NAS

Actuellement, chez moi, DNS Server est couplé au portail de connexion. J'utilise les deux. Et je n'utilise pas le portail de connexion uniquement pour les applications intégrées. J'utilise systématiquement un reverse-proxy. J'ai toujours une entrée définie dans le certificat Let's Encrypt, par exemple calendar.ndd.fr. Pour être clair je n'utilise jamais la partie "Applications" du Portail de connexion mais systématiquement la partie "Avancé" dans laquelle je définis les proxys inversés..

[PiwiLAbruti]

il y a une heure, CyberFr a dit :

Je sous-entendais que DNS Server ne servirait plus à rien en cas d'utilisation de Swag ou de Nginx Proxy Manager. Parce que ces derniers écoutent sur le port 443 des requêtes du type https://calendar.ndd.fr qu'ils transforment en http://localhost:port. À quoi servirait alors DNS Server ?

Dans ce cas qui, qui va résoudre calendar.ndd.fr ? Tu mélanges proxy inversé et résolution DNS.

il y a une heure, CyberFr a dit :

Pour être clair je n'utilise jamais la partie "Applications" du Portail de connexion mais systématiquement la partie "Avancé" dans laquelle je définis les proxys inversés.

Peu importe, les deux font la même chose (proxy inversé). C'est juste que l'interface Applications est plus intuitive pour les novices.

[CyberFr]

il y a 59 minutes, PiwiLAbruti a dit :

Dans ce cas qui, qui va résoudre calendar.ndd.fr ? Tu mélanges proxy inversé et résolution DNS.

Errare humanum est, perseverare diabolicum. Tu as sans doute raison mais comment tout cela s'articule ? Quel est le chemin suivi entre la requête initiale et sa résolution qui fait intervenir à la fois la résolution DNS et le proxy inversé ? L'un et l'autre se trouvent où dans le chemin ?

il y a une heure, PiwiLAbruti a dit :

Peu importe, les deux font la même chose (proxy inversé). C'est juste que l'interface Applications est plus intuitive pour les novices.

J'utilise systématiquement un proxy inversé pour les applications Synology et les autres ce qui m'évite de me compliquer la vie quand la situation évolue parce que j'applique toujours la même démarche.

[PiwiLAbruti]

Lorsqu'une URL est entrée dans la barre d'adresse d'un navigateur, ce dernier a d'abord besoin de connaître l'adresse IP de la destination. C'est le rôle du résolveur DNS qui va retourner l'adresse IP vers laquelle pointe le nom de domaine renseigné dans l'URL, et c'est la seule chose qui est demandée au serveur DNS. L'enregistrement DNS correspondant doit donc nécessairement être (ou pointer vers) un enregistrement de type A (IPv4) et/ou AAAA (IPv6), peu importe les alias CNAME utilisés en amont.

• CNAME calendar.ndd.fr -> A ns.ndd.fr -> adresse IPv4

Le navigateur peut maintenant contacter l'adresse IP retournée par le serveur DNS pour communiquer avec la destination.

Jusqu'ici, il n'est toujours pas question du proxy inversé. Le serveur DNS a donc un rôle complètement dissocié. Mais sans lui, impossible de savoir qui contacter.

────────────────────────────────

Une fois connecté à sa destination sur le port tcp/443 (HTTPS), le navigateur va envoyer une requête HTTP dont les en-têtes contiennent un champ Host avec comme valeur le nom de domaine de l'URL (Host: calendar.ndd.fr). C'est la valeur de ce champ qui permet au proxy inversé de diriger le trafic vers la destination finale (calendar.ndd.fr -> localhost:port).

 

N'hésite pas à demander si certains points sont mal expliqués, c'est le b.a.-ba pour comprendre comment ça fonctionne.

[CyberFr]

il y a 27 minutes, PiwiLAbruti a dit :

Une fois connecté à sa destination sur le port tcp/443 (HTTPS), le navigateur va envoyer une requête HTTP dont les en-têtes contiennent un champ Host avec comme valeur le nom de domaine de l'URL (Host: calendar.ndd.fr). C'est la valeur de ce champ qui permet au proxy inversé de diriger le trafic vers la destination finale (calendar.ndd.fr -> localhost:port).

Merci pour ce rappel salutaire parce que je ne comprenais pas comment, en aval du serveur DNS,  les en-têtes pouvaient être transmis 👍

Ce qui m'a troublé, c'est que les applications dont il est question dans le titre font à la fois serveur DNS et reverse-proxy. Je dis ça parce qu'elles attendent sur le port 443 une requête du type calendar.ndd.fr et qu'elles la redirige correctement. À tel point, si j'ai bien compris, que le port 443 ne doit plus être redirigé par le routeur ou la box internet vers le port local du NAS mais vers leur propre port local. Ce qui veut dire que le serveur DNS de DSM est court-circuité sauf s'il est possible de créer des exceptions au niveau de ces applications.

[Mic13710]

il y a 38 minutes, CyberFr a dit :

le serveur DNS de DSM est court-circuité

tout d'abord le serveur dns n'utilise pas le 443 mais le 53. ensuite, la vocation du serveur dns du NAS (s'il est bien paramétré selon le tuto) est de résoudre des ndd locaux sinon ça ne pourrait pas fonctionner, sauf si le routeur est capable de faire du loopback. Le serveur dns local n'intervient pas sur des requêtes externes.

 

il y a 38 minutes, CyberFr a dit :

À tel point, si j'ai bien compris, que le port 443 ne doit plus être redirigé par le routeur ou la box internet vers le port local du NAS mais vers leur propre port local.

Si tu utilises un reverse proxy autre que celui du NAS, il est bien évident que c'est vers celui-ci qu'il faut diriger les requêtes qui arrivent par le 443 pour qu'elles soient orientées vers les services appelés. Peu importe finalement quel équipement assure le reverse proxy, c'est vers lui qu'il faut diriger le 443.

[PiwiLAbruti]

il y a 27 minutes, CyberFr a dit :

Ce qui m'a troublé, c'est que les applications dont il est question dans le titre font à la fois serveur DNS et reverse-proxy.

Les applications citées sont des proxy inversés. Elles n'ont pas le rôle de serveur DNS car elles n'écoutent pas sur le port udp/53 (DNS).

À aucun moment le serveur DNS n'est court-circuité.

Le fait de changer d'application de proxy inversé ne change rien aux résolutions DNS, ce sont deux choses distinctes.

[CyberFr]

il y a 17 minutes, Mic13710 a dit :

tout d'abord le serveur dns n'utilise pas le 443 mais le 53. ensuite, la vocation du serveur dns du NAS (s'il est bien paramétré selon le tuto) est de résoudre des ndd locaux

C'est bien pour cela que je l'utilise en effet.

il y a 5 minutes, PiwiLAbruti a dit :

Le fait de changer d'application de proxy inversé ne change rien aux résolutions DNS, ce sont deux choses distinctes.

Suite à ma réflexion sur Swag et Nginx Proxy Manager, j'ai régressé parce que, lorsque il y a plusieurs années, j'ai mis en place DNS Server, les choses étaient claires. Je reçois donc une piqure de rappel qui les clarifie à nouveau. Merci.

Mais la question initiale (j'ai modifié le titre en conséquence) reste en suspens. Est-ce que ça vaut la peine de basculer du reverse-proxy intégré de DSM vers Nginx Proxy Manager ? Y gagne-t-on quelque chose ?

[PiwiLAbruti]

Désolé mais je vais répondre par une question : Pourquoi veux-tu mettre en place un autre proxy inversé que celui du NAS ? (Quel est le besoin ?)

[CyberFr]

il y a 4 minutes, PiwiLAbruti a dit :

Pourquoi veux-tu mettre en place un autre proxy inversé que celui du NAS ? (Quel est le besoin ?)

Préparer mon passage chez UGREEN car je ne sais pas s'ils disposent d'un proxy inversé 😀

[PiwiLAbruti]

UGOS, l'OS des NAS UGreen, ne propose pas (encore) de proxy inversé.

Je pense qu'il est urgent d'attendre que cet OS mûrisse (et que les alternatives fassent leurs preuves) avant de changer de crèmerie.

En tout cas, un proxy inversé dans un conteneur devrait largement faire l'affaire.

[CyberFr]

Il y a deux choses que j'ai mise en œuvre dans DSM et que je souhaite retrouver dans tout nouvel environnement : DNS Server et le proxy inversé de DSM. Parce que pour les autres applications j'utilise déjà des solutions alternatives, pour Docker par exemple j'utilise Portainer. Et je remplacerais volontiers L2TP/IPSec qui n'est pas compatible IPV6 par Wiregerd.  OpenVPN ne passe pas sur Mac, je l'avais installé mais il m'a été impossible de le réinstaller avec les mêmes fichiers de config ! Un bug de macOS sans doute.

[cadkey]

Il y a 5 heures, Mic13710 a dit :

la vocation du serveur dns du NAS (s'il est bien paramétré selon le tuto) est de résoudre des ndd locaux sinon ça ne pourrait pas fonctionner, sauf si le routeur est capable de faire du loopback

J'ai un RT6600 ax Synology qui est sensé faire du loopback. Pourtant mes NDD locaux ne sont pas toujours résolu correctement, je ne comprends pas pourquoi. Y-a-t-il un paramétrage à faire dans le RT6600 pour activer le loopback?

[PiwiLAbruti]

il y a 11 minutes, cadkey a dit :

[…] mes NDD locaux ne sont pas toujours résolu correctement, […]

C'est-à-dire ? Tu utilises DNS Server avec une zone locale ? Quel(s) serveur(s ) DNS sont paramétrés sur les clients ?

[Mic13710]

@cadkey désolé, je ne connais pas les routeurs Syno. Néanmoins, je vous conseille fortement de mettre à profit le serveur DNS du NAS, ce sera toujours plus efficace à la fois en terme de logique que d'utilisation de ressource que de passer par le loopback. Qui dit loopback dit sollicitation du CPU du routeur pour rediriger les requêtes du LAN vers le LAN. Le serveur DNS lui gérera les requêtes en local sans aucune intervention du routeur.

@CyberFr UGreen comme son nom l'indique est encore trop vert pour espérer en tirer partie comme ce qu'offre un synology. Il faut le laisser encore mûrir.

[CyberFr]

il y a 9 minutes, Mic13710 a dit :

@CyberFr UGreen comme son nom l'indique est encore trop vert pour espérer en tirer partie comme ce qu'offre un synology. Il faut le laisser encore mûrir.

J'en suis tout à fait conscient et d'ailleurs @PiwiLAbruti avait déjà attiré mon attention sur ce point. Je ne suis pas mûr pour changer de crémerie mais, comme beaucoup d'autres utilisateurs de la marque, ma vision a changé et ce fût brutal.