dd5992

@Superpa: Je n'ai pas (encore) implémenté de VPN, mais à lire ce forum, il semble qu'il n'y ait pas de problème de performance, surtout si tu as un Syno musclé comme le DS918+. Ça peut aussi être un atout quand tu décidera d'ouvrir l'accès de l'extérieur pour une liste d'utilisateurs réduite.

Bonjour, Pour garder le même service qu'actuellement (connexion de ton PC sur le serveur en local et sur internet, connexion de ton syno à la box pour les mises à jour) sans risquer de laisser accéder à des tiers sur ton syno, je dirais que tu peux : A minima : brancher ton PC et le syno sur le routeur de ton bailleur. établir les connexions entre ton PC et ton syno en https plutôt que http pour chiffrer les échanges. configurer le pare feu de ton syno pour n'autoriser que les flux qui t'intéressent, et éventuellement le pare feu de ton PC. Si tu utilises des partages de type SMB, il n'y a pas à ma connaissance possibilité de chiffrage des échanges sans implanter un VPN (serveur sur to syno, client sur ton PC). A toi de voir ce qui te convient.

Je parle de ce point déjà discuté, mais j'ai trouvé une solution (peut être évidente pour certains) pour éviter de "réserver" le port 443. Ça ne concerne pas l'utilisation de plusieurs sites, qui se traitent par des virtual hosts en effet.

Je viens de me rendre compte qu'il y a une solution plus simple qui marche très bien: On peut utiliser le port d'entée 443 pour le reverse proxy et pour accéder au site WebStation qui écoute le port 443 (à partie de https://www.ndd.fr par exemple), il suffit de ne pas mettre de règle reverse proxy pour l'adresse https://www.ndd.fr. Par défaut, ça renvoie au site WebStation (quelle que soit l'adresse de type https://xxx.ndd.fr qui n'a pas de règle dans le reverse-proxy et qui pointe sur le syno en question). Voilà. finalement c'est tout simple.

Que veux tu dire par là? Veux-tu créer deux sous-réseaux? pour quoi faire? J'avais compris que tu voulais te prémunir contre la panne d'un Syno, mais pas les isoler. Peux-tu expliciter?

C'est vrai, mais c'est si rare. De toutes façons tu auras toujours la panne commune potentielle de ta box internet. Autre solution (avec deux reverse-proxies) : Je suis en train de tester IPV6 et il s'avère qu'avec IPV6 chaque machine a son (et même ses) adresse(s) IP. Tu peux donc traiter les deux Synos séparément. Attention dans ce cas à bien configurer le ou les firewall(s), sinon toutes les machines du réseau local sont exposées sur Internet.

Bonjour @Dimebag Darrell, J'ai moi aussi deux Synos sur mon réseau local Syno1 et Syno2. Un seul (Syno1) a un reverse proxy de configuré. Les services de Syno1 sont accessibles par www.ndd.fr (webservice), syno.ndd.fr (DSM de Syno1), ... Pour accéder au DSM de Syno2, j'ai configuré dans le reverse-proxy de Syno1 la redirection suivante : https://Syno2.ndd.fr vers http://Nom_Local_de_Syno2:5000 et ça fonctionne très bien. Pas besoin de configurer un deuxième reverse-proxy sur le second syno.

Bon, après tests ce week-end, je peux confirmer (voir ici) que le problème identifié si on ne réserve pas le port 443 subsiste dans la version actuelle de DSM, que ce soit en IPV4 ou IPV6. Donc je garde ma préférence pour réserver le port 443. Toutefois, en IPV6, les redirections de ports dans la box (6443 vers 443 dans mon exemple) ne sont plus effectives. Il faudra trouver une autre solution (voir mon port référencé juste au dessus). Si quelqu'un a une autre idée...

@Jeff777: Pour https://www6.ndd.fr je pense donc que le problème de la boucle infinie est toujours présent dans l'implémentation native de reverse-proxy dans DSM. Il va falloir trouver une autre solution que la redirection de port dans la freebox (qui n'est plus effective en IPV6). Pour l'instant, je n'en vois que deux, : 1) que la machine hébergeant le reverse-proxy soit différente de la (ou les) machine(s) hébergeant un site sur le port 443. Ça peut être un autre syno ou un Raspberry Pi par exemple. Pas génial pour moi d'exposer sur Internet mon nas de backup, même avec un bon firewall. 2) Changer l'adresse d'écoute de WebStation https. Je n'ai pas trouvé comment faire dans l'interface de DSM et je préfère éviter de changer directement dans les fichiers de config. Pour le DHCPV6, je crois que le plus simple est en effet de le décocher. le firewall microsoft du PC peut aussi faire des siennes. On dirait que tu as trouvé la bonne config. Bon week-end à tous.

Bon, petit test en IPV6. Pour l'instant, j'ai utilisé un ndd spécifique IPV6 (syno6.ndd.fr - backup6.ndd.fr - www6.ndd.fr - freebox6.ndd.fr). Les enregistrements AAAA pour ces 4 domaines pointent tous sur mon nas (backup). Le reverse proxy a le port d'entrée 443 sur mon nas (backup). les redirections reverse-proxy pointent sur le SRM de mon nas principal, le SRM de mon nas backup, le webserver https de mon nas (backup), ma freebox (mafreebox.freebox.fr) respectivement. Le firewall de mon routeur ne laisse passer en IPV6 que des requêtes vers le nas (backup) et que sur les ports 80 et 443. Toutes les tentatives de connexion https indiquent que le certificat est incorrect (c'est un certif auto-signé qui ne correspond pas aux adresses). Résultats : La requête http://www6.ndd.fr fonctionne. Les requêtes https://syno6.ndd.fr - https://backup6.ndd.fr - https://freebox6.ndd.fr fonctionnent. La requete http://www6.ndd.fr fonctionne et donne accès au site web hébergé par le nas (backup) La requête https://www6.ndd.fr donne : 400 Bad Request Request Header or Cookie Too Large (nginx) Un problème avec le port 443 reste donc tout au moins possible, même si je ne sais pas comment interpréter le message d'erreur de nginx.

@Jeff777, @firlin , Désolé mais ce n'est ni le port 8870 ni le 4441. Ces valeurs sont des morceaux de l'IPV6 (les 6ème et 8ème segments).

Ben oui. Je crois que je vais tester directement en IPV6 en utilisant mon autre syno. 😊

Merci @Jeff777 pour ces résultats. Quel intérêt vois tu à utiliser DHCPV6 par rapport au mode automatique "stateless" que nous utilisions au début de ce fil ? Y revenir pourrait supprimer le problème avec android. Nous y voilà. Ce que je prétends (après tests), c'est que les redirections de port de la freebox ne sous pas effectives en IPV6. La freebox est transparente et se contente du rôle de routeur. Tu ne le vois pas car tu n'as que des redirections vers le même port. d'où mes questions. Si tu veux, je peux faire des tests pour toi de l'extérieur. Il suffit de se mettre d'accord sur une fenêtre horaire où ta config est prête pour le test et tu peux me fournir le ndd à utiliser en MP. pas besoin d'aller jusqu'à une connexion complète je suppose. Pour le moment je ne délègue pas la zone de mon domaine local vers mon DNS global (qui est chez Bookmyname). J'ai donc un DNS local qui résout les adresses en local et mes enregistrements DNS chez Bookmyname qui le font en global. Sur mon réseau local, j'ai bien remarqué dans les réponses de nslookup la mention de "serveur par défaut inconnu", mais ça ne me dérangeait pas. Zonemaster me trouve des warnings : 1 ADDRESS WARNING Aucune réponse des serveurs de noms sur une requête de type "PTR" (xxx.1.0.a.2.ip6.arpa.). 2 ADDRESS WARNING Le serveur de noms nsa.bookmyname.com a une adresse IP (88.191.249.135) sans enregistrement "PTR" correspondant. 3 ADDRESS WARNING Aucune réponse des serveurs de noms sur une requête de type "PTR" (xxx.1.0.a.2.ip6.arpa.). 4 ADDRESS WARNING Le serveur de noms nsb.bookmyname.com a une adresse IP (88.191.250.14) sans enregistrement "PTR" correspondant. 5 ADDRESS WARNING Aucune réponse des serveurs de noms sur une requête de type "PTR" (yyy.in-addr.arpa.). et des notices 0 DNSSEC NOTICE Il n'y a pas enregistrements de type "DS", ni de type "DNSKEY" pour la zone. 1 DNSSEC NOTICE La zone n'est pas signée avec DNSSEC. je sens que je vais devoir faire quelque-chose. Bonne journée.

Bonjour @Jeff777, Çà vient de la façon que j'avais suivie du temps de DSM 4, alors que le reverse-proxy n'était pas natif dans DSM. J'avais suivi le tutorial de @CoolRaoul, ici : (edit : un paragraphe a "sauté" dans mon texte initial. Je l'ajoute ci-après): Si un des services que tu veux présenter à internet est un site web via le port 443 et que tu utilises le port 443 en entrée du reverse-proxy, tu dois avoir une règle du reverse-proxy du type https://www.ndd.fr:443 vers https://localhost:443 et alors tu crées une boucle infinie. Même chose pour le port 80 et http. en aussi si tu forces l'utilisation https pour les requêtes arrivées en http. Une solution "élégante" est de libérer le port 443 comme je préconisais, en utilisant une redirection de port dans la box. Les choses ont peut-être changé avec l'implémentation native du reverse-proxy, comme j'évoquais dans un autre fil, mais en DSM 6, j'ai directement retranscrit ma config avec la solution native (les deux sont basées sur nginx). Si j'ai compliqué les choses inutilement, je vous prie de m'en excuser. Dès que je trouve un moment, je teste une solution sans "réserver" le port 443.

@Double Jo: là ton reverse-proxy écoute sur le port 443. Pour que l'adresse https://service.ndd.fr donne accès au srm, il faut : que tu définisses un enregistrement A dans le DNS OVH qui redirige service.ndd.fr vers l'IPV4 du NAS cible (c'est fait) que tu rediriges dans ta box ou ton routeur le flux internet du port 443 vers le port 443 de ton NAS (c'est fait aussi) que tu définisse une règle dans ton reverse-proxy de https://service.ndd.fr vers http://localhost:5000 Si tu veux, tu peux faire écouter le reverse-proxy sur un autre port (par ex le 6443). Là il faut : que tu définisses un enregistrement A dans le DNS OVH qui redirige service.ndd.fr vers l'IPV4 du NAS cible (le même) que tu rediriges dans ta box ou ton routeur le flux internet du port 443 vers le port 6443 de ton NAS que tu définisse une règle dans ton reverse-proxy de https://service.ndd.fr:6443 vers http://localhost:5000 l'intérêt de la seconde solution est de libérer le port 443 de ton NAS.

OK @Jeff777, merci pour ces précisions. Je reprends en détail pour voir si j'ai bien compris. Dis moi si je me trompe : Pour ce test tu as la config suivante du pare-feu de ton NAS : Interdiction totale d'entrer sur ton NAS avec une IPV4 (que ce soit une adresse locale - 192.168... - ou une adresse globale). interdiction totale d'entrer sur ton NAS avec une IPV6 locale (en fe80:...) les seuls ports ouverts sont les ports 80 et 443 ouverts aux adresses globales (style 2a01:...) de France Tu fais le test sur un appareil (A) connecté sur ton réseau local en utilisant l'adresse http://audio.ndd.fr qui est dans ton DNS global et qui pointe en IPV6 sur le port 80 de ton NAS (via la freebox qui fait le loopback). Le .htaccess force l'utilisation de https vers le port 443, donc les requêtes suivantes de (A) dans la même session seront traduites en https://audio.ndd.fr donc toutes arriveront sur le port 443 de ton NAS. Donc tu devrais avoir le même comportement en utilisant directement l'adresse https://audio.ndd.fr. C'est le cas? Tu as configuré ton reverse-proxy avec un port d'entrée égal à 443, et tu as une entrée qui route audio.ndd.fr:443 vers http://localhost:nnnn si "nnnn" est le port attribué à l'appli audio. Donc le reverse-proxy fonctionne 😊. Tu n'utilises pas de redirection de port dans ta freebox et tu peux accéder à d'autres services de ton NAS de la même façon, et même d'autres services fournis par d'autres machines de ton réseau local, machines que tu peux cacher complètement derrière le pare-feux de ton NAS (en n'autorisant l'accès en provenance d'internet que sur les ports 80 et 443 l'adresse IPV6 de ton NAS). Mais qu'en est il si tu as un site webstation que tu veux accéder par http://www.ndd.fr ou https://www.ndd.fr qui fonctionnent donc sur les ports 80 et 443 de ton NAS ? En écrivant celà, je me rends compte que je n'ai pas testé une possibilité : peut être suffit-il de ne pas mettre de redirection dans le reverse-proxy pour www.ndd.fr (ni en http ni en https) et que par défaut il utilise alors l'accès de base à webstation. Je me serais fait des nœuds au cerveau pour rien dans ce cas. En IPV4, j'avais réglé la question en utilisant le port 6443 comme port d'entrée sur le reverse-proxy et en définissant une redirection de port dans ma freebox du port externe 443 vers le port 6443 de mon NAS. Ça vaudrait probablement aussi le coup de tester à partir d'une adresse IPV6 vraiment extérieure. Pour ma part, je fais ça à partir de mon smartphone android (j'ai appliqué la modif Orange proposée par @CoolRaoulen début de ce fil). Si j'ai besoin de le faire depuis un PC, j'utilise mon tel android en mode "point d'accès mobile" et je connecte mon PC en wifi dessus. En tout cas merci @Jeff777, nous continuons à progresser !

Tout à fait d'accord sur ce point, mais le mécanisme de reverse-proxy utilise également les redirections de port dans le routeur (ou la freebox) comme décrit à la fin de mon message ici : Or les redirections du routeur ne semblent plus effectives en IPV6 donc il faut trouver un autre moyen pour répondre au besoin. Note : je n'ai pas eu le temps de faire de nouveaux tests hier soir.

@Jeff777 : comme j'ai une config un peu différente de la tienne (routeur derrière la freebox au lieu de freebox servant de routeur pour ton réseau local), j'ai voulu moi aussi faire quelques tests du DHCPV6. Sur le RT 2600ac, le SRM propose pour la config du réseau local plusieurs options pour l'affectation des adresses IPV6 : 1) mode sans état (stateless mode) 2) mode DHCPV6 sans état 3) mode d'état DHCPV6 (statefull mode) Le mode 1) correspond au DHCPV6 désactivé. C'est celui que j'avais jusqu'à présent et qui permet à chaque machine de choisir elle même sa ou ses adresses IPV6. Le mode 2) ressemble à ce que tu décris dans tes messages d'hier soir. Les adresses IPV6 ne sont plus exactement les mêmes, mais la modif principale par rapport à 1) est que l'adresse de la passerelle par défaut (l'adresse locale en fe80:...du routeur) est positionnée par le routeur et diffusée à tous les machines clientes. Je n'ai pas décelé de changement dans le comportement du réseau, à par le fait que sur mon pc, la commande nslookup (qui permet d'interroger le DNS actif - le local sur mon réseau) était complètement perdue alors qu'en mode 1, elle retourne bien les adresses IPV4 et IPV6 qui existent. Il semble que ce mode soit l'équivalent de ce que la freebox propose avec l'option DHCPV6 que tu as testé. le mode 3) ressemble plus au DHCP V4. En plus de la diffusion de la passerelle par défaut, l'option permet de choisir une tranche d'adresses à utiliser pour les imposer aux machines clientes. Il me demande la "tranche" d'adresses à affecter aux clients DHCPV6. Si mon préfixe de sous réseau local est 2a01:e0a:xxxx:yyyy, je lui ai défini la tranche 2a01:e0a:xxxx:yyyy::2 à 2a01:e0a:xxxx:yyyy::ffff (2a01:e0a:xxxx:yyyy::1 étant l'adresse du routeur sur le réseau local). même impact sur mon réseau local que pour le mode 2), les adresses IPV6 affectées étant bien dans la tranche choisie. Dans les 3 modes, je n'ai pas pu mettre en évidence l'application de redirections de ports (pourtant non marquées spécifiques à IPV4). Après ces tests, j'ai conclu que les modes DHCPV6 ne m'apportaient rien. Et puis, j'ai oublié de faire un test (il était tard) : je n'ai pas regardé l'impact (supposé négatif dans la littérature) sur les machines sous Android. Je subodore que c'est le cas 3) qui doit coincer, mais ça reste à vérifier. A suivre donc 😉

Merci @Jeff777. J'ai une question : Je ne comprend pas le "Donc". Avec le reverse proxy en IPV4 on utilise généralement le port par défaut (c'est un peu l'objectif), donc l'adresse https://mon IPpublique, ou plutôt https://service.ndd.fr par exemple ça arrive sur la freebox qui fait une redirection de port vers le port du NAS utilisé pour l'entrée https du reverse proxy (par exemple 6443). La commande reverse proxy du NAS renvoie la requête vers le port 5001 et tu arrives sur la page d'accueil du SRM de ton NAS. Quand tu mets l'adresse IPV4 https://mon IPpublique:5001, tu passes par la freebox, sa redirection de port ( ici : 5001 vers le même 5001 de ton NAS cible je suppose) puis tu atteins le NAS sur la page d'accueil de SRM. Pas d'utilisation du reverse proxy. De même quant tu mets l'adresse IPV6 https://mon IPpublique:5001, tu arrives directement sur ton NAS (c'est bien son IPV6 que tu as mis) et bien sûr tu atteins le NAS sur la page d'accueil de SRM. Pas d'utilisation du reverse proxy non plus. Ceci doit être identique que tu aies activé DHCPV6 ou non. Pour mon utilisation de l'extérieur, ce que je cherche c'est de pouvoir accéder à mes services (DSM de chacun des NAS, site web auto hébergé, ...) en utilisant le seul port 443 (seuls les ports 80 et 443 sont autorisés sur le réseau de mon employeur). En IPV4 j'utilise le reverse proxy de la manière que j'ai décrite plus haut. En IPV6 j'ai un problème car la transcription de port de la freebox (ou de mon routeur dans mon cas) ne s'applique pas. Il y a donc embouteillage sur mon NAS pour le port 443 qui reçoit à la fois l'entrée du reverse proxy et les requêtes https sur le site hébergé. Le seul contournement (théorique pour l'instant car je ne l'ai pas testé) que je vois est d'implanter le reverse proxy sur une autre machine (l'autre NAS ou un Raspberry Pi par exemple), de pointer de l'extérieur vers lui et de renvoyer les requêtes www.ndd.fr vers mon NAS principal. Ce ne me semble pas optimal (soit d'ouvrir mon NAS de backup sur internet, soit d'ajouter un Pi). D'où mes questions précédentes sur les redirections de ports et le reverse proxy. Qu'en penses tu?

Super travail @Jeff777! Comment se passe l'affectation des ipV6 sur ton réseau local? Est-ce que ce sont les mêmes que sans DHCPV6? Syno? PCs? Ça m'a quand même l'air assez concluant. Tu peux voir les connexions sur ton Syno dans le journal des connexions (Centre des journaux / Connexions). Il te donne l'adresse utilisée pour les connexions (et donc si c'est une IPV6 ou non). Même avec une connexion à travers un reverse proxy, il donne l'adresse d'origine réelle. Avais-tu des redirections de port? avec ta manip, les connexions qui passent doivent être IPV6. Les redirections ont elles été exécutées (je pense par exemple à celle que l'on met pour un reverse proxy du port 443 vers le port du Syno qui dispatche pour le reverse proxy)? As tu donné dans ton enregistrement AAAA l'adresse de le freebox ou celles de chacune des machines?

Tout ceci m'amène à d'autres réflexions (peut être liées) concernant l'accès à mon réseau local depuis l'extérieur : Peut on garder un fonctionnement similaire à celui d'IPV4 (en n'utilisant qu'une adresse externe et en accédant aux services internes avec des transmissions de port et un reverse proxy) ? En fait, ça ne semble pas fonctionner hors de DHCPV6 car les redirections de port sont ignorées. Mais avec DHCPV6 ? Sinon, comment configurer pour accéder aux services en n'utilisant que le port 443 pour toutes les requêtes https vers tous les services (le réseau de ma société ne permet que ça) ? Par exemple utiliser l'adresse d'un syno comme adresse principale et directement brancher le reverse proxy sur le port 443 ? Mais ça réserve le port de ce syno à cet usage. Je vais essayer de regarder ça. Si vous avez des idées... Il faudrait peut-être que j'ouvre un autre fil pour ça.

Concernant les types d'adresses IPV6 générées par MS Windows, voir cet article qui résume bien le sujet, mais ne s'explique pas ce qui fait changer l'adresse "Public" pseudo-fixe. http://computer-outlines.over-blog.com/article-windows-ipv6-privacy-addresses-118018020.html

@Einsteinium: En fait, la Freebox reçoit non pas une adresse, mais 8 bloc d'adresses qui ont chacune un préfixe de 64 bits. Par défaut (si DHCPV6 n'est pas activé) la freebox affecte le premier bloc au réseau local et diffuse le préfixe (de 64 bits donc) à toutes les machines. Chacune d'entre elles se construit une ou plusieurs adresses IPV6 avec ce préfixe et annonce ses adresses à la freebox qui connait donc toutes les adresses du réseau local. Voir ici : https://fr.wikipedia.org/wiki/Adresse_IPv6 (paragraphe Configuration automatique). Les autres blocs permettent d'avoir plusieurs sous-réseaux attachés à la freebox. il faut alors avoir un routeur par sous-réseau et on peut affecter un des 8 blocs d'adresses à ce routeur en renseignant "Next Hop" dans la config IPV6 de FreeboxOS.

Il est possible que le DHCPV6 assigne d'autres adresses IPV6 aux équipements, d'où la rougeur de Zonemaster.

@Einsteinium: Le DHCPV6 n'est pas nécessaire pour faire fonctionner un réseau local avec IPV6. Avec IPV6, chaque machine est capable de se donner elle même une adresse V6, en fait même plusieurs (comme on a pu voir dans ce fil). DHCPV6 est même déconseillé car il est incompatible avec les smartphones Android. Les PCs, tablettes ou smartphones utilisent alors pour accéder à internet des adresses IPV6 variables (durée de vie de 24 heures semble-t-il). Donc peu de risque si tentative d'intrusion. il semble que c'est aussi le cas des macs (à vérifier). Les serveurs par contre (par exemple les synos) n'ont qu'une adresse globale fixe (logique). Pour être complètement tranquille, plusieurs solutions : désactiver IPV6 sur chacune des machines (ou programmer le firewall pour le faire). Je n'ai pas vu comment faire pour les macs ou les smartphones. ou intercaler un routeur (par ex un syno RT2600ac) entre la box et le réseau local, et activer le firewall du routeur en bloquant le flux entrant IPV6.