Auteur Sujet: Tester sa connectivité IPv4 / IPv6 (Lu 157621 fois)

vivien · « **le:** 26 juin 2017 à 09:00:57 »

Tester sa connectivité IPv4 / IPv6 :

Vous pouvez tester votre connectivité IPv4 / IPv6 sur :
- http://ip.lafibre.info/ (en http)
- https://ip.lafibre.info/ (en https)

Vous pensez que c'est simple et qu'il y a ceux qui ont IPv6 et ceux qui n'ont pas IPv6 ?
Non, il existe beaucoup d’autres cas !

C'est pour cela que http://ip.lafibre.info/ réalise 4 tests distincts :
- Vérifier votre connectivité IPv4 via une site qui a un enregistrement DNS
- Vérifier votre connectivité IPv4 via une site sans enregistrement DNS (le test requête directement http://45.85.134.187/ )
- Vérifier votre connectivité IPv6
- Vérifier le protocole par défaut.

Si tout est ok, les 4 tests sont de couleur verte.

Exemple de cas concrets de défauts, que les tests sauront vous aider à déterminer :

Si vous vous trouvez sur un réseau en IPv6 seulement (votre appareil/ordinateur n'est pas servi par une double connectivité IPv4/IPv6 appelé dual-stack) le 464XLAT est nécessaire pour avoir une connectivité IPv4 littérale et l'adresse IPv4 publique utilisée pour le 464XLAT peut être différente de celle utilisée par le DNS64.

Pourquoi sous Android l’IPv4 publique utilisée par le DNS64 est différent de celle utilisée pour le 464XLAT ?

Un seul préfixe NAT64 est utilisé, aussi bien pour le DNS64 que pour le 464XLAT. Toutefois l’opérateur alloue un /64 d’adresses IPv6 au mobile. De nombreux mobiles Android utilisent une IPv6 source, différente de l’IPv6 source utilisée par le CLAT, pour les flux qui partent directement sur Internet.

La plateforme NAT64 de l’opérateur peut attribuer une adresse IPv4 source différente aux flux provenant de deux IPv6 source distinctes, même si les deux IPv6 sont dans le même /64. Il en résulte que l’IPv4 publique affichée pour une requête vers un site IPv4 only joint via DNS64 peut être différente de celle utilisée pour joindre le même site depuis le même mobile, mais via une IPv4 littérale.

L’IPv6 destination du DNS64 et celle calculée par le CLAT sont identiques, ce sont les IPv6 sources différentes qui font que les deux IPv4 publiques du DNS64 sont différentes.

Explication du 464XLAT dans le rapport sur l’état d’internet en France de l'Arcep, édition 2021 :

Citation de: vivien le 14 juillet 2021 à 21:59:21

Il y a quand même des nouveautés dans le rapport, comme les explications sur les accès IPv6 et le mécanisme de 464XLAT :

Il y a encore un test important que je ne sais pas réaliser : détecter quand le système d'exploitation reçois une IPv6 mais qu'il n'y a pas de connectivité IPv6. Ce type de bug ralenti fortement la navigation qui part en IPv6 avant de basculer après expiration du time-out en IPv4. Certaines applications ne basculent jamais (Filezilla par exemple) ce qui bloque de nombreux usages.

C'est pour cela qu'il y a un avertissement quand le test de trouve pas de connectivité native IPv6 :

Le test de connectivité IPv4 via une site sans enregistrement DNS (le test requête directement http://45.85.134.187/ ) ne peut pas être réalisé en https, car il n'y a pas de certificat correct pour l'IP. C'est pour cela que le site propose de passer en http pour faire le test, si vous l'appelez en https ( https://ip.lafibre.info/ ).

vivien · « **Réponse #1 le:** 26 juin 2017 à 09:02:56 »

Le site affiche toujours de nombreuses informations TCP / IP :

Merci à kgersen pour m'avoir aidé sur les scripts et l'ARCEP pour la bannière IPv6 récupérée de son dernier rapport.

turold · « **Réponse #2 le:** 26 juin 2017 à 09:25:19 »

Pourquoi ai-je ceci en HTTPS alors que la page affiche bien mon IPv4 sur la partie TCP?

Citer

Connectivité IP :

Votre connectivité IPv4 (via DNS) est OK
Votre connectivité IPv4 (en direct) est inconnu (réalisez le test en http pour avoir la réponse)
Votre connectivité IPv6 est OK
La version du protocole IP utilisée par défault est IPv6
Bienvenue dans l’internet du futur !

vivien · « **Réponse #3 le:** 26 juin 2017 à 09:29:48 »

Comme expliqué, il n'est pas possible de faire un est https vers une IP :

Citation de: vivien le 26 juin 2017 à 09:00:57

Le test de connectivité IPv4 via une site sans enregistrement DNS (le test requête directement http://46.227.16.8/ ) ne peut pas être réalisé en https, car il b'y a pas de certificat correct pour l'IP. C'est pour cela que le site propose de passer en http pour faire le test, si vous l'appelez en https ( https://ip.lafibre.info/ ).

C'est pour cela que j'incite l'utilisateur a basculer en http, si il est intéressé par le résultat de ce test.

turold · « **Réponse #4 le:** 26 juin 2017 à 09:34:19 »

Ok, je me doutais qu'il y avait une raison technique valable.

Pour le coup de la lecture, désolé, mais je louche en permanence depuis la canicule.
J'espère qu'avec beaucoup de repos, et une nouvelle baisse des températures par chez moi dans quelques jours, cela reviendra à la normale, sinon je serai parti pour quelques mois avant de m'y habituer...

yrousse · « **Réponse #5 le:** 26 juin 2017 à 10:44:05 »

Citation de: vivien le 26 juin 2017 à 09:00:57

Exemple de cas concrets, qui sont rares mais qui sont couvert par les tests :
- Si vous avez une connectivité IPv4 assurée par un NAT64, sans 464XLAT, les site avec un DNS en IPv4 fonctioneront tandis que ceux appelé directement par l'IPv4 ne fonctionneront pas.
- Si vous avez une connectivité IPv4 assurée par un NAT64 et que vous n'utilisez pas un DNS64, vous n'aurez aucune connectivité IPv4.
- Si votre connectivité IPv6 est assurée par Teredo (Tunneling IPv6 sur UDP), alors le protocole par défaut restera IPv4, alors que vous avez les 3 types de connectivité OK.

Ce paragraphe fait quelques raccourcis anodins mais il a fallut que je le relise

. (perso, un "site avec un DNS en IPv4", je ne sais pas ce que c'est.

Je chipote peut-être mais un DNS, c'est le résolveur, pas le nom de domaine)

Ma suggestion (tout en posant au début la condition essentielle, pour un peu de pédagogie envers l'utilisateur):

Citer

Exemple de cas concrets de défauts que les tests sauront vous aider à déterminer:
Si vous vous trouvez sur un réseau en IPv6 seulement (votre appareil/ordinateur n'est pas servi par une double connectivité IPv4/IPv6 (dual-stack)) alors...
- une connectivité vers des sites dont la résolution de nom ne donne qu'une IPv4 (pas d'IPv6 donc) nécessite une passerelle NAT64/DNS64. Les sites sollicités uniquement via leur adresse littérale en IPv4 ne seront pas joignables si votre passerelle ne fait pas également du 464XLAT.
- Si vous avez une connectivité vers IPv4 assurée par une passerelle NAT64 mais sans DNS64, vos sollicitations vers des sites en IPv4 seulement n'aboutiront pas.
- Si votre connectivité IPv6 est assurée par Teredo (Tunneling IPv6 sur UDP), alors le protocole par défaut restera IPv4 : vous aurez les 3 types de connectivité OK.

yrousse · « **Réponse #6 le:** 26 juin 2017 à 10:47:55 »

Ah oui… et du coup, la ligne sur Teredo ne convient plus avec ma mention d'un réseau en IPv6 seulement… $:-\$

vivien · « **Réponse #7 le:** 26 juin 2017 à 11:11:49 »

yrousse, j'ai complétement modifié le paragraphe pour prendre en compte tes remarques.

C'est par contre pas très compréhensible du grand public, mais au moins c'est juste.

A noter qu'il est possible de mettre en place un DNS tiers qui fais du DNS64, pour ceux qui sont en NAT64 (info venant de notre expert national en DNS, Stéphane Bortzmeyer, mais je n'ai pas bien compris comment récupérer les infos pour faire passer l'IPv4 par la plateforme NAT64)

yrousse · « **Réponse #8 le:** 26 juin 2017 à 11:37:25 »

Oui, j'ai bien conscience que cela reste moyennement accessible pour le grand public. Mais on sortait de l'intention première quant à ton outil.
À défaut, l'exactitude a son importance.

DNS64 : oui, "possible" et même indispensable. Un résolveur BIND fait ça avec quelques lignes de config.

Code: [Sélectionner]

dns64 2001:db8:1:ffff::/96 {
                clients { any; };

Il utilisera le prefix IPv6 précisé lorsqu'il répond à un host IPv6 local sur une requête ne répondant que par une IPv4 et c'est ce même prefix que tu configures sur ton NAT64 (ll saura donc "déconstruire" l'IPv6 sollicitée par ton host pour faire sa requête en IPv4 coté WAN et vice-versa).
Un petit tuto complet ici:
https://thepoulpe.net/index.php?article25/mise-en-place-d-un-reseau-ipv6-troisieme-partie
(Et comme on le voit dans le tuto, NAT64 connait l'IPv4 de la passerelle vers le WAN)

vivien · « **Réponse #9 le:** 26 juin 2017 à 12:39:50 »

Réponse du DNS64 pour le nom de domaine ipv4.lafibre.info qui comme son nom l'indique ne propose pas d'IPv6 :

Code: [Sélectionner]

$ dig AAAA ipv4.lafibre.info

; <<>> DiG 9.10.3-P4-Ubuntu <<>> AAAA ipv4.lafibre.info
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42266
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ipv4.lafibre.info.		IN	AAAA

;; ANSWER SECTION:
ipv4.lafibre.info.	223	IN	AAAA	64:ff9b::2ee3:1008

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Jun 26 12:37:00 CEST 2017
;; MSG SIZE  rcvd: 74

turold · « **Réponse #10 le:** 26 juin 2017 à 13:01:49 »

Je ne suis pas fan d'un préfixe aussi long pour le dns64, même si c'est celui-ci dans tous les tutos.

La conversion de 46.227.16.8 donne ::ffff:2ee3:1008

Ceci dit, c'est peut être fonctionnel.

yrousse · « **Réponse #11 le:** 26 juin 2017 à 13:22:34 »

Citation de: turold le 26 juin 2017 à 13:01:49

Je ne suis pas fan d'un préfixe aussi long pour le dns64, même si c'est celui-ci dans tous les tutos.

La conversion de 46.227.16.8 donne ::ffff:2ee3:1008

Ceci dit, c'est peut être fonctionnel.

64:ff9b::/96 ne sera utilisé qu'entre les hosts et la passerelle DNS64/NAT64 et tu respectes la RFC 6052 donc bon…