.Shad.

Si je suis cette vidéo, c'est un virtual server que tu dois créer du coup, et pas un port triggering comme dans ton impression d'écran. Il ne faut rien mettre dans la DMZ du routeur en effet. Vu de loin oui, vu de près non. Quand tu es en bridge mode, ce n'est plus juste un transfert de toutes les règles NAT vers le périphérique mis dans la DMZ. C'est la possibilité d'obtenir directement sur la patte WAN une IP publique de la part de ton FAI. Le modem n'est vraiment plus que là pour la connectivité avec le FAI, tout le reste est délégué au routeur en aval. Ils sont encore meilleurs en Belgique. 😉 La règle avec le port source n'a pas lieu d'être, car le client utilisera le port qu'il veut au sortir de sa machine. Tu peux également limiter à TCP au lieu de TCP/UDP. Je ne vois le 32401 nulle part dans leur doc : What network ports do I need to allow through my firewall? | Plex Support A priori, en l'état, si ton serveur est déjà configuré (il faut se connecter à l'UI la première fois localement pour "claim" le serveur), tu devrais pouvoir y accéder via http://IP_PUBLIQUE:32400 Remarques : Il est plus pratique d'avoir un petit nom de domaine pour atterrir chez soi, Synology en fournit un gratuitement, ou tu peux en acheter un pas cher (quelques € par an) Pas de chiffrement des données en l'état Oui, il faut un peu de temps pour bien comprendre comment ça fonctionne, donc pas de précipitation. 😉

Bienvenue parmi nous !

Hello, Si tu parcours le sujet sur la sécurité donné par @Mic13710 dans ta présentation, tu y liras que la "configuration du routeur" une fonction à proscrire car faille de sécurité majeure. N'importe quel malware pourrait ouvrir ton NAS à tous les vents. La redirection de port ou port forwarding est quelque d'assez simple à mettre en place. Est-ce que ton routeur vient se placer derrière ta box ? Si oui, je te conseille de placer ton routeur dans la DMZ de la Livebox, et tu pourras supprimer tes redirections de port dans celle-ci. Car c'est vers le routeur que tous les ports seront automatiquement redirigés. Dans ton routeur TP-Link, ce n'est pas du port triggering que tu dois mettre en place mais du port forwarding. Le port triggering est une ouverture qui se déclenche à la demande, mais la demande doit venir de l'intérieur du réseau et pas de l'extérieur. La règle est sensiblement la même que celle dans ton port triggering. Donc DMZ Livebox -> Routeur + règle de port forwarding du port 32400 => tu arrives aux portes du NAS. A ce niveau-là, il te faudra autoriser le port 32400 pour les IP qui t'intéressent, donc j'imagine les IP locales + par exemple une géolocalisation française. Normalement, tu seras en mesure d'accéder à ton NAS à distance en liaison directe après avoir vérifié tous ces points. En l'état, ce sera une connexion HTTP, pas HTTPS, ce qui présuppose qu'un Man In The Middle (MITM) pourrait intercepter tes identifiants, même si c'est peu probable. Si vraiment tu veux avoir un accès distant robuste, mes conseils : Te concentrer sur la sécurité et la surface d'exposition de ton NAS via le tutoriel : [TUTO] Sécuriser les accès à son nas - Tutoriels - NAS-Forum Appliquer ce que je t'ai dit plus avant, et vérifier que l'accès distant est fonctionnel Désactiver l'accessibilité du port de Plex à distance temporairement dans le pare-feu du NAS Mettre en place le proxy inversé pour sécuriser ton accès distant : [Tuto] Reverse Proxy - Tutoriels - NAS-Forum

Bienvenue parmi nous ! 🙂

Tu peux aussi apporter ton témoignage sur le sujet suivant, qui sait ce qui pourrait en ressortir :

Si tu es prêt à mettre les pieds dans Docker, tu peux très bien créer un conteneur intégrant un soft de download (Deluge, qBittorrent, etc...) couplé à un client VPN. Par exemple : binhex/arch-delugevpn - Docker Image | Docker Hub Et niveau ressources c'est peanuts.

@MilesTEG1 Beau boulot, remarques : Avoir UseTLS et UseSTARTTLS simultanément est contradictoire. Si tu utilises le port 587 c'est STARTTLS et tu peux désactiver UseTLS. Attention aux droits lorsque tu montes le fichier ssmtp.conf sur ton NAS Ajouter des DNS n'est utile que s'ils diffèrent de ceux utilisés par la résolution DNS Docker, qui se base sur celle de l'hôte.

Bienvenue parmi nous !

Cette suggestion n'avait rien à faire là. On n'installe pas des paquets sur un SSD externe, ni sur un HDD d'ailleurs. Il parlait d'un volume de SSD. C'est une discussion complètement différente qui n'a rien à faire ici. Si tu m'envoies un lien TeamViewer par MP je veux bien regarder. La discussion tourne en rond ici.

Voir mon impression d'écran et mes explications dans mon message de 21h21 hier. Ce serait bien de créer un autre sujet non ?

@ewfzapp J'ai rien pigé rien ne fonctionne c'est un peu vague. Ca coince où ? Qu'est-ce que tu ne comprends pas ?

Hello, bienvenue parmi nous. Mince @oracle7 tu as été devancé ! 😄

Oui il y a moyen, mais ça ne devrait pas être nécessaire dans ton cas. Car tout l'intérêt est d'utiliser la résolution DNS interne de Docker pour éviter d'avoir à jouer avec les IP. C'est ce qui se passe quand tu renseignes comme nom d'hôte pour la base mysql "mediawiki-db" comme nom d'hôte pour ta base mysql. S'il n'y avait pas cette résolution interne tu devrais renseigner l'IP bridge correspondante. Pour le reste, je n'avais pas répondu, mais ok 👍 Pour l'erreur, il y a vraissemblablement un problème de connectivité avec le container MariaDB. Là je cale, à part faire un partage d'écran (idéalement pendant le week-end en soirée pour moi), je ne vois pas trop comment te dépanner plus avant.

C'est normal car ton NAS n'étant pas joignable depuis l'extérieur, les serveurs de Synology font office de relais entre ton NAS et le client qui tente d'y accéder. Pour du travail bureautique ça fait l'affaire, pour du stream c'est un peu plus compliqué. 😉

Alors je ne m'explique pas pourquoi ça ne fonctionne pas sans ta règle 7, ou je loupe quelque chose de gros comme une maison. Si tu veux on peut faire un Teamspeak à l'occasion pour voir pourquoi ça ne fonctionne pas sans cette règle.

Hello, Mon NAS étant à la cave, et mon PC de bureau 2 switchs plus loin, je n'ai pas prévu actuellement prévu d'investir dans du 2.5 Gbps. Donc je ne le testerai sûrement pas avant quelques temps. Si j'ai bien compris le fonctionnement, le but est justement de répartir un même transfert sur plusieurs interfaces, donc exploiter les multiples interfaces 1 Gbps de ton NAS. Le PC lui doit être connecté à un port 2.5 Gbps. Donc le minimum est d'avoir un switch avec 1 port 2.5 Gbps et plusieurs ports 1 Gbps pour le NAS. Je ne sais pas si ce genre de produit existe. De ce que j'ai vu, un switch 2.5G n'a a minima que des ports 2.5G, voire du 10 Gbe ou du SFP+. Pour exploiter SMB Multichannel, de ce que disait @maxou56, il ne faut pas utiliser de bond, mais chaque interface doit avoir sa propre IP. Pour les règles de pare-feu, je pense qu'elles seront transférées sur une des voir chacune des interfaces.

Bon je viens de tester vite fait ça fonctionne très bien sans port supplémentaire que le port choisi sur mon NAS (45080 dans mon cas) pour atteindre le port 80 du conteneur. C'est dans la règle 2 que tu autorises "théoriquement" l'accès à Mediawiki, je dis théoriquement car il faut s'assurer que c'est bien le bon port qui est associé. Quel est le port repris pour l'application "Docker Mediawiki" dans le pare-feu Synology ? Ca devrait être le 8795. Pour revenir à la règle 7, elle dit que 172.20.0.3 peut accéder à tous les ports du NAS. Or, tu ne fixes nulle part l'IP du conteneur Mediawiki dans ton fichier compose, donc lors d'une re-création du conteneur l'IP pourrait changer. Mais surtout, Mediawiki n'a besoin d'accéder à rien du tout sur le NAS, car il communique directement avec MariaDB via le réseau bridge, c'est pour cette raison qu'on ne translate pas le port de MariaDB du conteneur sur le NAS, on n'en a pas besoin. Sauf bug du pare-feu (voir ma question au premier paragraphe), ta règle 2 est suffisante pour garantir l'accès à Mediawiki. Je confirme, le raisonnement est cohérent, à condition que tu évites d'accéder aux applications en HTTP. Je ne suis pas partisan du VPN à tout prix, donc ce n'est pas moi qui te le conseillerai. En revanche, tu pourrais tout autant bloquer la Chine, la Russie, la Corée du Nord, le Pakistan, etc... dans ta première règle. Et ca commence à être peu commode à gérer. Au passage, tu gagnerais sûrement beaucoup à utiliser le proxy inversé de DSM, il vaut mieux avoir une seule porte très solide qu'une multitude de portes qui le sont moins.

Sur lafibre.info ils évoquent le fait que Free utilise eu CGNAT pour son offre 4G, mais je ne trouve rien de plus récent que 2020, est-ce d'actualité ? A priori la pénurie d'IPv4 ne s'améliore pas donc j'imagine que oui. Tes options sont limitées en ce cas. Vérifier peut-être avec Free déjà.

Hello, ok j'avais peur que ce soit moins réfléchi que ça. Je vais essayer d'installer Mediawiki et voir pourquoi tu aurais besoin de cette règle.

Tu es derrière du CGNAT, d'où l'IP privée. Voo en Belgique ?

Ca confirme ce que je pensais 😛 ton pare-feu est sens dessus dessous. La logique d'un pare-feu c'est d'autoriser tout ce qu'on veut autoriser, et d'avoir une règle de refus général à la fin, c'est une architecture saine et lisible. Concernant ta règle concernant l'Iran, elle est là j'imagine pour empêcher d'accéder aux applications listées dans la règle 2, qui elles, sont ouvertes au monde entier. Ne serait-il pas plus judicieux de supprimer la règle 1, et de limiter les applications de la règle 2 aux pays dont tu souhaites autoriser l'accès à ton NAS ? Ok pour la règle 3, si le NAS est la cible d'une sauvegarde d'un périphérique ayant pour IP 192.168.0.11 Intérêt des règles 4 et 5 ? Est-ce que le but est d'autoriser l'accès à Portainer uniquement depuis 2 IP locales sur 2 réseaux différents ? La règle 6 dit qu'elle autorise Mediawiki à communiquer avec Mediawiki uniquement s'il passe par son IP bridge Docker. Moi quand je dois monter à l'étage de ma maison, je ne sors pas pour sonner et re-rentrer, je monte directement, ça revient à utiliser localhost 127.0.0.1 pour le conteneur. Et cette règle n'a pas d'intérêt car tu as déjà autorisé l'accès à Mediawiki à toutes les sources dans ta règle 2. La règle 7 ne sert à rien. Ok pour la règle 8. Si tu détailles ce qui doit avoir accès à quoi, je peux t'aider à reconstruire tes règles, en l'état tu es à deux doigts de te bloquer en dehors du NAS, et ton NAS est ouvert à quasiment tous les horizons.

Tu utilises un nom de domaine en .org et tu n'as aucun certificat correspondant dans ton NAS. Donc normal que tu aies un avertissement. Plusieurs solutions : - La plus simple : Utiliser le NDD Synology, demander un wildcard plutôt qu'un certificat avec domaines nominatifs, tu seras moins embêté par la suite si tu ajoutes une nouvelle application dans ton proxy inversé. Voir mon message plus haut pour la procédure à suivre. - Garder ton nom de domaine, il te faut dans ce cas-là t'assurer que le port 80 est ouvert sur ton NAS et redirigé depuis ta box, et tu suis la même procédure que pour le certificat LE pour ton domaine Synology, sauf que c'est pour ton ndd.org. Dans ce cas-ci, pas de wildcard, tu dois spécifier les sous-domaines pour lesquels tu souhaites que ton certificat soit valide. Si tu as besoin d'un autre sous-domaine, tu devras renouveler ton certificat en ajoutant à la liste des alias existants le sous-domaine désiré. - La plus complète : Mettre en place ACME via le tutoriel proposé plus haut pour obtenir un certificat wildcard pour ton ndd.org Dernière chose, quand tu auras un certificat qui couvre le nom d'hôte que tu vas utiliser pour ton instance de Vaultwarden via proxy inversé, il faudra associer cette entrée de proxy inversé au certificat, via le bouton Paramètres dans l'écran de gestion des certificats :

Il n'y a aucun autre port à ouvrir si on suit la doc que le port 8795 vers les IP de ton réseau local (sauf si tu tentes d'y accéder à distance), tu peux mettre une impression d'écran de ton pare-feu.

Pas eu le temps de te répondre, mais effectivement : - Supprimer le réseau macvlan, donc avant ça stopper les conteneurs - Supprimer l'interface virtuelle - Recréer le réseau macvlan - Recréer l'interface virtuelle - Relancer les conteneurs A priori rien d'autre. Il y a l'air d'y avoir ce qu'il faut pour ici : Guide ASUSTOR NAS MIB - ASUSTOR NAS

Cet article est encore un ramassis d'idioties. Désolé je n'aime pas être à ce point péremptoire mais là il n'y a pas d'autre mot. Il ouvre littéralement tout son NAS à toutes les IP roumaines. Même en hébergeant un site, on n'ouvre que les ports utiles à la navigation : 443 et éventuellement 80. Je te conseille de suivre ce tutoriel pour la configuration du pare-feu (entre autres), qui est une référence maintes fois éprouvée : ___________ Je me rends compte que j'ai lu de travers, il a effectivement bien nommé son conteneur mediawiki-db pour la base de données. Donc c'est ok de ce côté-là. 👌 Faute de frappe, je parlais du port 80 du conteneur, c'est ce que ton guide dit de faire, de mapper le port 8795 du NAS sur le port 80 du conteneur, c'est ta porte d'entrée vers Mediawiki. Toi, ce qui t'importe c'est à qui est accessible le port 8795 du NAS. Peut-être qu'il tente de bien faire, je n'en sais rien, en tout cas rares sont ses tutoriels sans erreur. Et ça n'incite pas du tout à essayer de comprendre ce qu'on fait. Le but c'est que tu y reviennes, encore et encore. Après c'est mon avis, d'autres sont sûrement plus indulgents, mais je trouve son travail souvent bâclé.