Aller au contenu

Messages recommandés

Posté(e)

Bonjour,

Tout d'abord, si un post similaire existe ailleurs ou si j'ai mal posté mon sujet, toutes mes excuses.

Je possède un DS916+ depuis plusieurs années. J'avais configuré le reverse proxy pour une série d'application et ces dernières étaient donc accessibles via le réseau interne et internet sur des adresses de type https://<nom application>.<nom de domaine>

J'ai migré à DSM 7 il y a quelques semaines et j'ai reconfiguré le reverse proxy via la nouvelle méthode intégrée à DSM7 et tout fonctionnait.

Il y a quelques jours, j'ai voulu en ajouter une nouvelle et en testant je me suis rendu compte qu'aucune de mes applications n'étaient plus accessibles depuis mon réseau interne sur https://<nom application>.<nom de domaine>. Elles sont toujours accessibles en utilisant l'adresse ip + port et lorsque je suis connecté à internet hors de chez moi, les adresses https://<nom application>.<nom de domaine> fonctionnent bien.

Cela fait plusieurs jours que je tourne en rond en cherchant une solution, mais je n'en trouve pas...

Si quelqu'un a une piste (ou mieux, une solution...) je suis preneur!

Merci d'avance!

Posté(e)
il y a une heure, faluorn a dit :

Je possède un DS916+ depuis plusieurs années. J'avais configuré le reverse proxy pour une série d'application et ces dernières étaient donc accessibles via le réseau interne et internet sur des adresses de type https://<nom application>.<nom de domaine>

J'ai migré à DSM 7 il y a quelques semaines et j'ai reconfiguré le reverse proxy via la nouvelle méthode intégrée à DSM7 et tout fonctionnait.

Rien n'a changé entre DSM 6 et 7 concernant le proxy inversé, à quoi fais-tu référence ? à l'ancienne méthode du temps de DSM 5 pour avoir un proxy inversé Nginx ?

il y a une heure, faluorn a dit :

Il y a quelques jours, j'ai voulu en ajouter une nouvelle et en testant je me suis rendu compte qu'aucune de mes applications n'étaient plus accessibles depuis mon réseau interne sur https://<nom application>.<nom de domaine>.

Localement, il faut avoir un routeur/box qui fasse du loopback pour que ça fonctionne en local sans configuration additionnelle. Si ce n'est pas le cas, il faut passer par (mieux) un serveur DNS local qui définit localement les adresses pour chaque ndd ou (moins bien) ajouter des entrées dans le fichier hosts de tes périphériques (valables uniquement pour les périphériques qui le permettent du coup).

Posté(e)
Il y a 3 heures, .Shad. a dit :

Rien n'a changé entre DSM 6 et 7 concernant le proxy inversé, à quoi fais-tu référence ? à l'ancienne méthode du temps de DSM 5 pour avoir un proxy inversé Nginx ?

Je parle de cette "nouvelle" méthode-ci :

image.png.e1843a3608285a3ee19432333520b77b.png

Il y a 3 heures, .Shad. a dit :

Localement, il faut avoir un routeur/box qui fasse du loopback pour que ça fonctionne en local sans configuration additionnelle. Si ce n'est pas le cas, il faut passer par (mieux) un serveur DNS local qui définit localement les adresses pour chaque ndd ou (moins bien) ajouter des entrées dans le fichier hosts de tes périphériques (valables uniquement pour les périphériques qui le permettent du coup).

Tout fonctionnait au niveau de mon routeur. J'arrivais bien, depuis mon réseau local, à contacter mes applications sur https://<nom application>.<nom de domaine>.

Je viens de faire un test : un activant un VPN, j'arrive de nouveau à contacter mes applications sur https://<nom application>.<nom de domaine> mais une fois mon VPN coupé, les applications ne sont de nouveau plus joignables.

A votre avis, l'erreur vient plutôt de mon routeur ou d'une configuration quelconque dans le NAS?

Merci pour la réponse en tous cas @.Shad.

Posté(e)

@oracle7

J'ai un routeur AC1200 de TPLink, firmware 3.13.34, qui gère tout mon réseau interne.

Mon réseau externe est géré par un modem de Proximus (je suis en Belgique), une B-Box 3, à laquelle je n'ai pas accès pour le moment et donc je ne sais pas quelle est son firmware. Les ports 80 et 443 sont ouverts et forwardés vers mon routeur qui lui-même les forwarde vers mon NAS.

Tout fonctionnait jusqu'à il y a quelques semaines et je n'ai rien touché au niveau de mon routeur/modem, juste fait la migration vers DSM 7. Et même là, cela a continué de fonctionner quelques jours avant de s'arrêter... 😕

Posté(e) (modifié)
il y a 56 minutes, faluorn a dit :

Je parle de cette "nouvelle" méthode-ci :

Ca existait déjà, c'est juste qu'il n'y avait pas d'images mais une liste d'applications.

il y a 56 minutes, faluorn a dit :

Je viens de faire un test : un activant un VPN, j'arrive de nouveau à contacter mes applications sur https://<nom application>.<nom de domaine> mais une fois mon VPN coupé, les applications ne sont de nouveau plus joignables.

Probablement parce que lorsque le VPN est connecté, la requête passe du côté publique.
Que donnent en SSH sur le NAS :

nslookup www.google.fr
nslookup nomdelapp.ndd
Modifié par .Shad.
Posté(e) (modifié)

@faluorn

Bonjour,

Il y a 4 heures, faluorn a dit :

Les ports 80 et 443 sont ouverts et forwardés vers mon routeur qui lui-même les forwarde vers mon NAS.

Sauf erreur de ma part, il semble bien que c'est l'inverse qu'il faut faire car actuellement ces ports ne semblent pas ouverts sur ton NAS. Donc, ceci pourrait expliquer cela. D'ailleurs peux-tu STP nous montrer une copie d'écran des tes règles de pare-feu ?

A mon humble avis, il te faut sur la box transférer les ports 80 et 443 et sur le NAS ouvrir/autoriser ces même ports dans le pare-feu du NAS.

Cordialement

oracle7😉

Modifié par oracle7
Posté(e)

Bonjour,

Merci beaucoup pour vos réponses rapides et désolé d'avoir mis du temps à répondre.

Je vais essayer de structurer ma réponse et d'être le plus précis possible.

  • Mon réseau :
    • Modem fourni par mon FAI auquel je n'ai que peu d'accès. Les ports 80, 43 et 443 sont ouverts
    • Mon routeur interne, que je peux gérer comme je veux. Les ports 80, 43 et 443 sont redirigés vers mon NAS (avec réservation d'adresse IP)
  • Mon NAS :
    • Firewall : les ports 80, 43 et 443 sont ouverts (mais je n'ai remarqué aucune différence en désactivant carrément le firewall)
    • Certificats : j'ai un certificat let's encrypt qui protège mes URL et est utilisé pour toutes mes applications
    • DNS : j'ai un nom de domaine enregistré auprès de synology. Le lien est opérationnel
    • DSM : version 7.0-41890
    • Reverse proxy :
      • j'ai installé et configuré plusieurs applications.
      • Soit des applications natives Synology (dschat, dscalendar,...)
      • soit des applications hébergées sur docker (grafana, homeassistant,...).
      • Toutes les applications sont configuré pour être contactable sur
        • http://<ip adresse>:<alias>
        • http://<ip adresse>:<port http>
        • https://<ip adresse>:<port https>
        • https://<nom application>.<nom de domaine>
        • J'ai coché la case "l'utilisation de HSTS force les navigateurs à utiliser une connexion sécurisée"
  • Les tests effectués
    • Sur mon desktop
      • Application de bureau :
        • https://<nom application>.<nom de domaine> : NOK
        • https://<ip adresse>:<port https> : OK
      • Firefox:
        • http://<ip adresse>:<alias> : OK
        • http://<ip adresse>:<port http> : OK
        • https://<ip adresse>:<port https> : OK
        • https://<nom application>.<nom de domaine> : NOK
        • http://<nom application>.<nom de domaine> : NOK
      • Google Chrome:
        • http://<ip adresse>:<alias> : OK
        • http://<ip adresse>:<port http> : OK
        • https://<ip adresse>:<port https> : OK
        • https://<nom application>.<nom de domaine> : OK
        • http://<nom application>.<nom de domaine> : OK => Bizarre de pouvoir me connecter en HTTP vu la case HSTS cochée, non?
    • Sur mon smartphone
      • Sur le wifi:
        • http://<ip adresse>:<alias> : OK
        • http://<ip adresse>:<port http> : OK
        • https://<ip adresse>:<port https> : OK
        • https://<nom application>.<nom de domaine> : NOK
        • http://<nom application>.<nom de domaine> : NOK
        • Application mobile DSChat sur https://<nom application>.<nom de domaine> : NOK
      • sur la 4G:
        • http://<ip adresse>:<alias> : OK
        • http://<ip adresse>:<port http> : OK
        • https://<ip adresse>:<port https> : OK
        • https://<nom application>.<nom de domaine> : OK
        • http://<nom application>.<nom de domaine> : OK => Bizarre de pouvoir me connecter en HTTP vu la case HSTS cochée, non?
        • Application mobile DSChat sur https://<nom application>.<nom de domaine> : OK

Tout fonctionnait il y a +- un mois. Il s'est passé deux évènements importants depuis :

  • Migration vers DSM7 : mais tout fonctionnait après
  • Panne d'électricité dans la maison alors que le NAS était allumé

Quelques jours après la panne, lorsque j'ai voulu ajouter deux nouvelles applications, je me suis rendu compte que les accès ne fonctionnaient plus. Pourtant, le NAS s'est rallumé correctement après la panne. J'ai fait un scan et redémarré pour être sur qu'il soit redémarré convenablement

Voilà, j'espère avoir été clair, concis et complet.

Je suis donc surpris qu'avec une même configuration, certaines choses fonctionnent mais pas toutes. Si quelqu'un a des idées, je suis preneur...

Merci d'avance!

Posté(e)

@faluorn

Bonjour,

  1. Astuce : Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait).

  2. Dans ton affaire, ce qui est bizarre, c'est que en local avec FF ton domaine ne passe pas alors qu'il passe avec Chrome et qu'il passe aussi lorsque tu es en externe (4G).
    Vérifies par ex que tu n'as pas dans FF un plugin du style "uBlock origin" ou "Adblock" qui filtrerait ton domaine. Si oui, alors mets ce domaine en liste blanche pour voir.

  3. Je remarque aussi une autre "bizarreté" : c'est l'ouverture du port 43 pour le protocole de recherche d'@IP ou de nom de domaine WHOIS. Comme WHOIS ne permet pas d'authentification, l'accès au serveur XHOIS est public. Cela peut poser des problèmes pour la protection de la vie privée des personnes ou, tout simplement, pour le secret commercial ou bien pour la protection contre le spam. Habituellement ce port n'est pas ouvert sur nos NAS car inutile à l'usage courrant. Je t'invite à supprimer le transfert de ce port sur ton NAS et à supprimer toutes règles d'ouvertures de ce port dans ta box et routeur.

  4.  

    il y a une heure, faluorn a dit :

    Bizarre de pouvoir me connecter en HTTP vu la case HSTS cochée, non

    Certainement parce que ton navigateur fait automatiquement la conversion http-->https et c'est transparent pour toi.

  5. Il y a 1 heure, faluorn a dit :

    Quelques jours après la panne, lorsque j'ai voulu ajouter deux nouvelles applications, je me suis rendu compte que les accès ne fonctionnaient plus.

    Avec le retour de courant ton modem a redémarré et a peut-être obtenu une nouvelle @IP externe sur laquelle ton domaine ne pointait peut-être plus. Du coup cela pourrait expliquer que tes accès via domaine ne fonctionnaient plus. Mais je peux me tromper ... Au fait, habituellement ton @IPexterne est-elle fixe ou dynamique ?
    Si dynamique, alors regardes du coté de ton DDNS qu'il fait bien pointer ton domaine sur ton @IPexterne ...

Cordialement

oracle7😉

Posté(e)

@oracle7

Merci pour ta réponse et tes conseils 🙂

il y a 33 minutes, oracle7 a dit :

Dans ton affaire, ce qui est bizarre, c'est que en local avec FF ton domaine ne passe pas alors qu'il passe avec Chrome et qu'il passe aussi lorsque tu es en externe (4G).
Vérifies par ex que tu n'as pas dans FF un plugin du style "uBlock origin" ou "Adblock" qui filtrerait ton domaine. Si oui, alors mets ce domaine en liste blanche pour voir

J'ai essayé et cela n'a pas changé. De plus, même l'application de bureau ds chat ne fonctionne pas avec l'adresse https://<application>.<nom de domaine>, ce qui n'a rien à voir avec une configuration dans FF.

il y a 34 minutes, oracle7 a dit :

Je remarque aussi une autre "bizarreté" : c'est l'ouverture du port 43 pour le protocole de recherche d'@IP ou de nom de domaine WHOIS. Comme WHOIS ne permet pas d'authentification, l'accès au serveur XHOIS est public. Cela peut poser des problèmes pour la protection de la vie privée des personnes ou, tout simplement, pour le secret commercial ou bien pour la protection contre le spam. Habituellement ce port n'est pas ouvert sur nos NAS car inutile à l'usage courrant. Je t'invite à supprimer le transfert de ce port sur ton NAS et à supprimer toutes règles d'ouvertures de ce port dans ta box et routeur.

Au temps pour moi : seul 443 et 80 sont ouverts et forwardés. Je ne sais pas pourquoi j'avais en tête le port 43...

il y a 35 minutes, oracle7 a dit :

Certainement parce que ton navigateur fait automatiquement la conversion http-->https et c'est transparent pour toi.

Peut-être oui. J'ai cependant quand même un petit panneau "attention" avec comme message : connexion non sécurisée. Mais c'est un soucis accessoire je pense.

 

il y a 36 minutes, oracle7 a dit :

Avec le retour de courant ton modem a redémarré et a peut-être obtenu une nouvelle @IP externe sur laquelle ton domaine ne pointait peut-être plus. Du coup cela pourrait expliquer que tes accès via domaine ne fonctionnaient plus. Mais je peux me tromper ... Au fait, habituellement ton @IPexterne est-elle fixe ou dynamique ?
Si dynamique, alors regardes du coté de ton DDNS qu'il fait bien pointer ton domaine sur ton @IPexterne ...

J'ai effectivement redémarré mon modem/routeur pour être sur que tout soit bien redémarré. Du côté de mon DDNS la connexion est bien établie. Le fait qu'avec un autre navigateur ou via la 4G mon domaine est accessible me fait penser que le soucis ne vient pas de là.

Si je n'avais l'erreur QUE sur FF via mon pc, je ferais un reset du profil ou désinstaller / réinstaller. Mais comme j'ai l'erreur également sur l'application de bureau et même via un navigateur sur mon smartphone, je me dis que l'erreur n'est pas liée à FF.

Merci,

 

Faluorn

Posté(e)

@faluorn

Bonjour,

Pour les applications DSxxxx depuis l'extérieur, il faut impérativement ajouter à l'URL le port 443, ce n'est pas nécessaire en local.

il y a 4 minutes, faluorn a dit :

J'ai cependant quand même un petit panneau "attention" avec comme message : connexion non sécurisée. Mais c'est un soucis accessoire je pense.

"Accessoire" : pas tant que cela mais normal si tu te connectes avec une @IP car ton certificat n'est pas défini pour elle donc ton navigateur te renvoies l'exception de sécurité.

Cordialement

oracle7😉

Posté(e)

@oracle7,

il y a 30 minutes, oracle7 a dit :

Pour les applications DSxxxx depuis l'extérieur, il faut impérativement ajouter à l'URL le port 443, ce n'est pas nécessaire en local.

Je viens de faire le test sur https://<application>.<nom de domaine>:443 et cela ne change rien.

Je viens encore une fois de parcourir la configuration de mon NAS et je ne vois vraiment pas quelle option changer/adapter pour corriger le soucis...

Faluorn

Posté(e) (modifié)

@faluorn

Bonjour, A titre d'exemple, quelle application tu n'arrives pas à joindre via le Reverse Proxy ? Tu peux faire STP une copie d'écran de la règle RP correspondante.

EDIT : une autre question : dans ton post initial tu dis que ton domaine est en Synology. Donc tes URL de connexion ont bien cette forme : " https://application.xxxxx.synology.me ", j'ai bon ?

EDIT 2 : dans réseau / Paramètres DSM tu es bien comme ceci ?

1gyyERy.png

Cordialement

oracle7😉

Modifié par oracle7
Posté(e) (modifié)

Bonjour,

@oracle7

Voici la liste des applications qui fonctionnent lorsque je passe par un VPN mais qui ne fonctionnent plus lorsque je suis en réseau local : calendar, contact, chat, audio, vidéo, photo, ...

Mes applications sont bien accessibles via https://<nom d'application>.XXX.synology.me, tu as tout à fait raison!

J'espère que l'image est assez grande / lisible

image.thumb.png.ab75179ee8ae684f0d0836f3d3869f18.png

Voici les détails lorsque j'en sélectionne une :

image.png.a4b317bb11e2bbe96d413d1fd1b8b857.png

Il y a 13 heures, oracle7 a dit :

EDIT 2 : dans réseau / Paramètres DSM tu es bien comme ceci ?

Je n'ai pas la même interface que toi visiblement...? Voici ce que je vois dans ce menu :

image.png.c101a98fcf4ace193101ce4ea951ea36.png

Comme tu vois, je n'ai rien en dessous de la partie "activer en-tête"...

Merci encore pour ton aide 🙂

Faluorn

 

 

 

image.png

Modifié par faluorn
Posté(e) (modifié)

@faluorn

Bonjour,

Bon cela ne va pas être facile car effectivement tu es sous DSM7 et je suis encore sous DSM6.x donc avec une interface différente. En plus si je ne dis pas de bêtises, certaines fonctions ont migrées dans d'autres écrans sous DSM7. Mais bon, on devrait quand même y arriver.

  1. Je vois que tu as modifié les ports par défaut pour certaines applications, de mon humble avis cela ne sert à rien du point de vue sécurité, car tu ne fais que retarder de quelques dizaines de secondes un malveillant qui scan tes ports.
    Ce qu'il faut soigner, ce sont les protections des accès. Mais rien ne t'empêche de le faire si tu penses que c'est bien. L'utilité est franchement discutable car si tu fais une commande "NMAP" sur ton IP publique, tu verras en quelques secondes tous les ports accessibles depuis chez le lieu de la commande, donc que DSM soit sur le port 5000 ou 57485, cela ne change rien. Une commande "CURL" renseignera également directement sur le contenu de la page renvoyée par ton @IP sur ce port. Donc aucun intérêt, mais ce n’est que mon avis …
     
  2. Pour configurer le Reverse Proxy, je te propose de faire autrement, et on va prendre comme exemple Audio Station, pour les autres applications, je pense que tu sera capable de transposer 😜
    a) Dans le portail des applications, tu accèdes à Audio Station avec un 2xClic.
    b) Là dans la partie "Services Web" tu gardes l'alias et tu ne renseignes que le N° de port HTTP, puis dans la partie "Domaine" tu effaces le champ "Domaine personnalisé"
    c) Ensuite tu vas dans Système / Portail connexion / Avancés / Reverse Proxy
    d) Tu crées une règle et lui donne un Nom par ex : Audio
    e) Pour la partie "Source" tu renseignes : protocole = HTTPS, Hôte = <alias>.xxxxx.synology.me, port = 443 --> <alias> = valeur donnée au point b) (tout en minuscules !!!), xxxxx est le nom que tu as donné pour ton domaine (DDNS).
    f) Tu coches HSTS (Attention avec ceci, ton navigateur Web t'interdira par la suite toutes URL en HTTP !, donc à faire en connaissance de cause).
    g) Pour la partie "Destination" tu renseignes (attention, c'est trompeur certains champs sont apparemment déjà renseignés, mais il n'en est rien, il faut quand même les saisir sinon rien n'est pris en compte !) : Protocole = HTTP, Hôte = localhost, port = N° de port HTTP celui saisi au point b).
    h) Ne pas oublier de valider.

    Remarques :
    -
    Si tu veux accéder à DSM via RP l'alias que tu utilisera devra être différent du nom donnée au NAS, sinon cela ne marchera pas, donc NomNAS = nasdetoto et alias = dsm ou = tartampion (en fait ce que tu veux mais pas = nasdetoto !)
    - Pour le "Protocole" de destination : il est inutile et improductif de faire du HTTPS d'autant plus que l'on est en local car cela reviendrait à crypter un flux qui l'est déjà, d'où des ralentissements.
    - Pour la valeur "localhost" de destination (qui correspond à l'IP locale de ton NAS), tu peux très bien indiquer à la place une @IP locale dans le cas où tu voudrais atteindre une autre machine (par ex chez moi j'ai des règles de RP pour atteindre la configuration de chacune de mes caméras de surveillance, j'ai donc mis l'IP locale 192.168.x.xx et le N° de port - 80 de chacune de mes caméras, j'en ai une aussi pour atteindre un RPI Jeedom pour la domotique).

    i) Enfin depuis l'extérieur tu te connectes avec un URL telle que : https://audio.xxxxxx.synology.me dans un navigateur Web ou si c'est avec DSAudio : https://audio.xxxxxx.synology.me:443 . En local, la première URL est suffisante.

Voilà, si tu suit bien ce processus cela devrait le faire.

Cordialement

oracle7😉

Modifié par oracle7
Posté(e)

@oracle7

Bonjour,

Oui, certaines interfaces ont changé avec DSM7.

il y a une heure, oracle7 a dit :

Je vois que tu as modifié les ports par défaut pour certaines applications

Je n'ai pas voulu changer les ports par défaut, il me semble avoir chaque fois utilisé le porte proposé. Si un port n'est pas celui par défaut, il s'agit d'une erreur de ma part et non une volonté réelle de changer le port. Si tu en as repéré un, indique moi le(s)quel(s) et j'irai adapter 🙂

il y a une heure, oracle7 a dit :

Pour configurer le Reverse Proxy, je te propose de faire autrement,

Tu voudrais que je fasse ceci en fait?

image.png.79f6c5818aa3051837c94277941e3280.png

Avant de passer à DSM7, toutes mes règles étaient définies comme cela. La DSM7 offre une nouvelle interface "simplifiée" pour les applications natives de Synology, que j'ai utilisée. J'ai donc remplacé les anciennes règles par les "nouvelles".

L'application que j'ai pris ici en exemple (homeassistant) n'est inaccessible ni sur https://application.xxx.synology.me ni sur https://application.xxx.synology.me:443 depuis mon réseau local. De même, l'application sur mon smartphone en wifi n'est pas accessible. Une fois que je passe sur la 4g, tout fonctionne bien...

Je suis donc vraiment perplexe sur ce qui cause un soucis.

Je vais tenter de reconfigurer une des applications native synology avec "l'ancienne" méthode, que tu renseignes, pour voir si le comportement change.

Encore merci pour ton aide!

Faluorn

Posté(e)

@faluorn

Bonjour,

Comme je te l'ai dit, je suis sous DSM6.x donc je ne connais pas encore la nouvelle méthode que tu évoques, donc difficile de t'en dire plus sur elle. Par contre l'ancienne méthode, elle je suis certain qu'elle marche. Alors ...

Pour les ports par défauts, regardes ce lien.

Pour l'accès local inaccessible, je crains maintenant, mais je peux me tromper, que la cause soit ta box qui n'accepterait pas le lookback. Du coup, la solution serait que tu installes le package DNS Server (voir TUTO) et que tu configures une zone DNS local et là tu ne devrais plus avoir de soucis. Rassures-toi, il n'y a rien de très compliqué pour DNS Server.

Cordialement

oracle7😉

Posté(e)

Bonjour bonjour,

Désolé d'avoir tardé à répondre, j'ai pris le tmeps de faire quelques tests.

@oracle7 je reviens sur ta remarque sur les ports. Merci pour le lien. Je vois que presque toutes les applications "natives" Synology (note, calendar, contact, audio,...) utilisent le port 5000 en HTTP et 5001 en HTTPS.

Ceci dit, quand je vais sur le firewall pour autoriser des applications, voici les ports mentionnés :

image.png.6f90d05056f3315d88efc1ce5a3dd526.png

Est-ce que quelque chose aurait changé entre DSM6 et DSM7 à ce niveau-là?

De même, quand je vais dans la section reverse proxy et, ces applications "natives" apparaissent dans la liste même si le RP n'est pas configuré :

image.png.c1ce37bdfacc9afb1668a4b5a89f3cd2.png

Lorsqu'on ouvre l'application non configurée, voici ce qu'on voit :

image.png.841c34303c0a931db19745095b4c4cab.png

Les ports conseillés sont donc différents de ceux renseignés sur la page dont tu m'as donné le lien.

 

Il y a 23 heures, oracle7 a dit :

Pour l'accès local inaccessible, je crains maintenant, mais je peux me tromper, que la cause soit ta box qui n'accepterait pas le lookback. Du coup, la solution serait que tu installes le package DNS Server

J'ai en effet fait le test et cela n'a malheureusement rien changé.

 

J'ai également fait le test de supprimer la configuration RP que j'avais pour refaire une configuration "version DSM 6"

image.png.c12aa0b21f2acd34e750dec5bbdd7df1.png

Cela ne change pas mon soucis : mon URL n'est pas accessible via FireFox mais bien via Google Chrome, bien que assez lent.

Remarque : pour que cela fonctionne avec cette configuration-là, j'ai bien du indiquer le port 5000 et pas le port 9350 comme indiqué dans le FireWall ou dans la "nouvelle" méthode de proxy.

 

Voilà, je pense avoir effectué tous les tests proposés et malheureusement mon soucis reste le même : en wifi/réseau local, je ne peux atteindre mes URL de type https://application.XXX.synology.me ni via firefox, ni via les applications de bureau ni via mon smartphone ni via les applications mobiles. Par contre, via Google Chrome, j'arrive bel et bien à atteindre ces URL. En passant par un VPN ou via la 4 G, ces URL sont bien joignables via FireFox et les applications mobiles / de bureau.

Encore merci à toi @oracle7 pour ton aide en tous cas 🙂

Faluorn

image.png

image.png

Posté(e)

@faluorn

Bonjour,

Pour la problématique des ports , j'ai aussi fait le même constat, donc il semblerait maintenant que même si des ports spécifiques apparaissent dans l'interface qu'il faille passer "majoritairement" (au sens applications/services) par les ports 5000/5001. Encore une bizarrerie de Synology 🤪

C'est quand même bizarre qu'en local, le RP ne fonctionne pas même avec DNS Server d'installé. A tout hasard as-tu essayé avec le navigateur Edge de Microsoft ou d'autres navigateurs tiers ?

Toujours au stade des bizarreries, as-tu redémarré ton NAS depuis longtemps ? Si oui, essaies toujours pour voir ? Sinon encore une solution un peu plus radicale pour réinitialiser le réseau du NAS c'est lui faire un reset mode 1 (lis bien les remarques sur les conséquences associées).

Voilà des pistes à explorer, elles valent ce quelles valent mais pourraient débloquer la situation de ce réseau local sachant que là, tu as quasiment vidé mon magasin à idées 😜

Cordialement

oracle7😉

Posté(e) (modifié)

@oracle7

Bonjour,

Encore merci pour toute ton aide et tes conseils.

J'ai tout retesté ce matin et j'ai rempli le tableau, pour avoir une meilleure vue d'ensemble (j'espère que c'est lisible sur le forum...)

image.thumb.png.fcad1d6942591b9848861b77298faec3.png

Après avoir lu ton post, j'ai redémarré mon NAS (uptime de 15 jours) et après redémarrage, la situation est pire puisque plus aucune page accessible auparavant via Chrome n'est encore accessible.

Cependant, j'ai UNE seule URL accessible via FireFox : celle pour les contacts. L'URL pour dsfile, qui est configurée de la même manière, n'est pas accessible par contre.

J'ai trois applications tournant sur docker mais une seule est accessible, la seule pour laquelle je n'ai rien autorisé via le firewall du NAS.

EDIT : après avoir désactivé les règles firewall liées à bitwarden et grafana, les pages ne sont pas redevenues accessibles...

J'avoue que plus je cherche, moins je comprends et plus je m'arrache les cheveux...

Il y a 21 heures, oracle7 a dit :

tu as quasiment vidé mon magasin à idées

Il contenait plus d'idées que le mien déjà 🙂

Encore merci en tous cas et je reste preneur de toute idée à tester!

Faluorn

Modifié par faluorn

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.