PiwiLAbruti

Vérifie les redirections de ports sur ta box/routeur. Il doit nécessairement y en avoir une qui laisse passer du SSH (quelque soit le port).

Des tentatives depuis quelles adresses IP ?

Non. Sur le mien j’ai eu à changer la pile de la carte-mère mais les symptômes n’étaient pas les mêmes (ce NAS me sert également de sauvegarde distante). Vérifie l’activité du NAS avec la commande "top" via SSH, l’interface DSM étant trop peu réactive. Absolument pas. Il suffit de bien sécuriser les accès pour ne pas exposer inutilement ce NAS sur internet (pare-feu).

Et visiblement ça continue 😅

Tu n’es pas obligé d’utiliser postmaster. N’importe quelle adresse fonctionnera.

Le problème est que la réputation de ton domaine et de ton adresse IP est devenue mauvaise à cause de l’absence des enregistrements DNS requis. Il faut être patient et attendre que Google améliore cette réputation.

@Vasyjeannot : Donc seul l’accès à l’interface de DSM ne fonctionne plus ? Quelles modifications as-tu faites récemment sur ton NAS ? Peux-tu ouvrir une session SSH et exécuter le commande "top" pour voir l’état de consommation des ressources ?

Le SPF sert à indiquer les adresses des hôtes autorisées à envoyer des emails pour vos domaines. C'est l'un des mécanismes le plus important lorsqu'on met en place un serveur mail. Comme la configuration sur un NAS Synology est souvent faite avec un seul domaine et un seul serveur principal, l'adresse à définir correspond à l'enregistrement MX du domaine. L'intérêt de choisir cet enregistrement est que le SPF suivra implicitement les modifications des MX : v=spf1 mx -all ou v=spf1 +mx -all (l'opérateur "+" est implicite devant les directives qui en sont dépourvues) J'en ai vu qui utilisaient des SPF un peu exotiques comme "v=spf1 mx a 1.2.3.4 -all" où "a" est l'enregistrement racine A du domaine et "1.2.3.4" l'adresse IP publique. Lorsque tous pointent vers la même adresse IP, c'est évidemment redondant et totalement inutile (voire dangereux). Attention à l'opérateur devant la directive "all", si vous êtes en phase de configuration ou de test de votre serveur, utilisez l'opérateur "~" (tilde) qui vous évitera des blocages intempestifs : v=spf1 mx ~all Bien sûr il est possible d'ajouter d'autres serveurs que vous voulez autoriser à envoyer des mails pour vos domaines, il existe alors différentes façon des les déclarer. Dans le cas d'un serveur MX de secours chez OVH, ce dont il est question dans ce sujet, on inclut l'enregistrement SPF d'OVH et rien de plus : v=spf1 mx include:mx.ovh.com -all Si vous utilisez plusieurs domaines et que l'enregistrement SPF est identique pour tous ces domaines, la directive "redirect" permet de faire pointer l'enregistrement d'un domaine vers celui d'un autre domaine. Ainsi, en cas de modification du SPF, la modification sera appliquée à tous les autres domaines : v=spf1 redirect=spf.domain.tld D'où la bonne pratique de le faire même si vous ne possédez qu'un seul domaine pour anticiper l'acquisition d'autres domaines ultérieurement : spf.domainA.tld TXT "v=spf1 mx -all" domainA.tld TXT "v=spf1 redirect=spf.domainA.tld" domainB.tld TXT "v=spf1 redirect=spf.domainA.tld" domainC.tld TXT "v=spf1 redirect=spf.domainA.tld" domainD.tld TXT "v=spf1 redirect=spf.domainA.tld" ... Pour terminer, vous pouvez résoudre récursivement les enregistrements SPF (TXT) pour vérifier les hôtes autorisés. Un exemple avec mx.ovh.com : > nslookup -type=TXT mx.ovh.com mx.ovh.com text = "v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all" > nslookup mail-out.ovh.net Name: mail-out.ovh.net Address: 87.98.222.13 > nslookup mail.ovh.net Name: mail.ovh.net Address: 193.70.18.148 Concernant l'enregistrement DMARC, il sert à indiquer la politique de filtrage à appliquer aux messages et à définir les destinataires des rapports. Là chacun configure selon ses besoins. Pour ma part, j'applique une politique stricte : _dmarc.domain.tld TXT "v=DMARC1; aspf=s; adkim=s; p=quarantine; pct=100; ruf=mailto:posmaster@domain.tld; rua=mailto:posmaster@domain.tld!100M;" Si vous voulez des détails, je ne vais pas paraphraser Wikipedia.

Dommage que ce ne soit pas mentionné dans les tutoriels, c’est la partie la plus importante dans la configuration d’un serveur mail. Je ferai un bref résumé de ce qu’il faut configurer ce soir si j’ai le temps. N’hésitez pas à abuser de Wikipedia sur ce sujet, le plus important étant de comprendre à quoi ça sert.

Ce qui fait ramer la VM est l’interface graphique de Windows 10. Si la VM n’a pas de session ouverte, les services seront beaucoup plus performants.

Il y a un tutoriel (un pour Mail Server et un autre pour MailPlus Server) sur le forum qui explique l’importance des enregistrements SPF, DKIM, et DMARC. Google applique une politique de sécurité assez restrictive concernant la présence de ces enregistrements (et c’est une bonne chose). Donc le problème que tu as rencontré provenait d’une mauvaise configuration de ton serveur mail (qui permet entre autre l’usurpation d’identité 😱). Ce qui me gêne le plus c’est que visiblement tu n’aies eu le problème qu’avec Google. Il y a encore du travail chez les autres fournisseur de messagerie...

La supervision consiste à faire un ping vers les MX de Google (aspmx.l.google.com). Si ces derniers sont joignables, c’est que Google a probablement blacklisté ton serveur mail (ou autre mécanisme de sécurité). Quelle note attribue Mail-Tester à ton domaine ?

@alan.dub t’a déjà donné une solution.

Si tu est persuadé que le problème ne se produit qu’avec les serveurs Gmail, tu peux donc ne superviser que ces derniers. Mail Server ne pourra rien te dire sur Gmail puisque les serveurs de Gmail n’ont même pas pu atteindre ton NAS.

Dans ton cas d’utilisation, un NAS ne t’apportera rien de plus que de la complexité inutile. Il vaut mieux avoir tes données sauvegardées sur plusieurs disques externes.

C’est pourtant clair, les serveurs Gmail n’ont pas réussi à atteindre ton NAS. Le plus probable est que le problème vienne du réseau. Soit ta connexion internet était perdue au moment de l’envoi du message par Gmail, soit ton opérateur a rencontré un souci d’interconnexion avec les services Google (ou du moins une partie). Ces deux cas sont assez courants. La seule solution pour savoir exactement d’où ça vient est de mettre en place une supervision de ta connexion internet et des serveurs Gmail.

La réponse se trouve dans la section "Répartition" de l’article suivant : https://fr.m.wikipedia.org/wiki/IEEE_802.3ad

Si le test est négatif, tu auras perdu du temps en commençant à le configurer. Il vaut mieux laisser le NAS terminer tranquillement de vérifier les disques. Commencer à l’utiliser ne fera que ralentir le test. Patience...

SI tu as compris tous les mécanismes que tu as mis en place pour monter ton serveur de messagerie (SPF, DKIM, et DMARC) et que tu as bien appliqué le tutoriel sur la sécurité (surtout le blocage automatique), le problème de la sécurité est alors déjà réglé.

Si on prend le premier fichier nommé 05M21S_1590671121.mp4, il se découpe comme suit : 05M : 05 minutes passée de l'heure indiquée dans le nom du dossier (15h dans le cas présent), 21S : 21 secondes, 1590671121 : c'est le timestamp de la vidéo (nombre de secondes passées depuis le 1er janvier 1970, fuseau GMT).

Ça peut être intéressant si le débit est très souvent sollicité simultanément par plusieurs machines du réseau, chose rarissime chez un particulier ou très ponctuelle qui ne justifie pas l’utilisation de l'agrégation de liens. En milieu professionnel, au-delà de l'augmentation de débit, on l’utilise surtout pour relier les serveurs à des switches stackés pour permettre la redondance de liens en cas de panne d’un switch. Par contre, tu peux très bien dédier une première interface à tout ce qui vient d’internet (dont ton WordPress), et dédier la deuxième au traffic local (interface sans passerelle ni DNS). Ainsi tu peux dédier 1GbE à Internet, et 1GbE au LAN.

Pour utiliser les applications mobiles depuis l'extérieur du réseau local, il est fortement recommandé d’utiliser le reverse proxy (voir le tutoriel dans la section dédiée) pour ne surtout pas exposer le port 5001 sur internet. Une fois le reverse proxy configuré, il faudra indiquer explicitement le port 443 dans les applications mobiles (nas.domain.tld:443).

Tu peux parfaitement prendre exactement les mêmes modèles de disques. Si tu veux éviter une mauvaise série, il suffit de les commander chez deux fournisseurs différents. Ainsi, les numéros de série se retrouveront éloignés. Les mauvaises séries, ça existe. J'ai eu le cas sur des WD RED Pro 4To, 9 disques sur les 12 étaient défectueux (secteurs défectueux qui montaient en flèche à +10k). Je n'ai pas de soucis depuis le remplacement par des disques de ce même modèle. Prendre des disques de modèles différents ne posera pas de problèmes si les disques fonctionnent 24h/24 (hibernation désactivée). Le souci avec des modèles différents est le risque de voir un des disques se faire éjecter de la grappe à la sortie de veille, d'où l'importance de la désactiver.

C'est une bonne question à laquelle je n'ai pas la réponse. Les licences sont liées à l'appareil, donc je pense qu'à la revente il faut supprimer l'appareil de ton compte pour que le nouvel acquéreur puisse l'ajouter. Ainsi il récupèrera les licences associées. À faire confirmer par le support Synology.

Non, tu ne te trompes pas 🙂 C'est d'ailleurs clairement indiqué dans les préalables des tutoriels sur Mail Server et MailPlus Server.