PiwiLAbruti

Il va falloir être plus explicite si tu veux obtenir de l'aide.

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.

Le port eSATA présent sur les modèles précédents était déjà peu utilisé et servait principalement à y connecter une extension de type DX5xx ou RX4xx. Vu le prix d'une extension DX5xx, la grande majorité des utilisateurs préfère migrer vers un modèle plus grand (DS18xx+ ou plus) pour ne pas être limité dans la gestion des groupes de disques (la fameuse hérésie du groupe de stockage à-cheval sur le NAS et son extension). Synology a remplacé le port eSATA par un port USB-C probablement pour bénéficier de débits supérieurs au SATA3.0 plafonnant à 600Mo/s. Ce qui est plutôt un choix judicieux à l'ère du SSD. Pourquoi ça chouine sur un port USB-C bridé qui remplace un port eSATA très peu utilisé alors que tout le monde branche son stockage externe sur des ports USB-A toujours présents sur le DS925+ ?

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.

C'est bien une adresse IPv6 appartenant à la société Driftnet (2a06:8483::/32) dont l'activité est de détecter les vulnérabilités sur internet à grands coups de scans et de détections de ports. Donc ça n'a rien de malveillant (en théorie). IPv6 ne fonctionne pas comme IPv4 et ne nécessite pour d'ouvrir de ports sur la box pour rendre des services accessibles depuis l'extérieur (au sens NAT/PAT). Tu n'as visiblement pas configuré correctement le pare-feu du NAS pour empêcher les connexions externes via IPv6. Il est donc exposé à tout l'IPv6 sur internet. Je ne peux que te conseiller d'appliquer les recommandations du tutoriel sur la sécurité : https://www.nas-forum.com/forum/topic/77493-tuto-pas-à-pas-sécurisation-du-nas-pour-dsm-7/

Dans ce cas qui, qui va résoudre calendar.ndd.fr ? Tu mélanges proxy inversé et résolution DNS. Peu importe, les deux font la même chose (proxy inversé). C'est juste que l'interface Applications est plus intuitive pour les novices.

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)

Le petit malin s'appelle un botnet et il ne change pas d'adresse IP puisqu'il exploite quelques milliers de machines zombies pour lancer des scans. Oui, en activant le blocage automatique et en le paramétrant temporairement pour que les IP soient bloquées dès la première tentative. En quelques jours, toutes les adresse IP du bot et seront bloquées. N'oublie pas d'ajouter tes réseau local en liste blanche avant d'activer le blocage automatique.

- Liste de compatibilité : https://www.synology.com/fr-fr/compatibility?search_by=drives - Pour le DS925+ : https://www.synology.com/fr-fr/compatibility?search_by=drives&model=DS925%2B&category=hdds_no_ssd_trim

Synology donne plus d'explications sur le choix restreint à ses seuls disques : Maîtrise du firmware : Le firmware ajusté permet un débit de lecture/écriture plus rapide et des opérations de récupération RAID efficaces. Moins de tickets d'assistance : Selon les statistiques de l'assistance clientèle de Synology au cours des dernières années, l'utilisation de disques validés entraîne près de 40 % de problèmes liés au stockage en moins et un diagnostic et une résolution des problèmes plus rapides. Vision monolithique : Gérez l'ensemble de votre solution de stockage via un point unique d'achat, de support et de RMA. https://event.synology.com/fr-fr/hard-drives-2025

Ressure-toi. Si Synology a fait ce choix, c'est justement parce que les revenus sur le marché professionnel permettent de négliger le marché grand public. Le surcoût des disques n'est pas un problème pour les professionnels, et la limitation aux disques de la marque est même un gage de qualité (vision monolithique de la solution). Ils font des choix drastiques d'un point de vue particulier, mais c'est une stratégie mûrement réfléchie.

Pourtant Synology est bien listé dans ta capture d'écran.

Sans même parler du DXP4800 Plus (Pentium Gold 8505), rien que le DXP4800 (N100) met déjà une claque au DS925+ (Celeron J4125) pour un TDP de 6W au lieu de 10W. https://www.intel.com/content/www/us/en/products/compare.html?productIds=197305,231803,226262 https://www.cpubenchmark.net/compare/3667vs5157vs4775/Intel-Celeron-J4125-vs-Intel-N100-vs-Intel-Pentium-Gold-8505

Ça n'a rien à voir avec les spécifications des disques. En plus d'imposer ses propres disques durs, Synology impose les mises à jour automatiques de ces derniers afin de fiabiliser au maximum le stockage. Chose qui n'est pas possible (ou qui prend trop de temps) avec des constructeurs tiers. Actuellement j'hésite entre acheter un DS224+ d'occasion pour pousser au maximum une utilisation raisonnable de leurs produits, ou simplement regarder ailleurs (notamment les NAS Ugreen sur sur lesquels on peut installer presque n'importe quel OS).

Tu peux vérifier la compatibilité des caméras directement sur le site de Synology : https://www.synology.com/fr-fr/compatibility/camera?brand[]=HIKVISION Concernant ton modèle : https://www.synology.com/fr-fr/compatibility/camera?query=DS-2CD2347G2H-LIU

Je te conseille de lire ces deux tutoriels dans l'ordre : https://www.nas-forum.com/forum/topic/77493-tuto-pas-à-pas-sécurisation-du-nas-pour-dsm-7/ https://www.nas-forum.com/forum/topic/67167-tuto-configurer-«-mailplus-server-»-avec-une-ip-dynamique-orange/ Selon ton opérateur, il sera peut-être nécessaire d'utiliser un relais SMTP pour envoyer les messages.

Par défaut, un paquet WoL n'est diffusé que sur le segment réseau de l'émetteur. Dans le cas présent, le smartphone n'émet ce paquet que sur le réseau 192.168.68.0/24 (broadcast à destination de 192.168.68.255 ou 255.255.255.255). Le paquet ne peut donc pas parvenir au NAS situé sur un autre segment (192.168.1.0/24). Il est très peu probable que le routeur Mesh propose un proxy WoL pour propager la diffusion du paquet sur les autres segments qui y sont connectés. La solution la plus simple est de connecter le NAS derrière le routeur mesh (attention au changement d'adressage IP). La solution la plus propre est de configurer un unique segment réseau en configurant les appareils réseau du réseau mesh en points d'accès Wi-Fi.

Panneau de configuration > Notification > onglet Règles > sélectionner defaut > bouton Modifier > développer Système > décocher Adresse IP bloquée.

Je n'ai jamais rencontré de problème de lenteur avec DNS Server. Les serveurs DNS définis sur le NAS sont ::1 et 127.0.0.1 pour qu'il puisse utiliser ses propres zones locales. Pour assurer la continuité des résolutions DNS par les clients en cas de panne du NAS (ce que je trouve inutile, mais admettons), il y a une solution possible pour Windows (je ne la connais pas pour Mac/Linux) : Il faut indiquer aux clients d'utiliser un serveur DNS public quelconque. Et renseigner le serveur DNS à utiliser pour les zones locales avec la commande PowerShell Add-DnsClientNrptRule : https://learn.microsoft.com/fr-fr/powershell/module/dnsclient/add-dnsclientnrptrule?view=windowsserver2025-ps Ainsi, lorsque le client doit résoudre un nom terminant par un domaine résolu en local, on lui indique l'adresse IP du serveur DNS à utiliser. À l'origine, j'utilise cette commande sur les clients Windows en VPN afin qu'ils puissent accéder aux ressources locales.

Il faut savoir que Firefox utilise par défaut les serveurs DoH (et non d'Oh!) de CloudFlare et non les serveurs DNS configurés sur le client. Il faut donc désactiver cette option dans : Paramètres > Vie privée et sécurité > Rubrique DNS via HTTPS > Cocher Désactivé Ainsi les requêtes DNS seront résolues par les serveurs DNS configurés sur le client.

J'ai corrigé ma précédente réponse. Un traceroute n'affiche que les routeurs traversés jusqu'à la destination demandée (du moins ceux qui répondent aux sollicitations ICMP echo, ce qui est de plus en plus rare pour des raisons de sécurité). Le premier routeur rencontré est la passerelle renseignée dans le client. Dans le cas présent, la passerelle est la Freebox en 192.168.1.254. IL n'y a donc rien d'anormal.

Quel est le résultat de la commande nslookup vaultwarden.domain.tld exécutée depuis le client ? Le fait que ce soit l'adresse IP locale de la Freebox qui est vue indiquerait que vaultwarden.domain.tld renvoie l'adresse IP publique de la box. La requête est alors renvoyée par le loopback de la Freebox sur le réseau local, d'où l'adresse IP de la box 192.168.1.254. > Il s'agit d'un traceroute.

Les clients ne gèrent pas tous les serveurs DNS qui leur sont distribués de la même manière. Ils peuvent très bien interroger le deuxième serveur DNS sans défaillance du premier. Les zones locales créées dans DNS Server ne pouvant pas être résolues par le serveur FDN, les accès peuvent être aléatoirement lents car les noms sont impossibles à résoudre (ou pointent vers une adresse IP publique).

Are you an IA bot @Rev9 Solutions ?

Dans tous les cas présentés, ça n'a aucun intérêt. Qu'est-ce qui ne fonctionne pas bien sur ton réseau actuellement et que tu voudrais optimiser ? Quels risques de sécurité crains-tu ? Je suppose que tu as choisis un environnement Orbi uniquement pour améliorer la qualité du réseau Wi-Fi ? Si oui, il risque d'y avoir des optimisations à faire : Est-ce que l'adressage réseau derrière le routeur Orbi est le même que celui de la Livebox ? Adresse du réseau Orbi : 192.168.x.0/24 Adresse du réseau Livebox : 192.168.y.0/24 Si x et y sont différents, le réseau n'est pas optimal pour les raisons suivantes : Double NAT (routeur Orbi + Livebox), Pas d'IPv6 derrière le routeur Orbi (on est en 2025 tout de même).