PiwiLAbruti

Le port tcp/22 est ouvert si SFTP est activé même si SSH est désactivé. Je ne sais pas si la règle de blocage fonctionne pour "Toutes les interfaces" (sélectionné en haut à droite). Je préfère créer les règles de pare-feu directement sur l'interface concernée ("LAN 1") et ne rien mettre dans "Toutes les interfaces".

Et tu l'as testé @mightor ? Ça n'a pas révolutionné ma façon d'écouter de la musique pendant mes trajets. J'utilise des playlist en aléatoire. L'icône "À l'écoute" (de base dans CarPlay) est suffisante pour afficher les informations du titre en cours et les contrôles de base (lecture/pause, suivant, précédent, ...).

Sans les adresses IP, on ne peut pas savoir si tes règles de pare-feu sont bonnes ou non. Il este inutile de masquer le adresses IP privées, masque seulement les adresse IP publiques personnelles (s'il y en a).

Tu passes également par l'assistant via le navigateur ? As-tu essayé via l'application Synology Assistant ? https://www.synology.com/fr-fr/support/download/DS216+II#utilities

Ok, donc c’est une belle régression par rapport à la série '18 pour ceux qui ont besoin de plus de RAM.

C’est une blague la RAM soudée ?! J’espère qu’on peut toujours mettre plus de 4Go dans le seul slot restant. Du coup je suis très satisfait de mon DS718+ sur lequel j’ai pu remplacer la barrette de 2Go par 2x8Go (oui la virtualisation ça consomme).

Le mien est sur un site distant depuis 2 ans maintenant. Le débit est limité par ma connexion VDSL à 8Mo/s. En local, je suis déjà monté sans problème à 70Mo/s, mais en règle générale ça tourne plutôt autour de 40Mo/s.

Ça m’étonnerait que ça vienne du hack, je n’ai pas de problèmes de débit sur le mien. Quels paquets sont installés sur ton DS112j ?

DSM 6 étant un gouffre pour les ressources sur ce modèle, as-tu testé les débit sans être connecté à DSM ?

Oui, c'est celui-là. Il n'est pas obsolète, il est parfaitement fonctionnel et valide, mais déconseillé (tel qu'énoncé dans la note de la RFC que tu n'as pas dû lire). Techniquement, le mécanisme est intéressant en soi car il permet une double validation DNS du serveur d'expédition. Mais la résolution inverse pose des problèmes de performances et donc de fiabilité. Bref, si ça posait vraiment des problèmes de fiabilité, je pense qu'OVH aurait déjà rectifié la chose. Si vraiment ça te gêne, tu peux toujours créer un nouvel enregistrement TXT dans ta zone DNS (en remplaçant les instructions "ptr" par "a") et l'inclure dans ton SPF principal : ovh.domain.tld TXT "v=spf1 a:mail-out.ovh.net a:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all" domain.tld TXT "v=spf1 mx include:ovh.domain.tld -all" Le gros inconvénient de cette méthode est qu'elle est statique. L'enregistrement ovh.domain.tld sera obsolète dès qu'OVH modifiera son enregistrement SPF. Personnellement, je laisserai le SPF d'OVH même s'il n'est pas optimal.

La documentation d'OVH est très claire sur le sujet, le SPF est l'enregistrement TXT mx.ovh.com contenant : v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all Il suffit de l'inclure dans ton enregistrement SPF ("include:mx.ovh.com"). ssl0.ovh.net et ns0.ovh.net pointent vers la même adresse IP (193.70.18.144), il n'y a donc aucune différence à utiliser l'un ou l'autre. Ces adresses ne sont pas déclarées dans le SPF d'OVH, elles ne permettront donc pas d'envoyer les messages de ton domaine. Si tu en doutes, vérifie les en-têtes du message reçu. La validation SPF indique l'adresse IP utilisée pour l'envoi du message. Ça ressemble à ça : spf=pass (recipient.tld: domain of user@sender.tld designates A.B.C.D as permitted sender) smtp.mailfrom=user@sender.tld; Je serais surpris que tu puisses y voir l'adresse IP 193.70.18.144.

a:ssl0.ovh.net veut dire que les adresses IP résolues par le nom d'hôte ssl0.ovh.net peuvent envoyer des emails. Pour obtenir ces adresses IP on fait une résolution de type A (par défaut) avec la commande nslookup ou dig, ce qui renvoie l'adresse 193.70.18.144. include=mx.ovh.com veut dire qu'on inclut le SPF résolu par mx.ovh.com. On fait cette fois-ci une résolution de type TXT et on obtient : v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all ptr:mail-out.ovh.net et ptr:mail.ovh.net indiquent la même chose que l'instruction "a", sauf qu'en plus on va faire une résolution inverse sur les adresses IP pour vérifier que les noms d'hôte appartiennent bien au même domaine : mail-out.ovh.net > 87.98.222.13 > admin.mail-out.ovh.net mail.ovh.net > 193.70.18.148 > mail.ovh.net Note pour OVH : D'après la RFC 7208, il n'est pas recommandé d'utiliser l'instruction "ptr" (voir la note en base de la section 5.5). Ce mécanisme est considéré comme lent et moins fiable que d'autres mécanismes. Au final, le SPF mx.ovh.com autorise les adresses IP suivantes : 87.98.222.13 193.70.18.148 8.33.137.105 192.99.77.81 Donc il n'y a pas de redondance avec ssl0.ovh.net (même si je me demande ce que cette adresse vient faire dans un SPF).

Il y a généralement un nom d'hôte associé aux adresses IP de sortie d'un relais SMTP, ou mieux un enregistrement SPF incluant tout ce qu'il faut. Dans le cas d'orange, ce nom est smtp.smtpout.orange.fr. Je n'ai pas trouvé le SPF mais il devrait exister. On s'en fout mais j'explique quand même le jeu de piste : Il n'y a aucune règle de nommage de ces noms d'hôte. Dans le cas d'Orange j'ai juste fait une résolution inverse sur une des adresses que tu as indiquées, ce qui donne smtpxx.smtpout.orange.fr où xx est une numérotation séquentielle (01, 02 ,03, ..., 12, 13). En enlevant la numérotation, on trouve l'enregistrement principal. Une documentation officielle aurait été sympa, mais c'est Orange... À partir de là, tu peux simplement ajouter ces adresses à ton SPF avec une instruction "a" : ndd.tld. 60 SPF "v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all"

C'est possible en utilisant l'instruction include (mais tu l'as déjà trouvé tout seul). Ça n'a aucune importance, on pourrait très bien créer un enregistrement jemetsnimportequoi.domain.tld et l'inclure dans l'enregistrement SPF principal. Je ne comprends pas ce que tu veux dire. Et c'est quoi toutes ces adresses IP ? Comme la plupart d'entre elles sont contigües, ça pourrait s'écrire plus succinctement ip4:80.12.142.120/29 ip4:80.12.142.128/29, ce qui correspond à la plage 80.12.142.[120-135]. S'il s'agit d'adresses IP dynamiques, la plage correspondante chez Orange est 80.8.0.0/13. Ça fait un paquet d'adresses (524 288 au total), donc on va s'abstenir de l'utiliser dans le SPF (même si le risque d'usurpation peut être considéré comme mineure pour un particulier).

Je ne vois pas pourquoi ça ne marche pas puisque c’est la configuration que j’aie donnée fonctionne chez moi et chez d’autres sans aucun souci. Tu postes un enregistrement SPF qui va exactement à l’encontre des bonnes pratiques que j’ai présentées. À partir de là je ne peux plus t’aider. C’est comme si, après avoir lu le tutoriel sur la sécurité, tu me disais que l’accès externe à ton NAS ne fonctionne que lorsque ce dernier est en DMZ et que le pare-feu est désactivé. Alors oui ça fonctionne, est-ce que c’est une bonne pratique ? À toi de voir. Je crois que je vais faire comme d’autres membres qui ont beaucoup apporté à ce forum, comme ça vous n’aurez plus à supporter mon arrogance si insupportable et déplacée.