PiwiLAbruti

Quel est l'état du pare-feu IPv6 de la Freebox ?

D'après le log de FileZilla (où ton adresse IP apparaît en clair), la connexion de donnée sur le port tcp/55700 (216*256+148) n'a pas pu être établie même si ce port appartient bien à la plage ouverte (55536 à 55899). Est-ce que la connexion FTP s'établit bien en local ? (sans passer par la box donc)

Synology répond toujours, même si le produit n'est plus suivi. Je les embête encore avec des reliques de 2009 et 2012 😅 On ne voit pas le message de Suggestion en entier sur la capture d'écran.

On s'en fout que ça me convienne, l'important est que ça résolve le problème de @Eric Cattelin.

Si ce n'est déjà fait, j'aurais tendance à suivre les recommandations indiquées dans le message d'erreur.

Est-ce que le nom utilisé en externe (imap.domain.tld) se résout uniquement en IPv4 ? Est-ce que le port tcp/993 est accessible de l'extérieur en IPv6 ?

Dans le pare-feu du NAS, quelles sont les sources externes autorisées à accéder au port tcp/993 ?

À un moment on est en 2025 @CMDC, il faudrait arrêter de conseiller aux novices de désactiver IPv6. Les réseaux des FAI sont IPv6 natif et IPv4 y est encapsulé (legacy). Donc si on souhaite avoir un réseau qui fonctionne de manière optimale, il faut utiliser au maximum IPv6. Certes, c'est loin d'être parfait car des fonctionnalités parfois vitales pour autohéberger certains services (comme un serveur mail) ne sont pas toutes disponibles, comme la délégation de préfixes et de zones DNS inverses, le support de NPTv6 (ou NAT66) pour la translation de préfixes locaux, et j'en passe… Mais si tout le monde s'amuse à désactiver IPv6, ça ne fera que repousser l'échéance de l'ajout de ces fonctionnalités manquantes. Ça fera bientôt 12 ans (depuis juillet 2013) que la délégation des zones DNS IPv6 inverses est demandée chez Free. Si vous voulez vraiment disposer d'un reverse IPv6, faites-le savoir sur ce ticket : https://dev.freebox.fr/bugs/task/12749 Vous verrez que vous ne serez pas les seuls à le demander : https://dev.freebox.fr/bugs/task/12749#comment187477 (message du 17/02/2025 09:32)

Les FAI devraient fournir une délégation de zone pour que ce soit possible. Aucun d'entre eux ne le propose actuellement. L'enregistrements MX utilisé pour le serveur de messagerie doit donc pointer vers des enregistrements de type A (IPv4) uniquement pour que la vérification du DNS inverse soit valide.

J'ai testé via un navigateur sur iOS, le mail est bien envoyé. Que se passe-t-il si tu ouvres le brouillon et que tu cliques sur le bouton [Envoyer] ?

Le modèle du NAS (DS415+) me fait surtout penser à ça :

Dans ce cas HTTP est suffisant, et il faut utiliser l'adresse IP du NAS virtuel (ce qui était certainement déjà le cas).

Si le reverse proxy et la destination sont sur le même NAS, la destination devrait plutôt être configurée ainsi : Protocole : HTTP Nom d'hôte : localhost Port : 10020

Ce n'est pas évitable avec la Livebox, car elle vérifie la valeur de l'en-tête Host (sécurité bidon appliquée par Sagem). L'intérêt du reverse proxy est de faire croire à la Livebox qu'on a utilisé l'hôte 192.168.1.1 pour se connecter. Le reverse proxy est fait pour tout type d'accès, intérieur ou extérieur. Maintenant, le cas présent (accès interne uniquement) ne présente pas beaucoup d'intérêt vu que http://192.168.1.1 est bien suffisant.

Si ton serveur DNS est correctement configuré, la commande nslookup xxx.synology.me doit se résoudre en l'adresse IP privée du NAS (192.168.1.x avec x≠1). Est-ce le cas ?

Si j'ai bien compris, tu veux que http://box.maison.local affiche l'interface de la Livebox en passant par le reverse proxy du NAS ? Pour cela, la résolution DNS de box.maison.local pointe vers 192.168.142.1 (adresse IP du NAS ) de façon à ce que les requêtes HTTP arrivent sur le reverse proxy du NAS. Ensuite, le reverse proxy du NAS se charge d'envoyer le traffic HTTP à destination de la Livebox dont l'adresse IP est 192.168.1.1. Dis-moi si ça te semble clair ou pas ?

Dans DNS Server, crée une zone DNS xxx.synology.me. Le reste est expliqué dans le tutoriel. Au passage, tu peux créer autant de noms que tu le souhaites de la forme <nom>.xxx.synology.me (dsm.xxx.synology.me, audio.xxx.synology.me, …). Ces noms fonctionneront aussi bien en local qu'en externe, et tu peux en contrôler individuellement les accès réseau dans le reverse proxy en créant des profils de contrôle d'accès.

@firlin : Non, je n'ai jamais vu ça.

Il vaut mieux laisser le proxy inversé au plus près de l'hébergement web pour des raisons de fiabilité et de performances.

box.maison.local doit pointer vers l'adresse IP du NAS pour que le reverse puisse ensuite rediriger vers la box.

Les licences Surveillance Station peuvent être stockées sur un compte Synology.

Comment une requête pointant vers 192.168.1.1 peut-elle atteindre le reverse proxy du NAS ? Le problème viendrait plutôt du fait qu'en local c'est l'adresse IP publique (résolue par xxx.synology.me) qui est utilisée. Il faudrait plutôt que xxx.synology.me pointe vers l'adresse IP privée du NAS.

Si box.maison.local pointe sur l'adresse IP de la box (192.168.1.1), à quel moment la requête va passer par le reverse proxy du NAS ?

Et 192.168.1.1 est l'adresse de quel équipement ?

Je me demande si le NAS sait résoudre ce nom. Il faudrait exécuter la commande nslookup sur le NAS via SSH/Telnet pour vérifier. D'ailleurs l'adresse IP privée n'a rien de confidential, elle n'a pas besoin d'être masquée. Surtout que la syntaxe que tu donnes prête à confusion : 192.168.1xx.x