Aller au contenu

Classement

Contenu populaire

Affichage du contenu avec la meilleure réputation depuis le 11/08/25 dans toutes les zones

  1. Non, ça n'a aucun rapport avec le port. C'est le NAS qui ajoute cette en-tête HTTP avant d'envoyer une requête à la Freebox. Il n'y a aucun intérêt à chiffrer les échanges entre le NAS et la Freebox, mais les deux fonctionnent (tcp/80 ou tcp/443). Je n'ai pas cherché à comprendre pourquoi la Freebox a un comportement différent en HTTP et en HTTPS, et ça ne m'intéresse pas. Orange faisait la même chose avec les Livebox v4 où il fallait l'en-tête Host: 192.168.1.1 pour y accéder, je ne sais pas si c'est le cas sur les modèles plus récents.
  2. L'en-tête personnalisé sert uniquement à tromper la Freebox en lui faisant croire que le nom d'hôte mafreebox.freebox.fr a été utilisé pour l'atteindre. C'est pour contourner l'erreur que tu avais indiquée : Ça n'a rien à voir avec le port 80. Si le NAS n'est pas accessible en IPv6, ça ne peut pas fonctionner. Le pare-feu IPv6 des Freebox (hors Freebox Pro) est un honte : c'est un gros interrupteur qui bloque ou autorise tout le trafic IPv6. Il n'y aucun moyen de filtrer le trafic sans rajouter un pare-feu digne de ce nom derrière la Freebox.
  3. Tu n'as que le port tcp/443 à ouvrir à destination du NAS sur la Freebox. Ensuite, tout se fait dans le proxy inversé. Par exemple : dsm.domain.synology.me > localhost:5000 freebox.domain.synology.me > 192.168.1.254:80 Si les restrictions d'accès du pare-feu ne sont pas suffisantes, je te conseille vivement de configurer des profils de contrôle d'accès dans le proxy inversé.
  4. Si le port est bien ouvert sur la Freebox, ça ne vient pas de la Freebox. Je pencherais plutôt pour un blocage du port sortant depuis la connexion en Allemagne. Je ne connais aucune entreprise sérieuse qui laisse du trafic utilisateur sortir sur d'autres ports que les suivants (hors besoins exotiques) : HTTP (tcp/80) HTTPS/DoH (tcp/443) QUIC/DoQ (udp/443) D'où l'intérêt d'utiliser systématiquement le proxy inversé pour toutes les interfaces web (DSM inclus).
  5. Le mieux est d'utiliser tcpdump : tcpdump -nq 'port (443 or 1234 or 5001)'Ça affiche le trafic en amont du pare-feu du NAS. Donc ça permet de savoir si le trafic parvient bien jusqu'au NAS, peu importe qu'il soit bloqué ou non par le pare-feu.
  6. Les domaines ayant pour TLD .me sont souvent bloqués, il s'agit peut-être d'un blocage DNS de ton entreprise. Vérifie que la résolution de domaine.synology.me retourne bien ton adresse IP : > nslookup domaine.synology.meou > Resolve-DnsName domaine.synology.me Et aussi celui sur la sécurité : https://www.nas-forum.com/forum/topic/77493-tuto-pas-%C3%A0-pas-s%C3%A9curisation-du-nas-pour-dsm-7/
  7. Bonjour Il faudrait revoir le tuto sur le reverse proxy. L'intérêt du reverse proxy est de limiter l'ouverture des ports. Seuls 443 doit être ouvert éventuellement 80 si tu n'as pas de redirection http vers https et quelques autres exceptions.
  8. Mystérieusement cela a repris vers 4h ce matin. Je me demande si l'ip du vpn n'a pas été Blacklist chez eux. Tout est rentré dans l'ordre pour moi et Milles Merci d'avoir pris le temps de répondre
  9. Bon bah, l'intuition était la bonne, j'ai désactivé le Wake on Lane, plus de problème de latence sur la télé.
Ce classement est défini par rapport à Bruxelles/GMT+01:00

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.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.