oracle7

@TuringFan Je constate que comme moi tu as eu droit à de multiples reboot usine pour y arriver. Quelque part cela me rassure et c'est bien un problème d'initialisation Synology et pas de notre fait. On se demande ce qui est fait car vu le temps que cela prend ! X ne peut être <> 1 mais forcément = 1 vu que la LB est en 192.168.1.1. Tu veux donc dire une " privée @IP internet" en 192.168.1.Y. N'oublies pas que le RT est un client du sous-réseau local de la LB. Dans la configuration Internet du RT, cela peut effectivement paraître bizarre de mettre une @IP privé pour joindre internet, je prends cela pour juste un abus de langage. Vers le RT. N'oublies pas non plus d'inclure le transfert des ports 80 et 443. OUI, puisque c'est celui du RT qui fait maintenant le boulot à la place de la LB. Sinon tes nouveaux clients de ton réseau local ne se verront pas attribuer d'@IP automatiquement. De plus si tu laisses deux serveurs DHCP actifs sur le même sous-réseau local, cela ne va pas le faire, tu auras des conflits d'@IP. Donc DHCP du RT = ACTIF et DHCP du NAS = INACTIF. Chez OVH, ndd.eu doit pointer (enregistrement A de mémoire) vers @IP externe de la LB (c'est le point d'entrée vers chez toi). Il n'y a rien à faire de plus sauf erreur de ma part (i.e. si tout est configuré correctement comme tu viens de le faire). C'est moi qui maintenant espère ne rien oublier ... Il faut avouer que ce n'est quand même pas simple tout cela, beaucoup de notions à intégrer en même temps, mais on y arrive avec un peu de méthode.😂 Cordialement oracle7😉

@AngesMortel Comme quoi un p'tit reboot parfois peu aider ...😅 Je n'en suis pas sûr et ne voudrais pas te raconter de bêtises (à vérifier donc) mais quand tu tapes \\mon_nas sous WIN, 'nom_nas' est recensé dans les noms NETBIOS et est donc associé à l'@IP locale du NAS (en 192.168.x.x). En mode VPN, ton NAS à une @IP toute autre (en 10.8.0.x) donc différente de celle enregistrée en NETBIOS donc WIN ne peut trouver via ce nom 'mon_nas' ... Dans ce cas tu accèdes au NAS en saisissant \\10.8.0.x sous WIN. Cordialement oracle7😉

@AngesMortel C'est tout ce qu'il y a dans ton fichier '.ovpn' ? ta copie d'écran est sûrement incomplète. Refais-la, sans bien évidemment ce qu'il y a entre les lignes '-----BEGIN CERTIFICATE-----' et '-----END CERTIFICATE-----'. Pour le port 1194 déjà utilisé, effectivement ce n'est pas normal. C'est normalement lui qui doit être utilisé pour OpenVPN. Essaies à tout hasard un reboot de la LB et de ton NAS (arrêt propre et marche) et vérifie s'il est toujours occupé. Cordialement oracle7😉

@AngesMortel Dans le parefeu du NAS vérifie les ports désignés par la ligne 'VPN Server, VNP Server, ...', je crains que cette ligne ne fasse doublon avec celle existant pour le port 1194. Limites aussi cette dernière à la France à moins que tu ne te connectes depuis l'étranger. Une seule ligne d'ouverture de port 1194 ou 1195 suffit, cela en cohérence avec ton fichier de configuration '.ovpn'. Mettre en accord le NAT/PAT dans la LB. Dans la configuration OpenVPN du serveur VPN, il me semblait qu'il fallait être cohérent entre les niveaux de chiffrement et d'authentification, alors pourquoi mettre authentification 'SHA512' pour un chiffrement 'AES-256-CBC' ? Ré-exportes alors la configuration OpenVPN et reprends ton fichier de configuration '.ovpn'. Après je penses que cela devrait aller mieux. @PPJP Désolé à mon tour, nos réponses se sont croisées ... Cordialement oracle7😉

@PPJP Bonjour, Sauf s'il a paramétré aussi un serveur VPN L2PT/IPsec. Sinon vous avez raison. Cordialement oracle7😉

@AngesMortel Bonjour, Quelques remarques : Je suppose que tu as modifié le port 1194 OpenVPN pour mettre autre chose : ce n'est pas une bonne idée car c'est le port de communication normal, d'où peut-être tes soucis. Il faut limiter à la France, l'ouverture des ports VPN : c'est déjà plus sûr ! Je vois que tu as ouvert aux "quatre vents" de l'extérieur ton port SSH. Là aussi TRES mauvaise idée. Ne t'étonne pas d'être rapidement attaqué depuis la Chine notamment et entre autres. Pour ta sécurité, ce port n'est à ouvrir que ponctuellement, le temps de faire la manipulation dont tu as besoin puis tu le refermes et désactives aussi le service SSH. Maintenant tu es seul maître de tes données ... Je ne vois pas l’intérêt sauf à avoir un certificat personnalisé (est-tu sûr ?), le certificat standard est déjà présent dans le fichier de configuration '.opvn' et est bien suffisant à mon sens. Par ailleurs, seule cette ligne d'ajoutée ?, je ne suis pas sûr mais je crains que ce ne soit incomplet. A vérifier dans la doc OpenVPN ... Relis bien ton mes message d'erreur (dernière ligne), la solution est là me semble-t-il ... Cordialement oracle7😉

@tchoumi23 Bonjour, Tu trouveras des éléments de réponse ici Cordialement oracle7😉

@AngesMortel l'@IP locale de ton NAS, puisque tu ouvres de l'extérieur vers l'intérieur. logique, non ? Si tu ne veux pas t'attirer "les foudres" d'un modo, évites aussi de citer tout le contenu des messages précédents. C'est très pénible visuellement et ça surcharge inutilement le sujet. Ne cites que la partie utile. Si tu veux interpeler quelqu'un, il suffit de commencer par "@" et les premières lettres du pseudo pour trouver et valider la personne concernée dans le popup qui apparait alors. Cordialement oracle7😉

@AngesMortel Bonsoir, Tu te connectes en mode admin à la LB Dans Réseau - NAT/PAT : Tu sélectionnes dans le popup, le service pour le quel tu veux ouvrir le port ou bien tu sélectionnes 'nouveau' et tu donnes un nom à ta convenance. Puis dans l'ordre port interne, port externe : tu sais le N° du port (le même pour les deux !). Tu sélectionnes ensuite le protocole à appliquer : TCP ou UDP ou les Deux Enfin tu saisis l'@IP de ton NAS ou son nom si tu l'as auparavant nommé dans 'Mes Équipements connectés' TU cliques sur créer pour valider ta saisie. Tu refais cela pour chaque port à ouvrir. Ce n'est pas plus compliqué ... Cordialement oracle7😉

@Thierry94 Bien vu, je n'avais pas percuté ! Cordialement oracle7😉

@Jcdusse44 Bonjour, Tu ne dis pas grand chose sur ce que tu as fais avant (tu ne facilites pas les réponses), toutefois, cette copie d'écran semble en elle même correcte si tu es certain d'avoir affecté précédemment le port 45000 à l'application Audio station, pour mémoire son port natif est normalement le 8800, mais pourquoi pas. Si c'est bien le cas, alors il te faut être cohérent avec ce que tu as renseigné dans l'onglet 'Application' pour l'application Audio Station. Cordialement oracle7😉

@TuringFan Pour bien comprendre tes soucis et pouvoir te donner la bonne réponse, il faudrait STP que tu me précises quelques points : Sur quel sous-réseau est ta LB ? 192.168.1.0 si tu as suivi la trame Quel sous-réseau est géré par ton routeur ? 192.168.2.0 si tu as suivi la trame As-tu créé un sous-réseau spécifique pour le WIFI invité ? Normalement si tu as suivi la trame, tu aurais dû avoir le message de recouvrement, c'est obligé ! Sinon, c'est le pourquoi de mes questions précédentes. Ce n'est pas que cela serve précisément à quelque chose, c'est plutôt une correction de configuration qu'il faut apporter. Néanmoins, saches que la réattribution d'@IP dans le réseau local est la conséquence de l’existence d'un recouvrement de réseau WAN et LAN. C'est la façon utilisée par l'assistant Synology pour remédier automatiquement à ce recouvrement. Pour éviter ce recouvrement, il attribue un sous-réseau LAN par ex en 10.x.y.z qui est par essence différent du sous-réseau WAN ( le WAN du RT est ici en fait le LAN de la LB) que l'on avait précédemment fixé soit 192.168.1.2 (pour mémoire à ce moment là le RT avait pour @IP LAN 192.168.1.1 et on fixait l'@IP 192.168.1.2 comme @IP WAN d'accès à Internet, en fait c'est aussi son @IPLAN dans le sous-réseau de la LB). D'où le recouvrement. Je sais c'est pas simple à appréhender ... Juste de la logique réseau. Je te conseille de faire un schéma avec les @IP, tu y verras tout de suite plus clair. OUI, puisque je suppose que le PC que tu utilises pour faire cela, est sur le sous-réseau LAN du routeur (i.e. il a une @IP 192.168.2.x). Ton routeur sert de passerelle qui te permet d'accéder à la LB. Dans le sens inverse, il faudrait que ton PC soit sur le sous-réseau LAN de la LB (i.e. qu'il ai une @IP 192.168.1.x) pour voir le RT mais il ne devrait pas voir plus loin en aval du RT. (à tester avec des ping pour confirmer) Cela, par contre, ne me parait pas normal. Le WIFI étant délivré par le RT, c'est le sous-réseau du RT qui s'applique donc en 192.168.2.0. Ou alors, c'est que tu utilises le WIFI invité du RT que tu aurais configuré, lui, en 10.x.y.z. Je ne vois que cette explication.🤔 Cordialement oracle7😉

@Mic13710 Je ne peux que t'approuver Cordialement oracle7😉

@cpc44 Super !!! Content pour toi. Cordialement oracle7😉

@cpc44 Bonjour, Il n'est pas recommandé de modifié les ports natifs de DSM (même si rien ne l'interdit). Voir le tuto sur la sécurisation des accès au NAS. Si c'est pour sécuriser l'accès externe à DSM, il est alors préférable de passer par un nom de domaine (nas.ndd.tld) et de configurer le reverse proxy pour passer du port 443 (nas.ndd.tld:443) vers le port natif 5000 (localhost:5000) de DSM. Il y a sur ce forum des tutos pour tout configurer cela. Lis-les bien et appliques-les et cela répondra à ta question initiale. Cordialement oracle7😉

@maxou56 Je vais donc suivre ton conseil avisé. Cordialement oracle7😉

@Mic13710 Pourtant, il me semble avoir lu ici que certains se targuaient qu'il existait des routeurs à moins de 50€ qui faisaient très bien le boulot (ce que je ne nie pas) .... Cordialement oracle7😉

@maxou56 Bonjour, Je ne sais pas, mais je me dis (peut-être à tord) comme je n'ai pas vu de possibilité de paramétrer ce type de réponse dans le RT cela ne veux pas forcément dire qu'il ne le fait pas par défaut comme tout périphérique Ethernet. En tout cas, chez moi il répond bien au ping sur le réseau local LAN du moins, c'est qui rassurant. Depuis le WAN, son @IP n'est-elle pas la même que la LB en amont ? Du coup je serais enclin à dire que ce serait elle (la LB) qui répond en premier malgré la DMZ. Mais ce n'est que mon avis, à confirmer donc ! Et si le réseau local WIFI est entièrement géré par des équipements Synology : alors pas de problèmes effectivement. Mais je ne comprends pas en quoi cela est gênant avec les clients ? Cordialement oracle7😉

@Mic13710 Bonjour, Je ne suis pas sûr que les autres box n'aient pas elles aussi de gros défauts. Cela dit, tu mets la LB en DMZ avec un routeur derrière pour faire tout le boulot à sa place et fini les problèmes 😀 Cordialement oracle7😉

@TuringFan Bonjour, Ci-après une trame à suivre si tu le veux, en tout cas c'est celle que j'ai personnellement suivie et çà marche pour le RT2600ac ! 1 - Préliminaires sur la LB Connecter un PC sur le port LAN2 de la LB. Laisser libre le port LAN1 de la LB Sur le PC fixer manuellement l'@IP du PC sur le réseau de la LB par ex 192.168.1.12 dans un navigateur se connecter à la LB 192.168.1.1 Faire une sauvegarde en local des paramètres de la LB Désactiver la sauvegarde automatique Réinitialiser la LB aux paramètres usine Quand la LB a redémarré, s'y connecter Dans "Réseau DHCP" : conserver la plage d'@IP par défaut 192.168.1.10 à 192.168.1.150, DHCP actif Dans "Réseau NAT/PAT" : fixer les ports à transférer vers le routeur (80, 443, 500, 4500, 1194 + éventuellement FTP 20, 21 et enfin SSH 22 ??? mais pas recommandé. Dans "Réseau UpnP" : activer le service (nécessaire pour le décodeur TV) Dans "Parefeu" : régler le niveau de sécurité sur "Faible" dans WIFI : désactiver les 2 antennes 2,4 et 5 Ghz Ne pas quitter l'interface d'administration de la LB 2 - Connexion du routeur à la LB (en espérant que c'est la même chose pour un RT2200ac que pour un RT2600ac !) Connecter le port WAN du RT au port LAN1 de la LB Démarrer le RT et pour être sûr de partir sur une base saine : réinitialiser le RT aux paramètres usine (Appui long 10sec sur le bouton "reset". Patienter plusieurs minutes ... C'est très long ! Sur le PC lancer une recherche avec Synology Assistant Le RT doit être trouvé à l'@IP 192.168.1.x, noter cette @IP Vérifier que l'@MAC est bien celle indiquée sur l'emballage du RT, (@MAC0 par la suite) 3 - Configuration LB Se connecter à la LB Vérifier dans "Mes Equipements connectés" la présence du RT (nommé SynologyRouter) Dans "Réseau DHCP" : attribuer un bail statique au RT par ex 192.168.1.2 Désactiver le serveur DHCP de la LB Redémarrer la LB Redémarrer le RT Patienter plusieurs minutes Vérifier avec Synology Assistant que le RT est bien trouvé à l'àIP 192.168..2 avec l'@MAC0 Se connecter à la LB Dans "Réseau DMZ" : intégrer le RT à la DMZ : sélectionner SyologyRouter dans le Popup 4 - Configuration du RT Déconnecter le câble réseau du PC du port LAN2 de la LB et le brancher sur le port LAN1 du RT Sur le PC lancer une recherche avec Syology Assistant. Le RT doit être trouvé à l'@IP 192.168.1.1 avec l'@MAC1 correspondante du port LAN1 du RT (ce sont des paramètres usine non modifiables !) Dans un navigateur se connecter au RT (192.168.1.1 ou router.synology.com) Dés la connexion établie cliquer sur Démarrer Suivre et renseigner les écrans selon Sélectionner mode de fonctionnement "RT sans fil" et désactiver "Accès externe à SRM" Sélectionner le type de connexion Internet "IP manuelle" Saisir @IP 192.168.1.2 masque 255.255.255.0 Passerelle : @IP de la box (normalement 192.168.1.1) DNS Server : 192.168.1.1 Définir comme valeur par défaut : activé Appliquer Un message de notification de l’assistant SRM indique alors que les sous-réseaux WAN et LAN spécifiés se recouvrent, ce qui peut bloquer la connexion à Internet. Pour mémoire, cette alerte est normale et logique puisque l’actuelle @IP de connexion pour configuration du routeur est « 192.168.1.1 » et que l’on est en train de définir l’@IP « 192.168.1.2 » comme @IP de connexion à Internet, ces deux @IP appartenant au même sous-réseau « 192.168.1.0 », d’où le recouvrement). Nota : Pour éviter cette notification, une autre solution aurait été de fixer au départ le sous-réseau de la LBen « 192.168.0.0 » avec pour l’@IP de la LB« 192.168.0.1 » et de fixer l’@IP du bail statique du routeur à « 192.168.0.2 ». Pour ma part je ne voulais pas reprendre tout le plan d'adressages de mes clients, d'où ce choix. L’assistant SRM propose alors de corriger cette anomalie en créant lui-même un autre sous-réseau LAN. Cliquer sur « OUI » pour accepter la correction de configuration. L'assistant poursuit la configuration du RT. Patienter plusieurs minutes, c'est assez long !!! A la fin, cliquer sur "Lancer le RT" Le sous-réseau LAN du routeur étant différent du sous-réseau LAN courant du PC, l’interface SRM ne s’affiche pas. Logique ! Sur le PC, lancer une recherche avec Synology Assistant : Le routeur doit être trouvé avec l’@IP du sous-réseau LAN que l’assistant SRM lui aura attribué, par exemple : 10.0.14.1 avec l’@MAC1 (@MAC du port LAN1 du routeur). Sur le PC, fixer manuellement l’@IP du PC (par ex : 10.0.14.12) sur le sous-réseau LAN du routeur (10.0.14.0). Ouvrir un navigateur WEB, se connecter au routeur avec le compte administrateur spécifié précédemment, en saisissant l’URL : "http://10.0.14.1:8000". Ouvrir "Centre réseau – Statut" et vérifier que le routeur est bien connecté à Internet. ⚠ L’affichage de l’état de la connexion n’est pas instantané il faut patienter quelques secondes. Ouvrir "Centre réseau – Internet" et vérifier que le routeur utilise bien l’@IP qui lui a été attribué dans le sous-réseau de la LB : 192.168.1.2. Ouvrir "Centre réseau – Réseau local" et modifier les paramètres de sous-réseau local du routeur pour lui attribuer l’@IP : 192.168.2.1. Renseigner en corrélation du sous-réseau 192.168.2.0, les @IP de la plage du serveur DHCP (fixées de 192.168.2.150 à 192.168.2.254) ainsi que celles de la passerelle (192.168.2.1) et du serveur DNS (192.168.2.1). Nota : Les @IP inférieures à 150 sont réservées pour les « Réservations DHCP » (@IP constante de certains périphériques) ce qui laisse pas mal de marge. Modifier l’@IP du serveur DHCP invité pour lui attribuer l’@IP 192.168.3.1. De même, renseigner en corrélation du sous-réseau 192.168.3.0, les @IP de la plage du serveur DHCP invité (fixées de 192.168.3.2 à 192.168.3.254) ainsi que celles de la passerelle (192.168.3.1) et du serveur DNS principal (192.168.3.1). Cliquer sur Appliquer pour enregistrer les modifications. Redémarrer le routeur. Dans un navigateur se connecter au RT : "http://192.168.2.1:8000" ou "router.synology.com" Poursuivre le paramétrage et la sécurisation du RT sur la base du Tuto de @unPixel Voilà, c'est un peu long, il faut "jongler" avec les sous-réseaux, mais si tu es attentif cela ne devrait pas te poser de problèmes. EDIT : Penser aussi à attribuer un bail statique dans la LB au décodeur TV ainsi que rétablir/activer le DHCP de la LB qui nécessaire au fonctionnement du décodeur. Cordialement oracle7 😉 @GrOoT64 Mes réglages WIFI : Pour les autres cases, tout est coché sauf le calendrier. Cordialement oracle7😉

@Pacha54 OK merci pour ta réponse. Mais cette "@IPv6 du NAS" dont tu parles, pour bien comprendre, ce n'est pas son @IPv6 sur le réseau local de la LiveBox ? Ne serait ce pas plutôt l'IPv6 externe de la LiveBox ? (pour l'IPv4 c'est cette @IP externe que l'on met en enregistrement A chez OVH, donc par analogie, mais je me trompe peut-être ...) Cordialement oracle7😉

@Pacha54 Bonjour, Par pure curiosité, pourrais-tu STP préciser cette création de champ AAAA : où exactement ? dans le serveur DNS du NAS ? Dans la zone DNS de OVH ? Je souhaiterai comprendre. Merci. Cordialement oracle7 😉

@TuringFan Bonjour, J'ai créé dans DNS Serveur des zones spécifiques (à l'image de celle pour le réseau local en 192.168.x.1 i.e. les mêmes règles CNAME pour les "sous-domaines"). Une zone pour OpenVPN vers l'@IP 10.8.0.1 et une zone pour L2PT/IPsec vers l'@IP 10.2.0.1 (i.e. seul l'enregistrement "A" diffère). J'ai aussi créé dans DNS Serveur des vues spécifiques OpenVPN et L2PT/IPsec avec toutes les deux comme @IP source le réseau 10.0.0.0/8 et chacune ce ces vues pointe sur la zone DNS correspondante sus-citée. Pour mémoire, la vue "réseau locale" a pour @IP source les réseaux locaux privée 127.0.0.0, 172.16.0.0, 192.168.x.0 et fe80:... pour l'IPv6. Dans VPN Serveur, OPenVPN est réglé sur 10.8.0.1 et L2PT/IPsec sur 10.2.0.1. Si j'ai bien compris le mécanisme, avec le reverse proxy la destination de redirection "localhost:port" s'adapte selon l'@IP locale que ton NAS peut avoir hors ou avec VPN (192.168.x.x:port ou 10.8.0.1:port). Ainsi,j'accède au NAS hors ou avec VPN via https://nas.ndd.tld depuis l'intérieur et depuis l'extérieur. En espérant ne rien avoir oublié. Ainsi Cordialement oracle7😉

Bonjour, Je me répond à ce sujet car la solution qui m'a été soufflée par @TuringFan (encore Merci à lui) est la suivante : il suffit de décocher (i.e. si elle l'était) la case "Activer les passerelles multiples" dans "Panneau de configuration / Réseau / Général / Paramètres avancés" Et la miracle ! j'ai de nouveau accès (via "https://nas.ndd.tld") depuis l'extérieur à mon NAS avec une connexion OpenVPN active. Merci aussi à @.Shad. pour son aide. Cordialement oracle7😉

@GrOoT64 Bonjour, On ne peux pas désactiver le parefeu de la LiveBox, tout au plus tu choisis l'option "Niveau de sécurité : Faible". Cordialement oracle7 😉