.Shad. Posté(e) le 20 août 2019 Partager Posté(e) le 20 août 2019 Tant mieux si ça vous débloque ! Je ne pourrais pas t'en dire plus au sujet des websockets, je sais en revanche que j'ai dû parfois ajouter des headers personnalisés pour faire fonctionner certaines redirections. Et sur ce point très difficile de trouver des infos pour le proxy inversé de DSM contrairement à HAProxy ou Nginx. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Stejo Posté(e) le 20 août 2019 Partager Posté(e) le 20 août 2019 Effectivement, ça refonctionne chez moi, nickel..Merci bien Thierry94 pour le gros coup de pouce. Merci aussi à toi Shadowking pour l info. Envoyé de mon téléphone en utilisant Tapatalk 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
PiwiLAbruti Posté(e) le 21 août 2019 Partager Posté(e) le 21 août 2019 Il y a 17 heures, Thierry94 a dit : Question aux connaisseurs : a quoi correspond cette entête personnaliée ? N’utilisant pas (encore) la vidéo-surveillance, j’étais passé à côté de ce souci avec DS cam. Pour que les WebSockets fonctionnent sur un proxy inversé, il est impératif de déclarer explicitement les en-têtes nécessaires à l’établissement de la connexion. La solution trouvée est très intéressante car elle montre que Synology a ENFIN compris que les WebSockets sont beaucoup plus efficaces pour le transport de flux continus que HTTP. Je leur avais déjà adressé une demande d’evolution dans ce sens il y a 3 ans pour DSM où le polling HTTP plombe les performances des NAS (tout ce qui concerne la télémétrie comme le Moniteur de ressources, et toutes les actions de polling intensives). L’impact de l’utilisation des WebSockets dans DSM serait très bénéfique sur les performances, et particulièrement sur les modèles d’entrée de gamme. On verra ce que ça donnera avec DSM 7 (même si je n’y crois pas vraiment). 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Thierry94 Posté(e) le 21 août 2019 Auteur Partager Posté(e) le 21 août 2019 (modifié) Je ne connais rien aux websockets mais j'ai vu que sa mise en place dans le reverse proxy générait une ligne "$http_upgrade" Ma question de néophyte : cela ne remet pas en cause la liaison https sur le port 443 entre l'équipement sur internet et le du reverse proxy du NAS ? Modifié le 21 août 2019 par Thierry94 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
PiwiLAbruti Posté(e) le 21 août 2019 Partager Posté(e) le 21 août 2019 Non, ça n’en pose aucun problème. Si le client ne demande pas un WebSocket, l’en-tête est ignorée. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Thierry94 Posté(e) le 21 août 2019 Auteur Partager Posté(e) le 21 août 2019 Si je te comprend bien cela veut dire que quand le client demande un websocket on passe alors en http ? Dans notre cas le client est DScam, et visiblement il demande le websocket puisque sans l'entête personnalisée ça ne marche pas. Alors problème ou pas avec le https du reverse proxy .. autrement dit à l'ouverture de l'appli lorsque le login et le mot de passe sont saisis il ne circuleront pas en clair sur le réseau ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
PiwiLAbruti Posté(e) le 21 août 2019 Partager Posté(e) le 21 août 2019 WebSocket utilise le même chiffrement que la connexion HTTP avec laquelle il a été initialisé. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sando77 Posté(e) le 28 août 2023 Partager Posté(e) le 28 août 2023 Bonjour, Suite à investigation avec le support synology, il suffit de désactiver l'ipv6 dans les paramètres du ddns 🙂 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
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.