TuringFan

Bonjour, J'ai suivi le tuto mais j'ai une erreur lors du déploiement du certificat (méthode ajout) : Unable to authenticate to localhost:5001 using https. Savez-vous d'où cela peut venir ? J'ai probablement un problème côté caractères spéciaux que j'utilise pour mon login et/ou mdp. @oracle7 mentionne en effet le fait "d'échapper des caractères spéciaux" mais je ne comprends pas ce que cela veut dire. Quelqu’un pourrait il m'aider svp ? Merci d'avance,

Bonjour @oracle7, Merci pour ce super tuto que je suis en train d'appliquer pas à pas car je ne maitrise pas du tout le SSH et que j'ai en tête sa potentielle dangerosité si mal utilisé. Quelques questions mineures : A quoi va service cette adresse email ? Comment peut on la changer ensuite ? Pas super clair pour moi cette partie. Je comprends que cela sert à deux choses : ne pas avoir à retaper le code d'authentification à chaque fois et ne pas bloquer le déploiement du certificat. C'est bien cela ? Comment faire si justement on souhaite avoir à renseigner le code d’authentification systématiquement ? Comment faire si nous n'utilisons pour le moment pas la double authentification mais que dans le futur nous la mettons finalement en place : quels sont les manipulations coté certificat ? Encore merci pour ce super tuto, clairement un cran au dessus de ceux que j'ai fait jusqu'à maintenant, et qui a dû demandé beaucoup de travail et de temps de préparation .

@oracle7 et @GrOoT64, Complètement d'accord, je préfèrerais en invisible mais justement je ne parviens pas à avoir quelque chose d'opérationnel en dehors de la configuration visible permanente. Preneur de vos commentaires.

Merci @maxou56, Je vais de ce pas le modifier. Si je comprends bien le pare-feu du RT laisse l'accès ouvert par défaut depuis le LAN mais pour le parefeu du NAS il faut créer des règles même pour un accès depuis le LAN ? Concernant la modification du numéro de port, j'ai cru comprendre d'un post de Fenrir que cela amène plus de complexité que de sécurité car un scan de port est très rapide. Merci d'avance,

Merci @oracle7, Réponse au top comme d'hab ! Si je ne dis pas de bêtise donc, on passera dons tous au moins une fois par cette étape : lors de la première connexion ? Je crois que Fenrir explique que dans certain cas c'est la seule solution pour débugger ta machine mais effectivement dans un cas "grave" comme celui là on peut attendre d'être sur le LAN. A titre personnel j'ai ouvert le 22 sur NAS et RT uniuement aux IP de mon LAN.

Merci @GrOoT64, Il faut faire une redirection de qqelle nature : site web ? De mon côté j'ai l'impression que seuls les redirections visibles (l'URL change effectivement dans la barre d'adresse du navigateur) fonctionnent et que pour le client il faille indiuer la véritable adresse.

Bonjour, Super tuto que j'ai suivi a priori avec succès (dans le cadre d'un autre tuto sur les certificats wilcard de @oracle7 qui y fait référence). Je suis novice en réseaux et je souhaite comprendre ce que je fais. Le SSH est de langage utilisé pour directement parler au terminal du NAS / RT émulé par PuTTY ou WinSCP : est-ce bien ça ? Je ne maitrise pas du tout le sujet des clefs : pourquoi utiliser des clefs et en installer une sur le NAS / RT plutôt que de se contenter d'un accès avec logins + mdp ? Une fois la clef publique installée sur le NAS, et sous l'hypothèse que nous perdons la clef privée et/ou la passphrase associée, serait il possible de faire un reset du SSH et de recréer des clefs ? Pourquoi modifier le port 22 par défaut ? je croyais avoir lu un commentaire de Fenrir qui expliquait qu'une modification des ports par défaut était quasi inutile et apportait plus de complexité qu'autre chose car un scan des ports peut se faire très rapidement. Qu'en est il ? Un scan des ports permet il en plus de dire si le port est ouvert ou non à quoi il sert (ex : utilisé pour le SSH) ? Enfin sur j'ai changé le port SSH sur mon RT mais en choisissant d'ouvrir dans mon parefeu le port lié au service SSH (uniquement pour dfes IPs du LAN) mon nouveau porte apparait bien tout en conservant le port 22 (si je veux uniquement mon port personnalisé sans le 22, je dois le mettre à la main) : savez vous pourquoi ? @oracle7 preneur d'une de tes explication simple et efficace si tu en as une en stock. Merci d'avance à tous,

J'ai directement tapé https://ndd.tld:noportSSLVPN dans mon navigateur. Un de ces 4 preneur d'une explication sur la fameuse exception de sécurité si quelqu'un à une réponse mais c'est purement par intérêt intellectuel car cela fonctionne bien. Idem sur iPad/iPhone

@GrOoT64 et @oracle7, Juste pour info je vous avais parlé d'une histoire d'exception de mon navigateur demandé lors de l’installation de mon client Windows. J'ai refait l'installation mon client VPN (qui est bien fonctionnel) en faisant une capture d'écran : je faisais référence au point 2.

Merci @oracle7 Idem, c'était un exemple générique pour bien comprendre. Top, je vais le faire de ce pas pour le SRM et le DSM. Si je comprends bien c'est un plus (que je vais faire) mais sur le papier ma configuration P3 uniquement (sans P1) est déjà théoriquement bloquante ? Mon idée n'a peut-être aucun sens, en gros je voulais savoir si je pouvais éviter d'avoir à préciser le port de mon SSL VPN quand je tape https://ndd.tld:XXXX dans mon navigateur pour à la place taper quelque chose du type "https://vpn.ndd.tld" ? Au même titre que j'utilise un reverse proxy pour renvoyer sur des appli sans préciser le port. Merci encore !

Bonjour à tous. Merci pour ce tuto très clair, je l'ai suivi (a priori avec succès). J'ai maintenant des petites questions d'ordre générales pour voir si j'ai bien compris ce que je faisais (je suis débutant en réseau). Pour la création d'un reverser proxy sur l'adresse "cible.ndd.tld", il faut donc trois prérequis : P1 (facultatif) : Créer une ressource de type A ou CNAME chez son Registrar P2 (obligatoire) : Adapter son certificat P3 (obligatoire) : Créer une ressource de type A sur son DNS (si on en a créé un avec une vue locale / VPN par exemple) En effectuant P3 mais pas P1 le reverse Proxy ne se fera qu'en local ou en VPN (accès au SRM / DSM par exemple) : impossible d'y accéder depuis l’extérieur. En effectuant P3 et P1 on permet l'accès à l'application concernée depuis l'extérieur. Dans tous les cas webstation force la redirection vers le port 443 pour accéder au reverse proxy. Une fois arrivé au reverse proxy plus besoin du https car déjà en local, la destination est donc en http pour ne pas dégrader les performances. D'une façon générale, en donnant accès à une application à un utilisateur depuis l’extérieur (Video Station par exemple) celui-ci n'aura pas accès en lecture/édition/suppression (sauf lecture des vidéos dans cet exemple évidemment) aux autres données et applications du réseau (dont les données du NAS, le DSM et le SRM). Ces 5 affirmations sont elles justes ? Enfin, une autre question (peut-être sans véritable sens). Je suis utilisateur du protocole SSL VPN de synology : concrètement je me connecte à un portail en "https://ndd.tld:XXXX" pour me connecter en VPN à mon NAS. Est-il possible d'utiliser un reverse proxy pour n'avoir qu'à taper "https://vpn.ndd.tld" et accéder au portail VPN ? Ce qui me parait difficile à gérer c'est l e va et vient entre l'IP privée et publique. En effet ndd.tld pointe vers mon IP Publique chez mon registrar mais une fois arrivé au reverse proxy j'imagine que ce sera mon DNS qui sdera utilisé et qui lui pointe vers mon IP locale. Comment ensuite repartir vers mon IP Publique pour accéder au portail VPN de synology ? @GrOoT64 et @oracle7 peut être une idée sur ce point spécifique ? Merci d'avance,

Yes ça marche ! Merci encore à toi @GrOoT64 et à @oracle7 !

Oui j'avais fait une erreur sur mon post (j'ai fait un edit) mais c'est bon chez mon registrar

ok merci, Par hasard une idée de ce qui pourrait clocher sur mon reverse proxy ?

Je suis maintenant convaincu ... Ok mais si "le pirate" s'amuse a scanner ton IP externe et qu'il tente port par port ça revient au même non ?

@GrOoT64, Concernant le cas des certificats wildcard cela semble en effet un plus en terme de sécurité. Je n'y connais pas grand chose mais dans le cas d'une personne mal intentionnée ne serait-ce pas simple pour elle de retomber sur une information équivalente à la liste exhaustive de tes sous domaines en scannant les ports ouverts ? Il pourrait comme cela méthodiquement essayer de rentrer port par port non ? Quel serait le danger supplémentaire à ce qu'il obtenne la liste exhaustive de tes sous domaines ? Oui pardon tu as raison. Je fais un edit dans mon post.

Bonjour, Je viens de suivre ce tuto pour File Station en utilisant le port 45002 et le nom d’hôte "files.ndd.tld" (pour info mon NAS est accessible à monNAS.ndd.tld). Problème en tapant https://files.ndd.tld dans mon navigateur j’obtiens une erreur "adresse intourvable". Edit : Coté regristrar je fais pointer un CNAM "*.ndd.tld" vers mon A "ndd.tld" qui pointe vers mon IP externe. Sur mon NAS j'ai désactivé la redirection du HTTP vers le HTTPS. Mon NAS est derrière un RT lui même en DMZ de ma Livebox : je n'ai rien fait sur la Livebox et j'ai transféré les ports 80 et 443 vers mon NAS sur le RT. les ports 80 et 443 sont ouverts sur mon NAS. Avez-vous une idée de ce qui peut clocher ? @oracle7 et @GrOoT64 peut être ? Je sais que vous avez pas mal regardé le sujet. Cordialement,

Si via les ports 80 et 443 pour NAS + RT ou ceux du DNS / VPN pour RT C'était juste pour comprendre, je vais de toute façon créer un reverse proxy. Dsl mais j'en suis encore aux basiques du NAS : je comprends de ta configuration que le papier des accès externes libres de tiers au NAS via des applications non critiques (autres que DSM, FileStations ou SSH) sont sûres et ne permettent pas de corruption du NAS (virus, corruption de la donnée, etc.). Encore une fois je sais que c'est la base (que je n'ai pas) mais une fois rentré par une application quelconque dans le NAS le périmètre d'action de l'utilisateur et son accès aux données reste limité à cette seule application (mur de chine dans le NAS) ? Concrètement si je donne un accès ouvert au monde à vidéo station : "tout le monde" ne pourra pas faire plus que rajouter, lire ou supprimer des vidéos ?

Merci encore à tous les deux @GrOoT64 et @oracle7, Une dernière question sur le sujet pour la forme (vous m'avez convaincu sur le reste) : Pour le moment je n'ai pas de reverse proxy mais j'ai l'impression de déjà avoir cette protection. En effet ndd.tld, monNAS.ndd.tld et mon RT.ndd.tld pointent chez mon registar vers mon IP externe (actualisée grâce au DDNS de mon RT). Il n'y a que mon DNS qui fait le différence entr eles 3 IP locales, hors celui-ci filtre les IP externes. Donc, pour le moment, chez moi la connaissance de mes "sous domaines" ne procure pas plus d'info. Dans ce cas avons nous une sécurisation équivalente puisque chez mois aussi monNAS.ndd.tld ne fonctionne pas en dehors du LAN/VPN ?

Merci à @GrOoT64 et @oracle7, Quel est l'intérêt, à titre personnel je vois plutôt ça comme un point positif de mettre les clients VPN sur des IPs spécifiques qui permettront un traitement spécifique justement (règle de pare-feur) etc. Mais il y a peut-être autre chose qui m'échappe ? Concernant SSL VPN, je suis d'accord, beaucoup plus simple à paramétrer mais deux questions : le fait de passer par le navigateur n'induit il pas une faiblesse supérieure à l'utilisation d'un client lourtrd comme en OpenVPN et/ou L2TP/IPSec ? Quid des licences, sont elles gratuites jusqu'à Septembre puis payantes ou jusqu'à septembre est il possible d'obtenir des licences gratuites à vie ? Autre question annexe : quelle est la différence entre le SSL VPN et le Web VPN : pas besoin de client pour le second ? J'ai effectivement essayé avec les deux pour comparer mais je suis en UDP mtn. Concernant le dhcp, même sans paramétrage spécifique j'obtiens une IP cohérente de mon client peux accéder à mon NAS et ma Livebox via des nom de domaine. Le seul véritable problème reste l'accès au RT. Preneur si quelqu'un trouve une explication / solution (je pense qu'il y a effectivement quelque chose du côté IPv4 IPv6) mais pour le moment je vais passer sur mon prochain sujet : le reverse proxy pour ne pas à avoir à spécifier les ports dans mes adresses.

@GrOoT64, Voici un petit retour d'expérience. J'ai redémarré tous mes appareils dont mon RT. J'ai configuré OpenVPn et L2TP/IPSec. Première bonne nouvelle : après de très nombreuses tentatives aux comportements erratiques (succès / échec des connexions sans modif des configurations) j'arrive enfin à me connecter (accès internet, même Ip que mon RT) via les deux protocoles depuis au moins un client : les serveurs sont donc bien configurés. En revanche j'arrive à me connecter au NAS mais pas au RT (j'y suis arrivé à de rares occasions mais pas répétable ce qui fait pensé au problème que nous avions avec les serveurs VPn sur le NAS avec @oracle7). En regardant les log de l'OpenVPN je me suis rendu compte que le protocole utilisé était parfois de UDPv6 bien que je n'ai activé l'IPv6 sur aucun de mes appareils (Livebox, RT, NAS) ! Ce qui m'a donné l'idée d'aller regarder mon pare-feu : > En appliquant la règle générée par la notification du paquet VPN Plus (1194 TCP/UDP ouvert pour toutes les sources vers SRM en destinataire) : connexion VPN fonctionnelle > En appliquant le même règle à la main et en désactivant la précédente : connexion VPN non fonctionnelle En fait en créant la règle à la main je pointais en IP de destination vers l'IP locale du RT soit un IPv4 et je pense que la règle automatique vers SRM pointe vers une IPv4 et une IPv6 ! Bref, ma conclusion pour le moment (peut-êt.re fausse) est la suivante : Les paquets VPN Synology utilisant des protocoles standards pourraient avoir un problème de gestion IPv4 IPv6 qui rend les connexions instables. deux choses que je ne comprends pas : 1 - Pourquoi j'ai accès à mon NAS et non à mon RT : sur les deux l'IPv6 est bloquée. Si je résous ce problème mes VPN seront parfaitement fonctionnels. 2 - Pourquoi @GrOoT64 n'a pas ce types de problèmes, c'est peut être d'autres paramètres ailleurs qui résolvent ces sujets d'IPv4 et IPv6. Par curiosité quelle est ta configuration du paquet VPN Plus dans Centre réseau > Sécurité > Sercvice ? Quelle est ta configuration dans configuration dans Centre réseau > Sécurité : section Pass -through ? Quelle est ta configuration dans Centre réseau > Internet : section Interface principale > Bouton Configurer IPv6 ? Quelle est ta configuration dans Centre réseau > Réseau Local > Onglet IPv6 ? De mémoire, @oracle7 avait mentionné un sujet de bug VPN en rapport avec avec les IPv4 et IPv6. Je reviens vers vous dès que j'en sais plus : j'ai toujours pour ambition d'utiliser OpenVPN et L2TP/IPSec. Cordialement,

J'ai essayé les deux : même combat !

Sur l'un de mes clients j'ai conservé la même configuration qu'avec le NAS (même IP externe) j'ai simplement changé mes logins. 9a fonctionnait sur le NAS plus sur le RT. sauf erreur de ma part non.

@GrOoT64 Similaire de mon côté. Et la réponse du scan.

Oui j'ai modifié IP Server par mon ndd.tld et j'ai décommenté gateway redirect : mais le problème vient viqsiblement du parefeu, j'ai ouvert le port 1194 et pourtant les scan indiquent qu'il est filtré ...