PiwiLAbruti

Tu as oublié de préciser l'année 😆

Le message est pourtant explicite, Kitterman indique qu'il n'a pas trouvé d'enregistrement MX comme indiqué dans le SPF ("mx"). Il est possible que ce soit redondant avec "include:mx.ovh.com".

Que les Freebox soient en mode routeur ou en mode bridge, il faut un adressage LAN commun aux réseaux 1 et 2. Donc ça ne me semble pas réalisable avec les contraintes que tu indiques. Quel est le besoin exactement ? Disposer d'un débit plus élevé pour certaines machines du réseau 2 ?

J'ai rien compris 🤔😅

Si le message indique toujours un softfail, c'est que le paramètre -all n'est pas effectif. Attention à laisser un délai suffisant avant de tester après modification (>24h), le temps que la propagation DNS soit effective.

Le softfail vient de ton enregistrement SPF. Ce n'est pas grave si tu es en phase de configuration/test, mais il faudra rendre le SPF plus restrictif en remplaçant ~all par -all.

C'est justement indiqué dans ton précédent message. Tu as autorisé la configuration automatique des enregistrements A et MX pour le Web hosting package auquel tu as souscrit, donc OVH a fait ce que tu l'as autorisé à faire 🙂

Utilises-tu ton propre SMTP ou un relai externe ? Suite au changement d'adresse IP, est-ce que ton score Mail-Tester s'est maintenu ?

Il y a une page d'information lorsqu'on consulte la page des produits EA (early access, accès anticipé) indiquant que le produit peut présenter des bugs non-corrigibles si ça vient du hardware et que Ubiquiti n'est pas responsable bla bla bla... À acheter en connaissance de cause.

Ubiquiti a sorti un AP en early access (oui, c'est original pour du hardware), il s'agit de l'UniFi 6 Lite : https://eu.store.ui.com/collections/unifi-network-access-points/products/unifi-ap-6-lite Je suis curieux de voir les performances de cet AP "bridé" par son port 1GbE. En tout cas il est vendu au même prix que l'UniFi AC Lite (69€ H.T.), pour le moment.

Ton phpMyAdmin retest accessible depuis Internet ? Si oui et si tu besoin d'un accès externe, utilise un .htaccess pour limiter les sources pouvant y accéder (filtrage IP et/ou mot de passe).

Ta mésaventure vient surtout du fait que tu as volontairement dégradé une grappe RAID pour transférer des données d'un système vers un autre. De là à remettre en cause la tolérance aux pannes, c'est un peu gros😅 Dans le cas présent, l'erreur est plutôt entre la chaise et le clavier. Il y a au moins 3 points incontournables dans la gestion du stockage, dans l'ordre : Tester tous les disques avant la mise en production (avec un outil fourni par le constructeur ou badblocks), Avoir une sauvegarde à jour des données importantes, Remplacer systématiquement et rapidement le(s) disque(s) défectueux d'un volume dégradé avant d'engager tout autre opération pouvant aggraver la situation (copie, sauvegarde, ...) Le point 1. est rarement appliqué, la fiabilité des disques étant relativement bonne et les utilisateurs grand public peu sensibilisés à cette vérification. La sauvegarde est de très loin le point le plus important. Sans même parler de la perte d'un disque, le moindre anéantissement total des données d'un NAS (destruction physique, cryptolocker, ...) est tout de suite dramatique. Non pas qu'il faille sauvegarder toutes les données, mais au moins sauvegarder les données importantes. C'est valable pour tout stockage numérique, quelqu'il soit. Concernant la probabilité que plusieurs disques tombent en panne en même temps, c'est plus fréquent qu'on pourrait le penser. Surtout avec des disques issus d'une même série (numéros de série consécutifs). J'ai déjà eu le cas avec 9 disques sur 12 qui ont échoué au test badblocks. Après remplacement par des disques de même modèle (oui, je suis joueur et persévérant), tous ont passé le test avec succès.

@Lelolo : Parce que tu utilises ton vrai prénom sur le forum ? 😆

La réponse est "Oui" mais... si tu te poses la question, c'est que ce n'est pas fait pour ton utilisation (stockage dédié, non partageable, ... tu vas l'abandonner dès tes premiers tests). As-tu testé SLB (Software Load Balancer) ? Cette d'agrégation n'a besoin d'aucune configuration particulière sur le switch. Il est aussi très important d'activer SMB3 dans les Services de fichiers du NAS (qu'on ne peut malheureusement pas définir comme version minimale). À partir de la version 3.0 de ce protocole, les canaux multiples (multichannel) et le basculement (failover) sont supportés. Contrairement aux versions précédentes du protocole, SMB3 est capable d'établir une connexion TCP par interface disponible et ainsi utiliser tous les liens possibles sur la machine cliente. Voilà pour la théorie, il ne reste plus qu'à tester. 😅

Non, j'utilise bien mon propre SMTP. Je verrais lors du passage à la fibre (un jour), qui impliquera certainement un changement d'adresse IP, si les choses se compliquent. Mon opérateur est Free avec une vieillerie increvable de Freebox Révolution à jour. Le reverse pointe sur un domaine something.domain.tld alors que j'utilise domain.tld pour les mail, la note Mail-Tester n'est pas dégradée pour autant.

L'une des premières choses à faire est de bien modifier les enregistrements DNS, dont passer l'enregistrement SPF en softfail (~all) et de le repasser en strict lorsque tout refontionne correctement (-all). Le reverse n'est pas vital (j'ai 10/10 sans). Patiente un peu, il faut parfois plusieurs jours pour que la propagation se fasse correctement. Il est tout à fait possible de sortir la nouvelle adresse IP des listes SORBS sans créer de compte (ça a peut-être changé depuis la dernière fois que je l'ai fait).

Une agrégation LACP sur un client va mettre à disposition plusieurs liens GbE sous une seule et même adresse MAC, adresse sur laquelle le switch se base par défaut pour faire sa répartition (une MAC par lien). Comme je l'ai déjà dit il existe d'autre méthodes de répartition selon ce que peut proposer le switch. À tester donc. Il y a une méthode d'agrégation sur le NAS (ALB de mémoire) qui permet de dépasser le 1GbE sans avoir besoin d'un switch L2 manageable, ni de configurer une agrégation sur ce dernier. Mais pour que tout cela fonctionne, il faut généralement un protocole de transfert de fichiers capable de gérer plusieurs connexions pour une même copie afin que la répartition puisse se faire au niveau du client (ce qui n'est pas le cas de SMB, ou alors peut-être en version 3 ?). Je n'ai utilisé ce type de fonctionnement qu'avec iSCSI en multipath (4Gb/s).

Avant que ce sujet ne devienne encore plus n'importe quoi, il faut savoir qu'un disque mécanique dépasse allègrement le 1Gb/s. LACP ne permettra pas de dépasser 1Gb/s par client, la méthode de repartition du switch étant basée sur l'adresse source (adresse MAC du client, par défaut). À voir selon le switch si d'autres méthodes de repartition sont disponibles. Mais je déconseillerais d'utiliser ce protocole.

C'est résolu.

J'espère que Synology va développer un client lourd pour C2, et ne fera pas l'erreur d'implémenter une horreur avec des technologies web.

De mon côté je n'ai pas de script ip-down, la route ajoutée par le script ip-up étant automatiquement supprimée à la déconnexion. Je ne saurais pas te dire pourquoi ça ne fonctionne pas chez toi.

Je ne comprends pas. Tu demandes où mettre le script alors que tu le mets au bon endroit. Le script se nomme ip-up et est placé dans /etc/ppp. Le script ip-down est inutile car, l'interface n'existant plus à la déconnexion, la règle de routage est supprimée automatiquement. Si tu souhaites faire passer tout le trafic par le VPN, il n'y a pas besoin de ce script. Bref, pour vérifier ce qui cloche il faut vérifier les métriques de la table de routage une fois connecté au VPN (netstat -rn).

C'est écrit sur ta capture d'écran : "Ajouter des arguments" 🤓

Pour faire court : https://github.com/piwi82/VPN-route

Le routage n'est pas une obligation et ne s'applique que dans le cas où on décoche la case à cocher qui fait passer tout le trafic par le VPN (cochée par défaut). Tu parles du script pour Mac/Linux (/etc/ppp) ou pour Windows (aucune importance) ?