Auteur Sujet: Problème de configuration IPv6 via 6to4 Tunnel (Lu 8302 fois)

rocho · « **Réponse #12 le:** 24 mai 2015 à 18:00:40 »

Avec et sans le proxy, dans les deux cas cela ne fonctionne pas...

Testé avec IE, Chrome et Chromium

[EDIT] C'est peux être plus complexe que sa car par exemple je n'arrive pas à accéder à http://ipv6.test-ipv6.com/ qui n'a pourtant qu'un enregistrement AAAA... Par contre un ping sur ipv6.test-ipv6.com fonctionne

kgersen · « **Réponse #13 le:** 24 mai 2015 à 18:07:54 »

Le serveur DNS est lequel ?

On dirait un probleme de Happy Eyeballs.

sous Chrome, aller sur : chrome://net-internals/#dns
clicker sur le button 'clear host cache' (j'ai pas la version francaise mais y'a qu'un bouton donc clicker sur lui).
puis réessayer le site qui pose probleme dans un autre onglet.
revenir dans l'onglet ou y'a le bouton pour voir les 2 valeurs que Chrome essai de joindre.

rocho · « **Réponse #14 le:** 24 mai 2015 à 18:18:47 »

Il n'y a aucune règle activé sur le Firewall en IPv6...

[EDIT] Le proxy transparent est désactivé et le poste sur lequel je suis n'a pas de proxy activé

[EDIT] Sur l'IP indiqué par Chrome, le ping fonctionne...

kgersen · « **Réponse #15 le:** 24 mai 2015 à 18:22:20 »

Et chrome affiche quelle erreur quand on tente d'aller sur ce site ?

Sinon un bon utilitaire: https://technet.microsoft.com/fr-fr/sysinternals/jj729731.aspx (suite PsTools).

Code: [Sélectionner]

psping -n 3 -i 0 -q test-ipv6.com:80va faire 3 tentatives d'acces web au site.

rocho · « **Réponse #16 le:** 24 mai 2015 à 18:24:15 »

Il affiche ERR_TIMED_OUT...

https://testdebit.info/ qui pointe vers 2a01:6e00:10:410::2 ne marche pas non plus... Mais par contre http://[2a01:6e00:10:410::2]/ s'affiche...

Je vais tester avec ton utilitaire

rocho · « **Réponse #17 le:** 24 mai 2015 à 18:32:24 »

Sur domaine qui n'a qu'un enregistrement AAAA et en "double pile" :

[EDIT] Chrome m'a fait ERR_CONNECTION_RESET cette foie... Après avoir tenté de charger la page pendant plus d'une minute...

kgersen · « **Réponse #18 le:** 24 mai 2015 à 18:38:14 »

Un simple "ping www.google.com" ca le fait en v4 ou v6 ?

Ce qui est curieux c'est que ca passe avec les adresses en dur et pas avec les noms. Le seul truc qui peut expliquer ca c'est un proxy quelque part ou une mauvaise résolution DNS mais d'apres Chrome il recoit la bonne résolution DNS donc c'est pas le DNS.

Sous Chrome: chrome://net-internals/#proxy affiche si proxy ou pas.

ERR_TIMEOUT en plus ca veut dire qu'il a bien envoyé la requete HTTP et qu'il n'a pas recu de réponse...donc a priori ca part bien du poste mais ca revient pas.

rocho · « **Réponse #19 le:** 24 mai 2015 à 19:10:46 »

J'ai aussi souvent : ERR_CONNECTION_RESET

D'ailleurs, https://www.google.fr/ qui est en "double pile" s'affiche parfaitement et c'est l'IPv6 qui est utilisé...

kgersen · « **Réponse #20 le:** 24 mai 2015 à 20:00:24 »

Curieux en effet...

on recap:

DNS - ok (test dans chrome)
Pas proxy local - ok (test dans chrome)
ipv6 prio sur ipv4 - ok (quand on fait un ping www.google.com c'est l'ipv6 qui est choisi).

symptômes:
A- Les url pures ipv4 marchent (url = www.domain.com qui ne se résous qu'en ipv4 (A) ou http://adresse_ipv4 )
B- Les url pures ipv6 marchent (url = www.domain.com qui ne se résous qu'en ipv6 (AAAA) ou http://[adresse_ipv6])
C- Les url mixtes ne marchent pas, sauf certaines comme https://www.google.fr/ ? (a confirmer).

causes probables:
un proxy quelque part sur le réseau ? (voir http://whatismyipaddress.com/proxy-check et http://www.lagado.com/proxy-test )
un taux d'erreur élevés dans le tunnel ? (douteux)
un antivirus/protection réseau dans le poste qui détecte du "spoofing" d'IP car il ne fonctionne pas (ou pas bien) en v6 ? (a verifier)

Ce qui me gene c'est que C soit pas tout ou rien et que certains sites mixtes fonctionnent ...c'est tres curieux ca.

rocho · « **Réponse #21 le:** 24 mai 2015 à 20:35:59 »

Apparemment cela ne concerne que le web (un rdp sur un domaine mixtes où AAAA only - qui ne fonctionnais pas sur le port 80 - marche parfaitement)
J'ai dit que cela venait des url mixtes car j'avais testé que sur une url à moi qui est IPv6 only ( http://vps14.vpsbenchmark.eu/ ) et cela avait fonctionné. Mais finalement cela semble vraiment aléatoire, par exemple http://ipv6.cybernode.com/ qui est IPv6 only ne s'affiche pas...

Donc pour l'instant sur le web :

IPv4 : Ok
IPv6 et mixtes : Parfois oui, parfois non... Cela dépend des sites web mais je n'arrive pas à trouver les points commun que pourrait avoir ceux qui fonctionne et ceux qui ne fonctionne pas... mais quand cela fonctionne c'est l'IPv6 qui est utilisé.

Pour la présence d'un proxy, les deux tests sont négatif mais apparament ils ne sont effectués qu'en IPv4...

Il y a eu 525 paquets perdu pour environ 660 000 paquets échangé sur sit1, c'est vraiment négligeable...
Le poste que j'utilise principalement pour tester c'est un Windows Server 2012 R2 donc sans "Antimalware service executable" et il n'y a pas d'antivirus.

[EDIT] Cela affecte aussi bien le HTTP que le HTTPS. Et encore plus étrange, cela affecte certain élèment sur un domaine qui fonctionne... Je peux accéder à http://ipv6.teddy.ch/ mais je ne vois pas le logo en haut à gauche et quand j'essaie de charger dans un autre onglet http://ipv6.teddy.ch/logo.png j'obtiens ERR_CONNECTION_RESET...

J'ai constaté que jusqu'à présent, les sites où fichiers qui ne s'affichait donnaient l'erreur ERR_CONNECTION_RESET en HTTP et ERR_TIMED_OUT en HTTPS...

Je commence vraiment à pensé que le problème viens de HE... Ils pourraient quand même pas fournir un tunnel 6to4 aussi filtré ? Il est envisageable qu'ils aient un problème technique qui entraîne ce genre de problème ?

[EDIT] J'ai peux être un début de réponse grâce à un miroir de test-ipv6.com

Je vais aller voir ce que je peux faire pour ses problèmes de MTU et je vous tiens au courant

[EDIT] Problème réglé ! J'ai modifié le MTU de l'interface sit1 de 1480 à 1280 comme conseillé par un des miroir test-ipv6.com et maintenant tout fonctionne parfaitement

Un grand merci à kgersen pour m'avoir aidé à solutionner mes problèmes et m'avoir appris plein de choses sur l'IPv6

kgersen · « **Réponse #22 le:** 24 mai 2015 à 22:11:32 »

Citation de: rocho le 24 mai 2015 à 20:35:59

Je commence vraiment à pensé que le problème viens de HE... Ils pourraient quand même pas fournir un tunnel 6to4 aussi filtré ? Il est envisageable qu'ils aient un problème technique qui entraîne ce genre de problème ?

J'en doute et il n'y a rien a ce sujet sur leur forums. Ils ne filtrent rien. De chez moi ca marche niquel (le logo de http://ipv6.teddy.ch/ s'affiche bien) mais je passe par New-York.

Je pense plutot que ca vient du routeur mikrotik. on n'est pas sur que ca configuration soit complètement réussie (edit: le MTU est bon?).

Tu peux tester en faisant un tunnel directement depuis le serveur Windows en le branchant derriere la livebox (ou avec un simple poste derriere la livebox si c'est plus simple). il y a les instructions sur le site de HE pour faire le tunnel avec Windows.

Tu peux aussi tester avec une "autre sortie" de tunnel, par exemple a NY ou Londres (un tunnel HE vers NY pour Netflix ca marche sans souci).

Ca donne quoi un tracert sur le tunnel francais de HE ? (tracert -4 tserv1.par1.he.net)
Depuis SFR ca passe par Londres...:

Code: [Sélectionner]

HOST: UserPC                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- box                           0.0%     1    0.3   0.3   0.3   0.3   0.0
  2.|-- 92com1-nro-1.nro.gaoland.net  0.0%     1    0.9   0.9   0.9   0.9   0.0
  3.|-- 109.13.6.109.rev.sfr.net      0.0%     1    0.9   0.9   0.9   0.9   0.0
  4.|-- 2.122.3.109.rev.sfr.net       0.0%     1    3.5   3.5   3.5   3.5   0.0
  5.|-- 40ge1-3.core1.lon2.he.net     0.0%     1    9.7   9.7   9.7   9.7   0.0
  6.|-- 100ge5-1.core1.par2.he.net    0.0%     1    9.5   9.5   9.5   9.5   0.0
  7.|-- 10ge3-1.core1.par1.he.net     0.0%     1   10.0  10.0  10.0  10.0   0.0
  8.|-- tserv1.par1.he.net            0.0%     1    9.5   9.5   9.5   9.5   0.0

Paris -> Londres -> Paris

les joies du peering

kgersen · « **Réponse #23 le:** 24 mai 2015 à 22:14:32 »

ah cool j'ai vu ta modif sur le MTU qu'apres mon 2eme edit. Effectivement on l'avait zappé au debut.

edit: c'est vrai qu'avec Orange on a du PPPoE donc deja sans tunnel on est pas a 1500.

par defaut un 6in4 se met a 1480 (1500 - les 20 pour faire le tunnel).

1280 c'est le plus bas possible et ca peut réduire les performances mais effectivement c'est le plus sur.

Dans ton cas, 1480 - les 8 de PPPoE = 1472 devrait marcher aussi. tu gagnes 200 octets par paquets ca peut jouer a haut débit (j'ai pas fait le calcul).