Forum Linux.général IPv6 à moitié routée ?

Posté par  . Licence CC By‑SA.
Étiquettes :
0
8
juil.
2016

Bon, là, j'ai un souci avec mon IPv6 fourni par Free.

EDIT : C'est un problème de MTU. Visiblement, chez Free, la MTU est à 1480, mais je ne recevais pas les paquets ICMP6 "Packet too big" pour ré-envoyer avec une taille moins grosse (pas de fragmentation intermédiaire en IPv6). La suite contient le début du problème.

Certains sites passent (http://test-ipv6.com/ à 10/10 par exemple) et d'autres bloquent (http://www.kame.net http://ploum.net/ par exemple).

Sachant que en IPv4, ces sites répondent bien, et que en ICMPv6, ça répond. Ça serait bizarre que ça vienne de mon firewall, vu que certains sites passent très bien.

Une piste ? Des outils pour débugger ? Je sèche un peu, et ça m'embête assez bien…

EDIT : Pour ploum.net, voici un truc intéressant :

~> curl -v --max-time 5 -6 http://ploum.net/
*   Trying 2001:4b98:dc0:950::136...
* Connected to ploum.net (2001:4b98:dc0:950::136) port 80 (#0)
> GET / HTTP/1.1
> Host: ploum.net
> User-Agent: curl/7.47.0
> Accept: */*
> 
* Operation timed out after 5000 milliseconds with 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 5000 milliseconds with 0 bytes received`

Et si on vire le champ Host, pour rigoler :

~> curl -v --max-time 5 -6 http://ploum.net/ -H "Host:"
*   Trying 2001:4b98:dc0:950::136...
* Connected to ploum.net (2001:4b98:dc0:950::136) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 403 Host header not found
< Server: Varnish
< Content-Type: text/html; charset=utf-8
< Retry-After: 0
< Content-Length: 365
< Date: Mon, 11 Jul 2016 19:54:48 GMT
< Connection: close
< Via: 1.1 varnish
< Age: 0
< 
[]
* Closing connection 0

Donc pour ce site là, ça viendrait peut-être du backend…

Après, pour https://framablog.org/ (2a01:4f8:a0:9132::85) c'est complètement mort avec curl. Par contre le traceroute se termine bien à l'hôte final.

Je sens que y a du drop de paquets quelque part, en fonction du protocole…

  • # traceroute

    Posté par  (site web personnel) . Évalué à 1.

    Que donne un traceroute (n'oublie pas d'anonymiser le résultat) ?

    • [^] # Re: traceroute

      Posté par  . Évalué à 1.

      J'ai édité mon post, sans coller les résultats, mais un traceroute pour framablog.org arrive correctement, dans un temps raisonnable (~100ms). Pareil que ploum.net. Les paquets ICMPv6 passent donc sans problème. Ce sont les paquets HTTP qui ne passent plus…

  • # Problème connu

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 11 juillet 2016 à 11:08.

    C'est connu : certains opérateurs, notamment Free à ma connaissance, passent par Cogent pour leur connexion à Internet v6. Or Cogent n'a de connectivité qu'avec quelque chose comme 70% d'Internet v6, les 30% restant sont donc injoignables.

    À noter que souvent, dans l'autre sens, ça passe. L'Internet v6 se divise donc en deux parties : ceux qui passent par Cogent, et qui ont donc accès à quelque chose comme 70% du réseau, et les autres, qui ont accès à tout.

    • [^] # Re: Problème connu

      Posté par  . Évalué à 1.

      En soit, ça me paraît louche, mais pourquoi pas.
      Par contre, j'accédais bien aux sites sus-mentionnés auparavant. Et pourquoi les paquets ICMP passent, et pas l'HTTP ?

  • # Problème de MTU ?

    Posté par  . Évalué à 3.

    Pour moi ça ressemble à un problème de MTU : les « petits » paquets passent (comme les pages peu fournies), mais pas les gros. Es-tu derrière une connexion avec une MTU inférieure à 1500 octets ? Si c'est le cas, c'est peut-être que Free fait de la merde avec l'ICMPv6 en amont de ta connexion. Ou alors toi qui gère mal les tailles encore inférieure de ton côté pour une raison quelconque.

    Je me suis permis de pinger le AAAA de ton domaine, et j'arrive à passer au maximum avec une taille de payload à un ping6 de 1432 octets. Soit 1440 de payload pour IP, soit 1480 pour le paquet IP avec les headers, qui doit passer sur le medium sous-jacent, et c'est ça le MTU de ton lien Internet.

    Normalement, lorsque je dépasse cette taille, je devrais recevoir en retour un paquet ICMPv6 « Packet Too Big », pour m'indiquer de fragmenter, mais je ne vois rien de mon côté. C'est donc un problème de configuration à l'endroit où le tuyau « rétrécit » en-dessous de 1500 octets, la MTU « standard » d'Internet. Ça peut éventuellement venir de mon côté sur ce réseau vu que j'ai mis des années à convaincre les admins de ne pas filtrer l'ICMPv6 pour les PTB, mais bon je ne suis jamais sûr des nouveautés qu'ils me pondent. Le seul réseau neutre et sûr que j'ai a une MTU encore plus petite que toi.

    Pour nous aider, il faudrait tes paramètres de connexion, avec le détail sur la box en particulier ; enfin, je ne sais pas si ça se récupère facilement, c'est tellement chiant les boxs des FAI…

    • [^] # Re: Problème de MTU ?

      Posté par  . Évalué à 1.

      MERCI !

      Ah la MTU. Je m'étais jamais frotté à ce problème, même si je le connaissais, donc j'ai jamais pensé à le tester…

      Donc oui, par dichotomie avec ip link j'ai bien trouvé 1480 de MTU, au lieu de 1500. Ça marche. Tout marche comme avant. Reste à savoir ce qui a changé, et pourquoi…

      Pour info, ma Freebox est en mode bridge, et j'ai mon propre serveur en mode serveur/pare-feu/routeur. Mais j'ai jamais touché à la MTU, et je n'ai jamais eu de souci jusqu'à récemment. Ou alors c'est Debian qui a changé la valeur par défaut de la MTU ?

      Et je suis en train de me rendre compte que je vais devoir changer la MTU sur les postes clients… J'ai un DHCP(v4), mais bon, l'IPv4 marche bien avec 1500…

      Bref, l'Internet est cassé pour les gens normaux. Mais merci pour la solution.

      • [^] # Re: Problème de MTU ?

        Posté par  (site web personnel) . Évalué à 2.

        Donc bon j'insiste avec mon traceroute :-)

        Tu peux utiliser l'option -T de traceroute pour faire du TCP (si tu as un doute TCP vs ICMP) et spécifier le port avec -p, par contre il faudra le lancer avec les droits root.
        Tu peux spécifier la taille du paquet de probe, par exemple :
        sudo traceroute -6 -T -p 80 framablog.org 5000
        Ça devrait te permettre qui pose problème avec les paquets trop longs !

        • [^] # Re: Problème de MTU ?

          Posté par  . Évalué à 4.

          Un petit coup de tcpdump peut aider aussi pour voir si l'icmp too big ne viendrait pas jusqu'à la machine mais ne serait pas pris en compte à cause d'une règle firewall par exemple.

          J'ai un DHCP(v4), mais bon, l'IPv4 marche bien avec 1500

          C'est parce que l'ipv4 permet la fragmentation, si un routeur reçoit un paquet trop gros, il le découpe. En ipv6, c'est interdit, à la place, le routeur envoit un paquet icmp packet too big et la source renvoie un paquet plus petit. Or, si l'icmp est filtré, ce dernier cas ne marche pas.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Problème de MTU ?

            Posté par  . Évalué à 1.

            C'est marrant, je me rends compte que je sais tout ça, et quand il faut le mettre en pratique, j'oublie… Comme quoi, la pratique, ça aide à fixer les connaissances. Merci pour le rappel en tout cas.

        • [^] # Re: Problème de MTU ?

          Posté par  . Évalué à 1.

          Effectivement, traceroute permet d'aller plus loin que ce que je pensais (je devrais plus souvent RTFM).

          Par contre, par défaut, il fragmente lui-même les paquets en fonction de la MTU de l'interface réseau. Pour forcer la non-fragmentation, il faut mettre -F ce qui permet de voir directement l'erreur.

          Et du coup, après avoir fait des tests en touchant la MTU de l'interface avec traceroute, après avoir vu des paquets ICMP6, packet too big avec tcpdump, je me retrouve avec la MTU fixée à 1500, et des connexions qui marchent. ALORS QUE AVANT ÇA MARCHAIT PAS ! Désolé, je m'emporte.

      • [^] # Re: Problème de MTU ?

        Posté par  . Évalué à 2.

        [retour de vacances…]

        Donc oui, par dichotomie avec ip link j'ai bien trouvé 1480 de MTU, au lieu de 1500. Ça marche. Tout marche comme avant. Reste à savoir ce qui a changé, et pourquoi…

        Comment ça par « dichotomie » ta as « trouvé » 1480 ? De quelle interface parles-tu ? Qu'as-tu testé exactement ? Et qu'as-tu trouvé ?

        Ce qui a changé, et bien c'est peut-être que Free a baissé la MTU de ton lien. Par contre, normalement, ils ne devraient pas faire de la merde en bloquant l'ICMPv6. Ça m'étonne un peu, et peut-être que le problème vient d'ailleurs. Mais pour diagnostiquer, il va falloir un peu plus d'informations : les ip link / ip addr / ip route sur ton routeur, des infos sur la freebox, etc.

        Pour info, ma Freebox est en mode bridge,

        OK, mais elle peut très bien avoir une MTU réduite sur le lien.

        et j'ai mon propre serveur en mode serveur/pare-feu/routeur. Mais j'ai jamais touché à la MTU, et je n'ai jamais eu de souci jusqu'à récemment. Ou alors c'est Debian qui a changé la valeur par défaut de la MTU ?

        Ah non, ça n'est pas quelque-chose qui change comme ça. Je pense plus à un paramètre de le Freebox, ou la manière dont Free gère (mal) son réseau. Pour ça il faudrait plus d'informations sur la configuration de la Freebox.

        Et je suis en train de me rendre compte que je vais devoir changer la MTU sur les postes clients…

        Heu, non. Ils s'adapteront très bien quand ton routeur leur renvoiera un PTB. C'est « normal » d'avoir des MTU différentes, la gestion est très bien intégrée au protocole quand on ne fait pas de la merde avec du filtrage de l'ICMPv6.

        J'ai un DHCP(v4), mais bon, l'IPv4 marche bien avec 1500…

        Oui, c'est le routeur qui fragmente en v4, comme indiqué plus haut. Par contre ça n'est pas « idéal » niveau efficacité, même si en général on s'en fout.

        Bref, l'Internet est cassé pour les gens normaux. Mais merci pour la solution.

        Non. L'Internet est cassé pour ceux qui ne respectent pas la neutralité. Et c'est normal : ICMPv6 est constituant du protocole, il ne faut pas le toucher pour que ça marche. Comme on ne connaît toujours pas la source de ton problème de MTU, on ne peut pas savoir pour l'instant qui fait des bêtises.

        • [^] # Re: Problème de MTU ?

          Posté par  . Évalué à 1.

          Comment ça par « dichotomie » ta as « trouvé » 1480 ? De quelle interface parles-tu ? Qu'as-tu testé exactement ? Et qu'as-tu trouvé ?
          Ben j'ai changé la MTU progressivement 1500, 1450, 1475, 1482, etc… Et à 1479, ça marche, 1480 aussi, mais pas 1481. Dichotomie quoi ;) Je l'ai fait sur l'interface eth_adsl (reliée à ma Freebox) de mon routeur.

          La MTU de 1480 vient, mais c'est une hypothèse, du tunnel 6rd de Free qui doit rajouter des en-têtes. Soit, ce n'est pas vraiment un problème. Par contre, comme je l'ai dit, quand je fais une connexion TCP, ou même un simple ping vers un site distant, je n'ai pas de ICMPv6 "Packet too big". De personne. Par contre, si je fais un ping vers le routeur, avec un payload trop important, je l'ai, et ça met à jour les tables de routage temporaire, et tout marche comme sur des roulettes par la suite.

          Du coup, j'avais trouvé la solution de mettre "AdvLinkMTU 1480;" dans mon /etc/radvd.conf. Il se trouve que ça a marché… jusqu'à une mise-à-jour de systemd sous Debian, avec une ligne dans le changelog :

          • networkd: Handle router advertisements in userspace again. Drop Revert-Revert-networkd-ndisc-revert-to-letting-the-k.patch. Bug #814566/#815586 got fixed in 230, and #815884 and #815884 and #815793 are unreproducible and need more reporter feedback.

          —Martin Pitt mpitt@debian.org Tue, 26 Jul 2016 12:17:14 +0200

          Et si on remonte un peu avant :

          • networkd: Go back to letting the kernel handle IPv6 router advertisements, as networkd's own currently has too many regressions. Thanks to Stefan Lippers-Hollmann for investigating this! (Closes: #814566, #814667, #815586, #815884, #815793)

          —Martin Pitt mpitt@debian.org Sun, 28 Feb 2016 22:16:12 +0100

          Donc là, ma vie personnelle fait que j'ai pas eu le temps de m'en occuper plus que ça, mais hein, si c'est pas un micmac avec networkd (que j'utilise sur mon ordinateur de bureau), je sais pas ce que c'est… Ce qui m'embête le plus, c'est de ne pas comprendre pourquoi les paquets ICMPv6 "Packet too big" ne sont pas générés, ni par mon routeur, ni par la Freebox…

          • [^] # Re: Problème de MTU ?

            Posté par  . Évalué à 2.

            Ben j'ai changé la MTU progressivement 1500, 1450, 1475, 1482, etc… Et à 1479, ça marche, 1480 aussi, mais pas 1481. Dichotomie quoi ;) Je l'ai fait sur l'interface eth_adsl (reliée à ma Freebox) de mon routeur.

            Ce que je veux dire, c'est que « ça marche » c'est très vague : tu réponds pour l'interface, mais tu ne dis pas depuis où, vers où, avec quel outil, quels paramètres, etc.

            La MTU de 1480 vient, mais c'est une hypothèse, du tunnel 6rd de Free qui doit rajouter des en-têtes.

            Effectivement, cette taille doit venir de là.

            Soit, ce n'est pas vraiment un problème. Par contre, comme je l'ai dit, quand je fais une connexion TCP, ou même un simple ping vers un site distant, je n'ai pas de ICMPv6 "Packet too big". De personne.

            Ça par contre c'est un problème de ton routeur, puisque c'est lui qui a un lien réduit, maintenant que tu as fixé la MTU dessus. Un paquet arrive sur son interface LAN, avec MTU de 1500 je suppose, OK, puis quand il veut forwarder vers l'interface eth_adsl, qui fait 1480, ça ne passe pas, alors il doit te renvoyer un PTB. Je pense donc que tu as un problème de filtrage de l'ICMPv6 sur ton routeur. Vérifie la configuration de ton firewall.

            Si par contre le problème arrive quand on fait un test depuis l'extérieur, le problème viendrait potentiellement de Free.

            Par contre, si je fais un ping vers le routeur, avec un payload trop important, je l'ai, et ça met à jour les tables de routage temporaire, et tout marche comme sur des roulettes par la suite.

            Ça par contre, je ne comprends pas, ça n'est pas normal, à moins que j'ai mal compris ton test : si c'est juste sur ton LAN entre ta machine et ton routeur, il n'y a aucune raison de limiter la MTU à moins de 1500.

            Du coup, j'avais trouvé la solution de mettre "AdvLinkMTU 1480;" dans mon /etc/radvd.conf.

            Qui n'est pas la bonne : ça empêche les machines de ton LAN de communiquer entre elles avec le MTU maximum réel. C'est un workaround foireux, car un jour tu pourrais tomber sur un interlocuteur sur le net qui a un MTU encore plus petite (comme chez moi), et là ça foirera parce que tu n'as pas identifié réellement la source de ton problème d'ICMPv6 PTB qui ne passe pas.

            Il se trouve que ça a marché…

            Comme j'ai dit, ça n'est pas pérenne.

            jusqu'à une mise-à-jour de systemd sous Debian, avec une ligne dans le changelog :

            Des fois j'ai vraiment envie de foutre des grosses baffes à ces devs incompétents. Vouloir tout remplacer pour le plaisir quand on y connaît rien… c'est irresponsable.

            Donc là, ma vie personnelle fait que j'ai pas eu le temps de m'en occuper plus que ça, mais hein, si c'est pas un micmac avec networkd (que j'utilise sur mon ordinateur de bureau), je sais pas ce que c'est… Ce qui m'embête le plus, c'est de ne pas comprendre pourquoi les paquets ICMPv6 "Packet too big" ne sont pas générés, ni par mon routeur, ni par la Freebox…

            Pour comprendre, essaye d'abord d'être plus clair dans ce que tu testes. Un PTB est généré par le routeur qui passe d'un lien plus gros à un lien plus petit, en renvoyant à l'émetteur un PTB. Cette fonction est réalisée des deux côtés du goulot d'étranglement, et peut donc foirer aussi bien dans un sens que dans l'autre, et pas forcément en même temps. Ça complique un peu le diagnostic, mais il est essentiel de bien être clair là-dessus pour commencer à résoudre ton problème. Je suis d'accord que pour le test depuis l'extérieur, c'est un peu plus compliqué, mais ça se fait.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.