Petit test suite passage IPV6 forcé par Free

[dd5992]

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

[Einsteinium]

Je ne me suis jamais intéressé au protocole en lui même, mais sans dhcp, comment le client devine t’il la plage d’ip qu’il doit prendre pour accéder à internet ? Il dialogue quand même avec le serveur malgré le dhcp coupé ?

Pas besoin de firewall sur le routeur synology, quand on a renseigné son interface principal en ipv4, il suffit d’afficher l’option de l’ipv6 et de la désactivé.

Maintenant ma freebox en adsl ne me sert que de connection de secours et je ne la garde que pour la puce 4G free en data illimité (cf signature pour le routeur 4G)

[dd5992]

@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.

Modifié le 13 mai 2019 par dd5992

[dd5992]

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

[Jeff777]

il y a 28 minutes, dd5992 a dit :

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

Bon pour faire progresser la science j'ai réactivé l'IPV6 de la freebox et tout rebooté PC,NAS et Freebox.

Résultat:

Je n'ai plus d'adresse IPV6 publique sur mon PC (vérifié avec ipconfig) je n'ai que l'adresse locale en fe80 toujours la même puisque basée sur l'adresse mac.

Le zone master est rouge car l'IPV6 globale du NAS à changé et  les 4 derniers groupes sont maintenant différents de l'adresse locale.

Donc dd5992 n'avait pas tort.

Pour pousser un peu plus loin j'ai mis cette nouvelle adresse dans les enregistrements de ma zone publique et maintenant mon zonemaster est correct !

Reste à récupérer mes adresses IPV6 publiques. J'attends de voir

 

Et oui en rebootant la box j'ai une nouvelle adresse publique non liée à mon adresse mac. Et je n'ai plus d'adresse IPV6 temporaire !

Bon appétit !

[dd5992]

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 :

1. 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 ?
2. 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) ?
3. 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.

Modifié le 13 mai 2019 par dd5992

[Jeff777]

En tout cas maintenant j'ai des adresses locales fixes déduites des adresses mac et des adresses publiques qui n'ont plus rien à voir avec l'adresse locale (ni avec les adresses mac, à priori) du type :

2a01:xxxx:xxxx:xxxx::yyyy:yyyy

avec la partie en x identique pour tous les périphériques.

De plus ces adresses sont fixes et sont utilisées à la place des adresses temporaires.

Par exemple avant de mettre le DHCP IPV6, l'adresse ipv6 de mon PC (https://test-ipv6.com/) changeait à chaque reboot de ma box et correspondait à l'adresse temporaire donnée par la cmd  ipconfig.

Maintenant avec le DHCP IPV6 j'ai une adresse fixe publique (que je peux trouver par https://test-ipv6.com/ et ipconfig) et plus d'adresse temporaire ( dans ipconfig)

 

 

Modifié le 13 mai 2019 par Jeff777

[Einsteinium]

Il y a 11 heures, dd5992 a dit :

@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.

Merci pour le court, je m’endormirais moins plus riche, donc au final c’est ipv6 forcé par free c’est pas dû jolie et je n’ose imaginé pour les appareils iot...

[Jeff777]

Il y a 23 heures, dd5992 a dit :

En fait, ça ne semble pas fonctionner hors de DHCPV6 car les redirections de port sont ignorées. Mais avec DHCPV6 ?

Avec DHCPV6 j'ai tenté de forcer les connexions au NAS en IPV6 de la manière suivante :

Dans le pare-feu du NAS j'ai refusé toutes les connexions du LAN en IPV4 (elle restent autorisées en IPV6) j'ai aussi refusé mon adresse publique IPV4.

Le fonctionnement reste identique après nettoyage des caches pour toutes les connexions locales utilisant les noms de domaines.

Mais je ne sais pas dire si ce test est concluant vis à vis de l'IPV6.

Si j'ai le courage j'essaierai bien de supprimer mes enregistrements A de ma zone publique mais j'ai peur des conséquences. 😰

[dd5992]

Il y a 3 heures, Jeff777 a dit :

Avec DHCPV6 j'ai tenté de forcer les connexions au NAS en IPV6 de la manière suivante :

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?

Il y a 3 heures, Jeff777 a dit :

Mais je ne sais pas dire si ce test est concluant vis à vis de l'IPV6.

Ç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?

Modifié le 14 mai 2019 par dd5992

[Jeff777]

Oui les affectations sont les mêmes pour les IPV6 locales pour tous les périphériques (Dans mon cas elles sont toutes liées à l'adresse Mac puisque j'ai retiré la "randomisation" de win 10).

Par compte comme j'ai dit plus haut, plus d'IPV6 temporaires (du moins pour le PC et je pense que c'est vrai pour le reste).

Ceci est sans doute une conséquence du fait que maintenant les adresses globales publiques ont changé et ne sont plus liées aux adresses mac. Ce sont elles qui sont utilisées de l'extérieur du réseau et non plus les temporaires.

Pour l'instant je n'ai pas pu voir une perte de connectivité IPV6 sur ma tablette android.

Oui je peux voir quelques connexions IPV6 dans le journal, d'ailleurs cela a toujours été le cas. Mais j'ai toujours eu l'IPV6 activé même sans le DHCPV6.

Les enregistrements AAAA de la zone publique ns.ndd et ndd correspondent à l'adresse IPV6 publique du NAS et non celle de la freebox car c'est là que loge le DNS serveur.

(Et oui en IPV4 c'est la même pour le NAS et la box. Mais en IPV6 faut pas se tromper)

C'est là que je m'étais planté car, comme tu me l'avais fait remarqué, l'adresse a changé avec le DHCPV6 activé.

Lorsque je mets dans mon navigateur https://mon IPpublique:5001  j'arrive sur la page d'accueil du NAS  que ce soit avec l'adresse IPV4 ou IPV6 (entre crochets). Bien sûr https est  en rouge barré non sécurisé puisque le certificat est attaché au nom de domaine et non à l'adresse IP. Donc le reverse proxy fonctionne aussi pour l'IPV6.

Si j'ai un moment demain je referai un test et vérifierai les connexions dans le journal sur cette période de test.

Bonne soirée

 

 

 

[Jeff777]

Finalement j'ai refait un test ce soir, avec les réglages précédents du pare-feu, en me connectant sur divers applis (audio, download, cam, photo )du NAS depuis mon PC et depuis ma tablette

Tout ce petit monde se connecte avec une adresse IPV6

Le PC (adresse avec b562:xxx) se connecte avec son adresse IPV6 publique. Mais la tablette fcf2:c564:xxx:xxx  avec son adresse temporaire publique.

Contrairement à ce que je croyais la tablette (android) conserve  adresse locale, globale (avec fe80:: et les 4 derniers groupes identiques) et adresse temporaire utilisée pour se connecter de l'extérieur. Ces adresses ne sont donc pas affectées par le DHCPV6 de la freebox contrairement aux adresses des PC sous win 10.

Il me reste à faire un test de l'extérieur en interdisant la connexion de l'IPV4 du client.

Bye

Modifié le 14 mai 2019 par Jeff777

[dd5992]

Merci @Jeff777.

J'ai une question :

Il y a 21 heures, Jeff777 a dit :

Lorsque je mets dans mon navigateur https://mon IPpublique:5001  j'arrive sur la page d'accueil du NAS  que ce soit avec l'adresse IPV4 ou IPV6 (entre crochets). <...> Donc le reverse proxy fonctionne aussi pour l'IPV6.

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?

[Jeff777]

Me serai-je emmêlé les pinceaux ? Je regarde ce soir.

[dd5992]

@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 😉

Modifié le 15 mai 2019 par dd5992

[Jeff777]

Bon j'ai que quelques minutes pour répondre. 

Tu as raison le "donc" est totalement idiot. 🙄

Par contre on est bien d'accord que le reverse proxy se sert des adresses et non des IP pour les redirections. Donc je ne vois pas pourquoi cela ne marcherait pas avec les IPV6 s'ils pointent sur les mêmes adresses.

D'ailleurs toutes les connexions du journal ont été réalisées avec les adresses de type tartanpion.ndd.fr ( le journal donne toujours l'IP) et ont bien été redirigées vers la bonne application.  Les connexion avec l'adresse privée du NAS 192.168.0.10 ont été réalisée également avec tartanpion.ndd.fr mais avant et après les modif du pare-feu pour interdire l'IPV4.

A suivre....

 

Modifié le 15 mai 2019 par Jeff777

[dd5992]

Il y a 14 heures, Jeff777 a dit :

Par contre on est bien d'accord que le reverse proxy se sert des adresses et non des IP pour les redirections. Donc je ne vois pas pourquoi cela ne marcherait pas avec les IPV6 s'ils pointent sur les mêmes adresses.

 

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]

Il y a 2 heures, dd5992 a dit :

utilise également les redirections de port

Oui donc lorsque je fais un test avec audio.ndd.fr et que mon pare-feu interdit les connexions locales au NAS ainsi que celles avec l'adresse IPV4 publique la seule solution est que je rentre (en loopback) sur le LAN en IPV6 publique (vérifié dans le journal des connexions) avec le port 80 que j'ai autorisé dans le pare-feu pour tous les IP France.

J'arrive donc sur webstation et je tombe sur le .htaccess qui me dit de passer en https avec le port 443, je continue sur le reverse proxy et je passe en http en localhost mais avec le port que j'ai attribué à l'appli audio. 

Ce port n'est pas autorisé dans le pare-feu du NAS (ni d'alleurs le port correspondant au https pour l'appli audio qui de plus n'est même pas déclaré). Mais comme je suis déja sur le NAS j'arrive sur la page d'accueil de l'appli, je renseigne mes identifiants et j'arrive sur Audiostation.

Bon d'accord c'est mon vocabulaire. Peut-être pas très pro.et peut-être qu'il y a quelque chose qui m'échappe mais pour moi je ne vois pas de différence de fonctionnement entre une connexion en IPV4 et une en IPV6. Donc le reverse proxy est opérationnel dans les deux cas !

Modifié le 16 mai 2019 par Jeff777

[dd5992]

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 :

Il y a 4 heures, Jeff777 a dit :

lorsque je fais un test avec audio.ndd.fr et que mon pare-feu interdit les connexions locales au NAS ainsi que celles avec l'adresse IPV4 publique la seule solution est que je rentre (en loopback) sur le LAN en IPV6 publique (vérifié dans le journal des connexions) avec le port 80 que j'ai autorisé dans le pare-feu pour tous les IP France.

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).

Il y a 4 heures, Jeff777 a dit :

J'arrive donc sur webstation et je tombe sur le .htaccess qui me dit de passer en https avec le port 443, je continue sur le reverse proxy et je passe en http en localhost mais avec le port que j'ai attribué à l'appli audio. 

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.

Il y a 4 heures, Jeff777 a dit :

Ce port n'est pas autorisé dans le pare-feu du NAS (ni d'alleurs le port correspondant au https pour l'appli audio qui de plus n'est même pas déclaré). Mais comme je suis déja sur le NAS j'arrive sur la page d'accueil de l'appli, je renseigne mes identifiants et j'arrive sur Audiostation.

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 !

Modifié le 16 mai 2019 par dd5992

[Jeff777]

Je ne sais pas si ce sont mes tests qui ont mis le site du forum "down" mais j'ai eu du mal à me connecter 🤣

Pour répondre à tes questions j'ai fait un test (après vidage des caches) avec ceci :

Donc j'ai supprimé (mis de côté plutôt) un certain nombre de ports qui pouvaient parasiter le test. Même résultat que précédemment sauf qu'il faut se connecter en https puisque j'ai supprimé le 80.

Sauf avec la tablette où j'ai " time-out". Mais si j'autorise les connections locales ça fonctionne et si je les interdis à nouveau (sans vider les caches) ça fonctionne à nouveau même sur un sous domaine non testé. Par exemple je teste https://audio.ndd.fr sans les connections locales : time out, j'autorise les connections locale https://audio.ndd.fr fonctionne...... je les interdis à nouveau, ça fonctionne et photo.ndd.fr aussi !

D'où l'intérêt de vider les caches dns et navigateur avant tout test. Le time out est peut-être lié  à la mise en garde de free sur la connectivité IPV6 sur android lorsque le DHCPV6 est activé.

Je vais essayé d'éclaircir ce pb. (J'édite ce texte et confirme que j'ai perdu la connectivité IPV6 sur les appareils android . Dans Freebox OS les IP locales IPV6 sont maintenant marquées comme injoignables)

Sinon la réponse est oui à toutes tes questions.

Il y a 6 heures, dd5992 a dit :

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.

https://www.ndd.fr ==>http://localhost  dans le RP donc j'ai le même résutat qu'avec ndd.fr. Un de ces jours je customiserai la page web éventuellement avec des raccourcis vers les applis.

Pour les sites j'utilise les virtual hosts dans webstation :

nomdusite.ndd.fr   80/443   http/https  web/nomdusite

J'en ai deux dont un fait avec Wordpress du Syno et ça marche très bien. Bien sur il faut déclarer les sous domaines nomdusite, leur adjoindre un certificat (si pas de wildcard) et placer tous les fichiers du site sur le serveur dans le dossier web/nomdusite (pour wordpress j'ai garder ce nom pour le site et le dossier mais je suppose qu'il est possible de changer cela avec qq modifs des fichiers).

Je crois que j'ai rien oublié.

Il y a 6 heures, dd5992 a dit :

Tu n'utilises pas de redirection de port dans ta freebox

Si mais que des redirections sans changer le numéro du port. Et faudra que je vérifie lesquelles sont utiles (par exemple j'ai une redirection du 443 mais pas du 80 !).

Il y a 6 heures, dd5992 a dit :

Ç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

C'est vrai. Mais je n'ai pas de smartphone je n'ai qu'un tablette sans carte SIM. Oui je fais partie de ces irréductibles qui ont toujours résisté. 

Alors lorsque je veux tester une connexion par l'extérieur j'utilise un proxy. C'est lent et pas très prudent et j'évite d'y rester longtemps. Mais pour ces tests il faut que je trouve un proxy avec connexion IPV6, c'est plus rare  et je ne m'y suis pas encore mis.

Il y a 6 heures, dd5992 a dit :

nous continuons à progresser !

Oui. Et là je suis en train de créer des zones inversées pour les enregistrements PTR. Pour le moment j'ai réussi cela en local :

Avant la création de la zone j'avais serveur par défaut inconnu mais j'avais la bonne adresse et maintenant j'ai ns.ndd.fr ce qui prouve que l'enregistrement PTR est fait.

Par contre pour les zones inverses externes je n'ai pas réussi à les déléguer vers mon serveur DNS secondaire (chez Hurricane) et  Zonemaster me dit que le serveur ns.ndd à une adresse IP IPV6 celle ci dessus sans enregistrement PTR.

Mais cela progresse.

Bonne soirée

 

 

Modifié le 16 mai 2019 par Jeff777

[Jeff777]

Bon j'ai réussi la création de 4 zones inversées ( LAN et WAN pour IPV4 et IPV6) les zones WAN ont été transférées vers le DNS secondaire (Hurricane) avec succès.

Tout ceci n'était pas évident en l'absence de tuto précis et j'ai pas mal galéré.

Par contre pour le moment toujours pas d'enregistrement PTR pour l'adresse IPV6 de ns.ndd détectée par zonemaster. Et si je supprime l'option reverse dns de free je perd l'enregistrement PTR en IPV4 !

A suivre

[dd5992]

Merci @Jeff777 pour ces résultats.

Il y a 15 heures, Jeff777 a dit :

Le time out est peut-être lié  à la mise en garde de free sur la connectivité IPV6 sur android lorsque le DHCPV6 est activé.

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.

Il y a 15 heures, Jeff777 a dit :

Si mais que des redirections sans changer le numéro du port. Et faudra que je vérifie lesquelles sont utiles (par exemple j'ai une redirection du 443 mais pas du 80 !).

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.

Il y a 15 heures, Jeff777 a dit :

Lorsque je veux tester une connexion par l'extérieur j'utilise un proxy. C'est lent et pas très prudent et j'évite d'y rester longtemps. Mais pour ces tests il faut que je trouve un proxy avec connexion IPV6, c'est plus rare  et je ne m'y suis pas encore mis.

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.

 

Il y a 15 heures, Jeff777 a dit :

Oui. Et là je suis en train de créer des zones inversées pour les enregistrements PTR. Pour le moment j'ai réussi cela en local :

Avant la création de la zone j'avais serveur par défaut inconnu mais j'avais la bonne adresse et maintenant j'ai ns.ndd.fr ce qui prouve que l'enregistrement PTR est fait.

Par contre pour les zones inverses externes je n'ai pas réussi à les déléguer vers mon serveur DNS secondaire (chez Hurricane) et  Zonemaster me dit que le serveur ns.ndd à une adresse IP IPV6 celle ci dessus sans enregistrement PTR.

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.

[Jeff777]

Je réponds dans l'ordre pour limiter les images :

1/Intérêt du DHCPV6  Free. Bon effectivement cette perte de connectivité sur les appareils android est gênante. Je vais essayer de m'e passer du DHCPV6 de free. Mais il faut que je re-paramètre les entrées DNS. Je vais faire un essai limité.

2/Redirection de ports pas possible en IPV6 : d'où l'intérêt de ne pas  faire de redirection sur un port différent.

3/Je retiens ta proposition, merci. Ce sera sans doute milieu semaine prochaine car je voudrais d'abord résoudre cet histoire de zone inversée et je vais m'absenter demain matin jusqu'à mardi.

4/Ben non la zone de mon domaine locale n'est pas non plus déléguée. Je ne vois pas à quoi ça pourrait servir et je ne sais pas si c'est possible. Je fais comme toi sauf que le dns secondaire n'est pas le même.

"Serveur par défaut inconnu" signifie que tu n'a pas d'enregistrement PTR ce que confirme zonemaster. Effectivement ce n'est absolument pas gênant.

Les enregistrements PTR sont loin d'être indispensables http://blog.christopher.compagnon.name/article.sh?id=d20170509072404731

C'est juste pour le fun que j'essaie de le réaliser.

DNSSEC je crois que ce n'est pas possible avec DNS Serveur.

En fait mis à part l'enregistrement PTR du serveur secondaire qui existe pour Hurricane et pour mon IPV4. J'ai la même chose que toi.

 

Modifié le 17 mai 2019 par Jeff777

[Jeff777]

il y a une heure, dd5992 a dit :

je sens que je vais devoir faire quelque-chose.

Non rien à faire !

[dd5992]

il y a une heure, Jeff777 a dit :

2/Redirection de ports pas possible en IPV6 : d'où l'intérêt de ne pas  faire de redirection sur un port différent.

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

il y a 34 minutes, Jeff777 a dit :

Non rien à faire !

😊