PiwiLAbruti

Aucun souci avec un vieil iPad 5 sous iOS 15.2. Vérifie les paramètres SMB de DSM. À quelle version as-tu limité le protocole ? (Panneau de configuration > Services de fichiers > SMB > Paramètres avancés > Protocole SMB max/min)

Attention à bien fournir l'adresse du serveur DNS (192.168.1.101) aux clients VPN pour que ces derniers lui envoient leurs requêtes DNS.

Salut @Macman, Tout d'abord, merci pour l'effort de rédaction et la la clarté de tes explications pour décrire l'environnement dans lequel tu travailles 👍🥇 SI, c'est bien ça. Pas avec NetBIOS (utilisé actuellement), mais avec un serveur DNS oui. Ça fonctionnera et ça t'évitera de mettre en place un serveur DNS. Essaye \\192.168.1.101\nomutilisateur (comme COMPTA-SRV ne peut pas être résolu...). Non, ça n'apportera rien de mieux.

Outlook ne tient pas compte des enregistrements SRV (comme Exchange et autres produits Microsoft), au mieux l'autodiscover est pris en compte. Ne perds pas ton temps avec les enregistrements SRV pour du mail, ils sont inutiles à 99,9% car seules une poignée d'applications totalement méconnues ou obsolètes les utilisent.

Pour faire court : à rien. ---- Pour faire long et inintéressant : Les enregistrements SRV servent (sans blague !) à automatiser la détection des serveurs à utiliser pour un service précis. Le cas le plus utilisé est la configuration automatique de clients SIP, mais ça peut s'appliquer à n'importe quel service réseau pour peu que les logiciels clients soient configurés pour les utiliser, ce qui est malheureusement extrêmement rare. La principale raison de la non-utilisation de ces enregistrements est le risque de usurpation par DNS-spoofing. C'est pour cette raison que cette méthode de configuration automatique est principalement utilisée dans des environnements réseau maîtrisés. J'avais fait le test avec un client mail qui utilisait cette méthode (parmi d'autres comme l'autodiscover) avec les enregistrements suivants : _imaps._tcp.domain.tld. 0 SRV 0 1 993 imap.domain.tld. _submission._tcp.domain.tld. 0 SRV 0 1 587 smtp.domain.tld. Le client construit préfixe le nom de domaine avec le service (_imaps, _submission, _xmpp, _sip, ...) et le protocole (_tcp, _udp, ...) à utiliser et demande une résolution de type SRV au serveur DNS afin d'obtenir l'adresse et le port du serveur avec lequel communiquer. Plus de détails sur : https://fr.wikipedia.org/wiki/Enregistrement_de_service

C'est une transcription graphique brute d'iptables 😅

Un NAS Synology peut faire l'un, l'autre, ou les deux. C'est d'ailleurs ce qui te fait des nœuds au cerveau. Il n'y en a pas un qui est meilleur que l'autre car les deux répondent à des besoins différents. Si tu veux une analogie, c'est comme devoir faire le choix entre le Cloud ou un NAS pour stocker ses données personnelles. Concernant Synology, seule la fonctionnalité iSCSI de DSM permet de faire d'un NAS Synology un SAN. Comme l'a déjà dit @maxou56, ce qui différencie un NAS d'un SAN sont les protocoles de communication dédiés au stockage (CIFS/SMB, NFS, AFP, iSCSI, FCoE, FiberChannel, ...). Je ne vais pas me lancer dans une explication détaillée de la différence, la page Wikipedia est très bien fournie à ce sujet.

... sur le VPS (si tu conserves ton VPN).

TTFB : Time To First Byte, autrement dit : le temps d'attente avant réception du premier octet. Donc ça exclut tout problème de DNS ou de lenteur réseau. Il ne reste que le NAS. Ton Wordpress étant installé dans /var/services/web/, vérifie que l'utilisateur http:http est bien propriétaire du dossier Wordpress et de tout son contenu.

Dans l'onglet [Réseau], ça t'affichera les détails de la séquence de chargement de la page.

Si possible sur le VPS, un tcpdump donnerait l'origine des attaques.

Il faudrait voir la séquence de chargement dans les outils de développement du navigateur web ([Ctrl]+[Shift]+[i]) pour voir ce qui prend autant de temps.

Pour en revenir au sujet, je ne vois pas de quoi peut venir la lenteur. Est-ce QuickConnect est activé sur le NAS ? Peux-tu vérifier la charge du NAS lors du chargement du site ? (Moniteur de ressources ou mieux, la commande "top" via SSH).

J'en connais beaucoup qui aimeraient avoir une connexion ADSL limitée à 1Gb/s en upload 😄

Vu que tu as exporté (donc sauvegardé) le calendrier qui pose problème, as-tu essayé de le supprimer de l'utilisateur avec lequel il ne fonctionne pas et de l'importer depuis la sauvegarde ? (c'est long et peut-être peu compréhensible 🥵😅)

Kézéksa "mon gros fichier" ? 🧐😄

C'est une très bonne question. Les calendriers semblent stockés dans la base de données interne de DSM (PostgreSQL). sudo -u postgres psql -d calendar -c "SELECT dav_name,summary,dtstamp,dtstart,dtend FROM calendar_item ORDER BY dtstamp DESC LIMIT 20;" (Le mot de passe demandé set celui de l'utilisateur connecté en SSH) Le champ dav_name indique un fichier .ics. Je ne sais pas s'il s'agit d'un fichier physique ou d'un lien virtuel. Dans tous les cas, je n'ai trouvé aucun fichier .ics dans /var/packages/Calendar, /var/services/homes/<user> ou /volumex/@calendar.

C'est vague comme réponse. Quel est le message d'erreur exact affiché dans le navigateur (Safari ?) ? Est-ce que Synology Assistant détecte bien le NAS ?

@.Shad. Comment sont physiquement connectés tes clients ? (filaire/Wi-Fi ? sur un même switch/directement sur le pfSense ?)

Essaye de te connecter avec l'adresse https://nomDuNAS:5001/ en remplaçant nomDuNAS par celui affiché dans le Finder. L'adresse IP du NAS, si elle n'était pas fixe, a probablement changé. Synology Assistant est un bon moyen de retrouver un NAS sur un réseau.

Je ne comprends toujours pas en quoi le pare-feu devient subitement inutile. Le pare-feu (et donc la passerelle dans le cas présent) n'est jamais utilisé dans le cas des communications entre machines d'un même réseau. Donc retirer la passerelle sur tes caméras ne les empêchera pas de se mettre à jour via NTP sur le réseau local, peu importe que le serveur NTP soit sur un routeur, un NAS, ou autre. Je ne vois pas ce qu'il y a de choquant là-dedans.

@.Shad. Si tu parles bien du trafic entre deux machines d'un même réseau, ça me paraît peu probable : Autrement dit, le trafic local n'ayant pas besoin d'être routé, la passerelle n'est pas utilisée. Exactement. C'est le moyen le plus simple et efficace d'empêcher des équipements d'accéder à d'autres réseaux (dont internet). Pas de bras, pas de chocolat 😄 Au passage, je ne sais pas s'il est possible de personnaliser les options d'une réservation DHCP dans SRM. Ça peut être pratique pour retirer la passerelle de certaines machines tout en les laissant en adressage dynamique (DHCP).

Ça ne remet rien en cause du tout et ça ne s'applique qu'aux appareils concernés, les autres ont besoin du pare-feu ne serait-ce que pour limiter une partie du trafic. C'est juste la façon la plus sécurisée d'empêcher des appareils maîtrisés d'accéder à d'autres réseaux (on les prive de niveau 3 en leur retirant la passerelle, rien ne sort de ces appareils en dehors du trafic local). Maintenant chacun fait comme il le souhaite.

Ne définis que l'adresse IP et le masque sur les appareils restreints, ça suffit pour que l'appareil puisse communiquer avec les machines du même sous réseau. Le passerelle n'est utilisée que pour atteindre des réseaux dont l'adressage est différent de celui de l'appareil. Sachant que le pare-feu devrait bloquer tout le trafic des appareils restreints, ça lui fait ça de moins à gérer. Le pare-feu ne filtre que le trafic entre réseaux différents, le trafic du réseau local (d'un même réseau) ne fait que le traverser le pare-feu sans aucun contrôle. Donc je ne vois pas en quoi ça remettrait en cause l'existance du pare-feu.

Si ça fonctionne et que ça te convient, c'est le principal. Personnellement je préfère que le trafic ne sorte même pas de la source, et donc que le pare-feu n'ait rien à bloquer.