Problèmes IPv6

Le
JKB
Bonjour à tous,

Je suis en train de tenter la configuration d'un serveur en IPv6.

La configuration est la suivante :
- eth0 -> LAN
- eth1 -> WAN IPv4 (et route par défaut IPv4)
- eth2 -> WAN IPv4 + IPv6 (et route par défaut IPv6)

Je n'ai pas encore installé de firewall IPv6.

Lorsque j'essaie deme connecter à la page http://test-ipv6.com/,
j'obtiens un 10/10. Je n'ai donc pas tout à fait n'importe quoi.

Cependant :
- certains sites qui sont résolus en IPv6 me sont inaccessibles ;
- un apt-get update échoue (sur ftp.fr.debian.org).

Je viens de tracer ce qu'il se passe lors de l'apt-get et je vois
les choses suivantes :

18:53:47.843327 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 403:442, ack 495, win 225, options [nop,nop,TS val 2393879 ecr
180210981], length 39
18:53:47.897096 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 495:505, ack 442, win 224, options [nop,nop,TS val 180331135 ecr
2393879], length 10
18:53:47.897126 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [.],
ack 505, win 225, options [nop,nop,TS val 2393893 ecr 180331135], length
0
18:53:47.897156 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 442:481, ack 505, win 225, options [nop,nop,TS val 2393893 ecr
180331135], length 39
18:53:47.948996 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 505:525, ack 481, win 224, options [nop,nop,TS val 180331188 ecr
2393893], length 20

Je communique donc bien avec le serveur distant. Celui-ci me répond
quelque chose. La question est maintenant de savoir pourquoi cela ne
fonctionne pas.

Une idée ?

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26333235
Salut,

JKB a écrit :

- certains sites qui sont résolus en IPv6 me sont inaccessibles ;
- un apt-get update échoue (sur ftp.fr.debian.org).



Echoue de quelle façon ?


Je viens de tracer ce qu'il se passe lors de l'apt-get et je vois
les choses suivantes :

18:53:47.843327 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 403:442, ack 495, win 225, options [nop,nop,TS val 2393879 ecr
180210981], length 39
18:53:47.897096 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 495:505, ack 442, win 224, options [nop,nop,TS val 180331135 ecr
2393879], length 10
18:53:47.897126 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [.],
ack 505, win 225, options [nop,nop,TS val 2393893 ecr 180331135], length
0
18:53:47.897156 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 442:481, ack 505, win 225, options [nop,nop,TS val 2393893 ecr
180331135], length 39
18:53:47.948996 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 505:525, ack 481, win 224, options [nop,nop,TS val 180331188 ecr
2393893], length 20



On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?

Je communique donc bien avec le serveur distant. Celui-ci me répond
quelque chose.



Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
JKB
Le #26333237
Le Sat, 10 Jan 2015 21:10:53 +0100,
Pascal Hambourg
Salut,

JKB a écrit :

- certains sites qui sont résolus en IPv6 me sont inaccessibles ;
- un apt-get update échoue (sur ftp.fr.debian.org).



Echoue de quelle façon ?



Réception de : 1 ftp://ftp.fr.debian.org/debian/ unstable/main fail2ban
all 0.9.1-1 [248 kB]
Err ftp://ftp.fr.debian.org/debian/ unstable/main fail2ban all 0.9.1-1
Pas de réponse du port de données dans les délais [IP :
2a01:e0c:1:1598::2 21]
E: Impossible de récupérer
ftp://ftp.fr.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.9.1-1_all.deb
Pas de réponse du port de données dans les délais [IP :
2a01:e0c:1:1598::2 21]



Je viens de tracer ce qu'il se passe lors de l'apt-get et je vois
les choses suivantes :

18:53:47.843327 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 403:442, ack 495, win 225, options [nop,nop,TS val 2393879 ecr
180210981], length 39
18:53:47.897096 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 495:505, ack 442, win 224, options [nop,nop,TS val 180331135 ecr
2393879], length 10
18:53:47.897126 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [.],
ack 505, win 225, options [nop,nop,TS val 2393893 ecr 180331135], length
0
18:53:47.897156 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 442:481, ack 505, win 225, options [nop,nop,TS val 2393893 ecr
180331135], length 39
18:53:47.948996 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 505:525, ack 481, win 224, options [nop,nop,TS val 180331188 ecr
2393893], length 20



On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?



Je n'ai rien filtré. J'ai essayé à la main avec un client ftp
classique, ça échoue bien. Chose amusante, les sites web
inaccessibles en IPv6 le sont en passant par un squid local qui
force une résolution IPv4. Ça ressemble en tout point au fameux
"trou de MTU" qu'on pouvait avoir en IPv4 lorsqu'on laissait 1500 en
PPPoE, mais je ne vois pas du tout d'où ça pourrait venir.

Je communique donc bien avec le serveur distant. Celui-ci me répond
quelque chose.



Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.



Peut-être, mais comme un tcpdump ne donne rien et qu'il n'y a rien
de filtré, je ne vois pas trop ce que pourrait donner un outil de capture
plus sophistiqué...

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26333240
JKB a écrit :



E: Impossible de récupérer
ftp://ftp.fr.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.9.1-1_all.deb
Pas de réponse du port de données dans les délais [IP : 2a01:e0c:1:1598::2 21]



"Port de données", apparemment ça concerne la connexion de données.

On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?



Je n'ai rien filtré. J'ai essayé à la main avec un client ftp
classique, ça échoue bien.



Tu as les logs complets de la session de commande avec ce client ?

Ça ressemble en tout point au fameux
"trou de MTU" qu'on pouvait avoir en IPv4 lorsqu'on laissait 1500 en
PPPoE, mais je ne vois pas du tout d'où ça pourrait venir.



Si c'est une connexion Nerim, ça peut venir du tunnel L2TP entre le LNS
et le BAS, qui peut avoir une MTU d'environ 1460 si les liens
sous-jacents ont une MTU de 1500. En IPv4 les LNS de Nerim font du
"clamping MSS" pour limiter les problèmes en TCP, je ne sais pas s'ils
le font en IPv6. J'ai configuré radvd sur mon routeur pour annoncer une
MTU de 1460 dans ses RA.

Mais habituellement le symptôme est que les petits paquets SYN et ACK
passent, mais pas les gros paquets de données de taille maximum. Or ici
on ne voit aucun paquet d'une connexion de données FTP. Tu peux quand
même essayer de baisser la MTU de l'interface pour voir si ça change
quelque chose.

Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.



Peut-être, mais comme un tcpdump ne donne rien et qu'il n'y a rien
de filtré, je ne vois pas trop ce que pourrait donner un outil de capture
plus sophistiqué...



On verrait l'avancement de la session de commande FTP. Si un transfert
en mode passif est initialisé, c'est le client qui devrait émettre un
SYN vers le serveur. Si on ne le voit pas partir, c'est que le problème
est local. Tu fais bien la capture sur le poste client ?
JKB
Le #26333248
Le Sat, 10 Jan 2015 21:58:37 +0100,
Pascal Hambourg
JKB a écrit :



E: Impossible de récupérer
ftp://ftp.fr.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.9.1-1_all.deb
Pas de réponse du port de données dans les délais [IP : 2a01:e0c:1:1598::2 21]



"Port de données", apparemment ça concerne la connexion de données.



Certes :-P

On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?



Je n'ai rien filtré. J'ai essayé à la main avec un client ftp
classique, ça échoue bien.



Tu as les logs complets de la session de commande avec ce client ?



Non, c'est un apt-get. Mais j'ai essayé avec un bête client ftp, je
n'ai rien de plus pertinent.

Ça ressemble en tout point au fameux
"trou de MTU" qu'on pouvait avoir en IPv4 lorsqu'on laissait 1500 en
PPPoE, mais je ne vois pas du tout d'où ça pourrait venir.



Si c'est une connexion Nerim, ça peut venir du tunnel L2TP entre le LNS
et le BAS, qui peut avoir une MTU d'environ 1460 si les liens
sous-jacents ont une MTU de 1500. En IPv4 les LNS de Nerim font du
"clamping MSS" pour limiter les problèmes en TCP, je ne sais pas s'ils
le font en IPv6. J'ai configuré radvd sur mon routeur pour annoncer une
MTU de 1460 dans ses RA.



Mon modem est un ZyXEL SBG3300. Configuré comme suit :
LAN IPv6 Address Setup : static 2001:7a8:a8ed::/64
ULA IPv6 Address Setup : 2001:7a8:a8ed::2/48

LAN Information
- IP Address: 192.168.253.254
- IP Subnet Mask: 255.255.255.0
- DHCP: Disable
- IPv6 Address:
2001:7a8:a8ed::2/48
2001:7a8:a8ed:0:2a28:5dff:fe11:bf23/64
- IPv6 Link-Local Address: fe80::2a28:5dff:fe11:bf23/64
- MAC Address: 28:28:5D:11:BF:23

Mais habituellement le symptôme est que les petits paquets SYN et ACK
passent, mais pas les gros paquets de données de taille maximum. Or ici
on ne voit aucun paquet d'une connexion de données FTP. Tu peux quand
même essayer de baisser la MTU de l'interface pour voir si ça change
quelque chose.



Avec une MTU de 1460 sur le lien en question, ça semble me permettre
d'atteindre les sites auparavant dans le néant. Mon modem ne propose
pas de radvd. Plus exactement, il m'indique

RADVD State : Enable

mais je ne vois pas comment le configurer finement.

Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.



Peut-être, mais comme un tcpdump ne donne rien et qu'il n'y a rien
de filtré, je ne vois pas trop ce que pourrait donner un outil de capture
plus sophistiqué...



On verrait l'avancement de la session de commande FTP. Si un transfert
en mode passif est initialisé, c'est le client qui devrait émettre un
SYN vers le serveur. Si on ne le voit pas partir, c'est que le problème
est local. Tu fais bien la capture sur le poste client ?



Tu vas rigoler, mais j'ai l'impression qu'avec une MTU de 1460,
j'arrive à utiliser le client ftp. J'avoue que je ne comprends pas
trop.

Merci pour tout,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26333343
JKB a écrit :

Avec une MTU de 1460 sur le lien en question, ça semble me permettre
d'atteindre les sites auparavant dans le néant. Mon modem ne propose
pas de radvd. Plus exactement, il m'indique

RADVD State : Enable

mais je ne vois pas comment le configurer finement.



radvd est le démon sous Linux qui gère les annonces de routeur IPv6 (RA)
utilisées pour l'autoconf sans état sur le LAN. Il transmet le préfixe,
l'adresse de routeur et optionnellement d'autres paramètres comme les
DNS et la MTU.

Tu vas rigoler, mais j'ai l'impression qu'avec une MTU de 1460,
j'arrive à utiliser le client ftp. J'avoue que je ne comprends pas
trop.



Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
JKB
Le #26333400
Le Sun, 11 Jan 2015 11:21:23 +0100,
Pascal Hambourg
JKB a écrit :

Avec une MTU de 1460 sur le lien en question, ça semble me permettre
d'atteindre les sites auparavant dans le néant. Mon modem ne propose
pas de radvd. Plus exactement, il m'indique

RADVD State : Enable

mais je ne vois pas comment le configurer finement.



radvd est le démon sous Linux qui gère les annonces de routeur IPv6 (RA)
utilisées pour l'autoconf sans état sur le LAN. Il transmet le préfixe,
l'adresse de routeur et optionnellement d'autres paramètres comme les
DNS et la MTU.

Tu vas rigoler, mais j'ai l'impression qu'avec une MTU de 1460,
j'arrive à utiliser le client ftp. J'avoue que je ne comprends pas
trop.



Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.



Justement, je me posais aussi la question. Dans l'ancien temps,
j'avais des modems Speestream 5200 et il fallait forcer le MTU à
1492. Je suis passé en PPPoA sur des Netopia 3346 et là, comme par
magie, une MTU de 1500 fonctionne. Repassage en PPPoE, en IPv4, avec
1492, ça fonctionne toujours. Avec un ZyXEL, même chose. As-tu une
explication ?

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26333411
JKB a écrit :
Le Sun, 11 Jan 2015 11:21:23 +0100,
Pascal Hambourg

Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.



Justement, je me posais aussi la question. Dans l'ancien temps,
j'avais des modems Speestream 5200 et il fallait forcer le MTU à
1492. Je suis passé en PPPoA sur des Netopia 3346 et là, comme par
magie, une MTU de 1500 fonctionne. Repassage en PPPoE, en IPv4, avec
1492, ça fonctionne toujours. Avec un ZyXEL, même chose. As-tu une
explication ?



Ça devient un peu confus pour moi. Tu parles toujours d'IPv6 avec ta
connexion actuelle ? Peux-tu détailler ce qui fonctionne ou pas (IPv4,
IPv6) avec quelle valeur de MTU, sur quelle connexion, avec quel modem
dans quel mode (bridge ou routeur) et à quel moment ?

PS : on ne devrait pas poursuivre dans fr.comp.reseaux.ip plutôt ?
JKB
Le #26333441
Le Sun, 11 Jan 2015 14:31:34 +0100,
Pascal Hambourg
JKB a écrit :
Le Sun, 11 Jan 2015 11:21:23 +0100,
Pascal Hambourg

Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.



Justement, je me posais aussi la question. Dans l'ancien temps,
j'avais des modems Speestream 5200 et il fallait forcer le MTU à
1492. Je suis passé en PPPoA sur des Netopia 3346 et là, comme par
magie, une MTU de 1500 fonctionne. Repassage en PPPoE, en IPv4, avec
1492, ça fonctionne toujours. Avec un ZyXEL, même chose. As-tu une
explication ?



Ça devient un peu confus pour moi. Tu parles toujours d'IPv6 avec ta
connexion actuelle ? Peux-tu détailler ce qui fonctionne ou pas (IPv4,
IPv6) avec quelle valeur de MTU, sur quelle connexion, avec quel modem
dans quel mode (bridge ou routeur) et à quel moment ?



eth1 : IPv4, MTU 1500, modem Netopia 3346 en PPPoE (depuis que le
PPPoA ne fonctionne plus sur la ligne). Dans les temps anciens, il
me fallait une MTU de 1492 pour que ça fonctionne, mais là, avec une
MTU de 1500, ça passe. C'est de l'ADSL2+. Je suppose peut-être à
tort que le modem qui embarque un système de type Unix est assez gentil
pour modifier la MTU du lien côté PPPoE. Pas d'IPv6, le Netopia ne
le permet pas.

eth2 : IPv4 et IPv6 en VDSL2, MTU 1492, modem ZyXEL SBG3300.
Lorsqu'il est en IPv4 seul, il fonctionne parfaitement avec une MTU de
1500 et du PPPoE. Pour l'IPv6, la valeur max est une MTU de 1492.
Je viens de trouver la valeur maximal avec une dichotomie.

Les deux liens sont du Nerim First.

PS : on ne devrait pas poursuivre dans fr.comp.reseaux.ip plutôt ?



Pourquoi pas... Je n'ai pas plus d'avis que cela.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26333466
JKB a écrit :

eth1 : IPv4, MTU 1500, modem Netopia 3346 en PPPoE (depuis que le
PPPoA ne fonctionne plus sur la ligne). Dans les temps anciens, il
me fallait une MTU de 1492 pour que ça fonctionne, mais là, avec une
MTU de 1500, ça passe. C'est de l'ADSL2+. Je suppose peut-être à
tort que le modem qui embarque un système de type Unix est assez gentil
pour modifier la MTU du lien côté PPPoE. Pas d'IPv6, le Netopia ne
le permet pas.

eth2 : IPv4 et IPv6 en VDSL2, MTU 1492, modem ZyXEL SBG3300.
Lorsqu'il est en IPv4 seul, il fonctionne parfaitement avec une MTU de
1500 et du PPPoE. Pour l'IPv6, la valeur max est une MTU de 1492.
Je viens de trouver la valeur maximal avec une dichotomie.

Les deux liens sont du Nerim First.



Encore une question : la MTU est fixée sur les routeurs ou sur le serveur ?

J'aurais bien voulu faire quelques tests complémentaires mais j'ai
l'impression que ton serveur ne répond plus sur eth2, ni en IPv4 ni en
IPv6...

PS : on ne devrait pas poursuivre dans fr.comp.reseaux.ip plutôt ?



Pourquoi pas... Je n'ai pas plus d'avis que cela.



Moi non plus. Ce fil parle plus d'IP que de Linux, mais comme il a
commencé ici, autant continuer.
Pascal Hambourg
Le #26333473
Pascal Hambourg a écrit :
JKB a écrit :
eth1 : IPv4, MTU 1500, modem Netopia 3346 en PPPoE (depuis que le
PPPoA ne fonctionne plus sur la ligne). Dans les temps anciens, il
me fallait une MTU de 1492 pour que ça fonctionne, mais là, avec une
MTU de 1500, ça passe. C'est de l'ADSL2+. Je suppose peut-être à
tort que le modem qui embarque un système de type Unix est assez gentil
pour modifier la MTU du lien côté PPPoE. Pas d'IPv6, le Netopia ne
le permet pas.

eth2 : IPv4 et IPv6 en VDSL2, MTU 1492, modem ZyXEL SBG3300.
Lorsqu'il est en IPv4 seul, il fonctionne parfaitement avec une MTU de
1500 et du PPPoE. Pour l'IPv6, la valeur max est une MTU de 1492.
Je viens de trouver la valeur maximal avec une dichotomie.

Les deux liens sont du Nerim First.



Encore une question : la MTU est fixée sur les routeurs ou sur le serveur ?

J'aurais bien voulu faire quelques tests complémentaires mais j'ai
l'impression que ton serveur ne répond plus sur eth2, ni en IPv4 ni en
IPv6...



J'ai quand même pu faire des tests de ping de différentes tailles vers
les adresses IPv4 et IPv6 de tes deux modems-routeurs. En IPv4, si
j'envoie un paquet de taille supérieure à 1492 sur les deux adresses, le
dernier routeur (NAS/LNS) avant la ligne xDSL renvoie un ICMP
fragmentation needed avec 1492. En IPv6 en revanche, il ne le fait pas
et le paquet est silencieusement perdu.
Publicité
Poster une réponse
Anonyme