Merci @bugmenot
Comme indiqué précédemment le ping est toujours OK vers toutes les IPv6 testées.
Mais on sait que les routes peuvent différer en fonction du protocole et du port... Si ICMP passe, ça ne veut pas dire que TCP ou SYN passe.
lr@lr-desktop:~$ ping6 ip.lafibre.info
PING ip.lafibre.info(fr.archive.ubuntu.com (2001:bc8:1600:4:63f:72ff:feaf:a2de)) 56 data bytes
64 bytes from fr.archive.ubuntu.com (2001:bc8:1600:4:63f:72ff:feaf:a2de): icmp_seq=1 ttl=49 time=22.1 ms
64 bytes from fr.archive.ubuntu.com (2001:bc8:1600:4:63f:72ff:feaf:a2de): icmp_seq=2 ttl=49 time=22.1 ms
64 bytes from fr.archive.ubuntu.com (2001:bc8:1600:4:63f:72ff:feaf:a2de): icmp_seq=3 ttl=49 time=22.3 ms
^C
--- ip.lafibre.info ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 22.120/22.186/22.293/0.075 ms
D'ailleurs, fait intéressant, j'arrive à faire un curl -4 et -6 sur mon domaine (hébergé chez Hetzner) en HTTP mais pas en HTTPS...
lr@lr-desktop:~$ curl -4 http://lrob.fr
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved here.</p>
<address>Apache Server at lrob.fr Port 80</address>
</body></html>
lr@lr-desktop:~$ curl -6 http://lrob.fr
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved here.</p>
<address>Apache Server at lrob.fr Port 80</address>
</body></html>
lr@lr-desktop:~$ curl -6 https://lrob.fr
^C
Par contre sur ip.lafibre.info, aucun succès, ni en HTTP ni en HTTPS.
lr@lr-desktop:~$ curl -6 http://ip.lafibre.info
^C
lr@lr-desktop:~$ curl -6 https://ip.lafibre.info
^C
Via telnet -6, les outputs sont intéressants, on voit que j'ai quand même une réponse invalide sur port 80, mais pas sur port 443, ce que ce soit sur mon site ou sur ip.lafibre.info
lr@lr-desktop:~$ telnet -6 lrob.fr 80
Trying 2a01:4f8:171:28e8::2...
Connected to lrob.fr.
Escape character is '^]'.
exit
HTTP/1.1 400 Bad Request
Date: Sat, 09 Mar 2024 15:57:43 GMT
Server: Apache
Content-Length: 283
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.
</p>
<address>Apache Server at default Port 80</address>
</body></html>
Connection closed by foreign host.
lr@lr-desktop:~$ telnet -6 lrob.fr 443
Trying 2a01:4f8:171:28e8::2...
Connected to lrob.fr.
Escape character is '^]'.
exit
Connection closed by foreign host.
lr@lr-desktop:~$ telnet -6 ip.lafibre.info 80
Trying 2001:bc8:1600:4:63f:72ff:feaf:a2de...
Connected to ip.lafibre.info.
Escape character is '^]'.
exit
HTTP/1.1 400 Bad Request
Date: Sat, 09 Mar 2024 15:58:41 GMT
Server: Apache
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.
</p>
</body></html>
Connection closed by foreign host.
lr@lr-desktop:~$ telnet -6 ip.lafibre.info 443
Trying 2001:bc8:1600:4:63f:72ff:feaf:a2de...
Connected to ip.lafibre.info.
Escape character is '^]'.
exit
Connection closed by foreign host.
Tandis qu'avec un site qui passe par CloudFlare, j'ai bien un retour même sur port 443 :
lr@lr-desktop:~$ telnet -6 chat.openai.com 443
Trying 2606:4700:4400::6812:25e4...
Connected to chat.openai.com.cdn.cloudflare.net.
Escape character is '^]'.
exit
HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Sat, 09 Mar 2024 16:07:31 GMT
Content-Type: text/html
Content-Length: 155
Connection: close
CF-RAY: -
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>cloudflare</center>
</body>
</html>
Connection closed by foreign host
Je vois difficilement comment une règle firewall de mon côté pourrait être la cause.
Une petite comparaison de traceroute6 et traceroute6 -T (TCP) pourrait peut-être utile ?
J'ai tenté sur différents ports pour voir avec -p mais ça ne semble pas mettre le souci en évidence.
Mon domaine sur port 80 et 443 :
lr@lr-desktop:~$ sudo traceroute6 -T -p 80 lrob.fr
[sudo] password for lr:
traceroute to lrob.fr (2a01:4f8:171:28e8::2), 30 hops max, 80 byte packets
1 2001:41d0:fc02:1f04::1 (2001:41d0:fc02:1f04::1) 0.447 ms 0.346 ms 0.318 ms
2 2001:41d0:fde0::28 (2001:41d0:fde0::28) 12.533 ms 12.751 ms 12.752 ms
3 fd00::145:239:153:165 (fd00::145:239:153:165) 12.986 ms 12.882 ms 12.847 ms
4 * * *
5 2001:41d0:aaaa:100::5 (2001:41d0:aaaa:100::5) 28.651 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3) 34.768 ms 2001:41d0:aaaa:100::5 (2001:41d0:aaaa:100::5) 28.115 ms
6 2001:41d0:aaaa:100::13 (2001:41d0:aaaa:100::13) 34.036 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3) 26.911 ms 26.107 ms
7 2001:41d0:aaaa:100::4 (2001:41d0:aaaa:100::4) 13.618 ms * 2001:41d0:aaaa:100::6 (2001:41d0:aaaa:100::6) 13.211 ms
8 * * *
9 * be105.fra-fr5-sbb2-nc5.de.eu (2001:41d0::44b) 21.382 ms *
10 ae310.fra-fr5-pb1-ptx.de.eu (2001:41d0::2631) 20.914 ms 21.118 ms 20.813 ms
11 hetzner.as24940.de.eu (2001:41d0::581) 21.651 ms hetznr.as24940.de.eu (2001:41d0::2595) 20.865 ms hetzner.as24940.de.eu (2001:41d0::581) 21.642 ms
12 core5.fra.hetzner.com (2a01:4f8:0:3::31a) 21.622 ms core4.fra.hetzner.com (2a01:4f8:0:3::2fd) 21.480 ms 21.608 ms
13 core23.fsn1.hetzner.com (2a01:4f8:0:3::4b9) 26.504 ms core24.fsn1.hetzner.com (2a01:4f8:0:3::4c9) 26.311 ms core22.fsn1.hetzner.com (2a01:4f8:0:3::4e5) 25.939 ms
14 ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::166) 26.401 ms 26.120 ms ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::16a) 25.889 ms
15 ds.lrob.net (2a01:4f8:171:28e8::2) 26.144 ms 26.328 ms 26.611 ms
lr@lr-desktop:~$ sudo traceroute6 -T -p 443 lrob.fr
traceroute to lrob.fr (2a01:4f8:171:28e8::2), 30 hops max, 80 byte packets
1 2001:41d0:fc02:1f04::1 (2001:41d0:fc02:1f04::1) 0.449 ms 0.353 ms 0.370 ms
2 2001:41d0:fde0::28 (2001:41d0:fde0::28) 12.991 ms 12.544 ms 13.075 ms
3 fd00::145:239:153:165 (fd00::145:239:153:165) 13.141 ms 12.771 ms 13.112 ms
4 * * *
5 2001:41d0:aaaa:100::5 (2001:41d0:aaaa:100::5) 31.583 ms 2001:41d0:aaaa:100::9 (2001:41d0:aaaa:100::9) 19.203 ms 2001:41d0:aaaa:100::13 (2001:41d0:aaaa:100::13) 21.752 ms
6 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3) 39.516 ms 2001:41d0:aaaa:100::7 (2001:41d0:aaaa:100::7) 36.149 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3) 27.874 ms
7 2001:41d0:aaaa:100::12 (2001:41d0:aaaa:100::12) 13.416 ms * *
8 * be102.sbg-g1-nc5.fr.eu (2001:41d0::446) 18.956 ms *
9 * * be105.fra-fr5-sbb2-nc5.de.eu (2001:41d0::44b) 21.931 ms
10 ae304.fra-fr5-pb1-ptx.de.eu (2001:41d0::262f) 21.303 ms ae310.fra-fr5-pb1-ptx.de.eu (2001:41d0::2631) 20.849 ms 2001:41d0::27d1 (2001:41d0::27d1) 23.596 ms
11 hetznr.as24940.de.eu (2001:41d0::2595) 21.060 ms hetzner.as24940.de.eu (2001:41d0::581) 21.271 ms hetznr.as24940.de.eu (2001:41d0::2595) 20.949 ms
12 core4.fra.hetzner.com (2a01:4f8:0:3::2fd) 21.517 ms core1.fra.hetzner.com (2a01:4f8:0:3::7d) 21.369 ms core4.fra.hetzner.com (2a01:4f8:0:3::51) 21.888 ms
13 core21.fsn1.hetzner.com (2a01:4f8:0:3::4d5) 25.866 ms 25.975 ms core22.fsn1.hetzner.com (2a01:4f8:0:3::4e1) 25.810 ms
14 2a01:4f8:0:3::546 (2a01:4f8:0:3::546) 26.450 ms 2a01:4f8:0:3::532 (2a01:4f8:0:3::532) 25.916 ms ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::166) 26.531 ms
15 ds.lrob.net (2a01:4f8:171:28e8::2) 26.072 ms 26.019 ms 26.307 ms
VS ip.lafibre.info
lr@lr-desktop:~$ sudo traceroute6 -T -p 80 ip.lafibre.info
traceroute to ip.lafibre.info (2001:bc8:1600:4:63f:72ff:feaf:a2de), 30 hops max, 80 byte packets
1 2001:41d0:fc02:1f04::1 (2001:41d0:fc02:1f04::1) 0.388 ms 0.366 ms 0.303 ms
2 2001:41d0:fde0::28 (2001:41d0:fde0::28) 12.534 ms 12.398 ms 12.515 ms
3 fd00::145:239:153:165 (fd00::145:239:153:165) 13.165 ms 13.256 ms 12.938 ms
4 * * *
5 2001:41d0:aaaa:100::11 (2001:41d0:aaaa:100::11) 26.336 ms 45.628 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3) 35.030 ms
6 2001:41d0:aaaa:100::11 (2001:41d0:aaaa:100::11) 35.453 ms 2001:41d0:aaaa:100::13 (2001:41d0:aaaa:100::13) 31.722 ms 31.640 ms
7 2001:41d0:aaaa:100::12 (2001:41d0:aaaa:100::12) 13.239 ms * 13.663 ms
8 be102.rbx-g2-nc5.fr.eu (2001:41d0::c70) 16.958 ms be103.rbx-g4-nc5.fr.eu (2001:41d0::25e9) 17.015 ms *
9 be102.ams-gsa1-sbb1-nc5.nl.eu (2001:41d0::25f4) 22.057 ms be101.ams-gsa1-sbb1-nc5.nl.eu (2001:41d0::61d) 21.862 ms 21.864 ms
10 ae300.ams-ams9-pb1-ptx.nl.eu (2001:41d0::2743) 21.758 ms ae301.ams-ams9-pb1-ptx.nl.eu (2001:41d0::2745) 21.354 ms 21.953 ms
11 scaleway.as12876.nl.eu (2001:41d0::2783) 22.062 ms * *
12 2001:bc8:1400:2::2 (2001:bc8:1400:2::2) 23.336 ms * *
13 * 2001:bc8:400:100::b8 (2001:bc8:400:100::b8) 22.571 ms *
14 2001:bc8:1400:1::9 (2001:bc8:1400:1::9) 23.138 ms 22.706 ms 22.340 ms
15 fr.archive.ubuntu.com (2001:bc8:1600:4:63f:72ff:feaf:a2de) 22.638 ms 22.212 ms 22.460 ms
lr@lr-desktop:~$ sudo traceroute6 -T -p 443 ip.lafibre.info
traceroute to ip.lafibre.info (2001:bc8:1600:4:63f:72ff:feaf:a2de), 30 hops max, 80 byte packets
1 2001:41d0:fc02:1f04::1 (2001:41d0:fc02:1f04::1) 0.413 ms 0.284 ms 0.358 ms
2 2001:41d0:fde0::28 (2001:41d0:fde0::28) 12.694 ms 12.571 ms 12.381 ms
3 fd00::145:239:153:165 (fd00::145:239:153:165) 13.293 ms 12.947 ms 13.075 ms
4 be51.par-gsw-pb2-nc5.fr.eu (2001:41d0::2437) 18.958 ms * *
5 2001:41d0:aaaa:100::7 (2001:41d0:aaaa:100::7) 22.894 ms 27.164 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3) 29.422 ms
6 2001:41d0:aaaa:100::7 (2001:41d0:aaaa:100::7) 44.165 ms 2001:41d0:aaaa:100::9 (2001:41d0:aaaa:100::9) 33.271 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3) 33.114 ms
7 2001:41d0:aaaa:100::4 (2001:41d0:aaaa:100::4) 13.952 ms 2001:41d0:aaaa:100::10 (2001:41d0:aaaa:100::10) 13.316 ms 2001:41d0:aaaa:100::6 (2001:41d0:aaaa:100::6) 13.498 ms
8 be102.rbx-g2-nc5.fr.eu (2001:41d0::c70) 16.981 ms be103.rbx-g3-nc5.fr.eu (2001:41d0::25e7) 16.934 ms be102.rbx-g2-nc5.fr.eu (2001:41d0::c70) 17.245 ms
9 be101.ams-gsa1-sbb1-nc5.nl.eu (2001:41d0::61d) 22.545 ms 22.373 ms be102.ams-gsa1-sbb1-nc5.nl.eu (2001:41d0::25f4) 22.083 ms
10 ae301.ams-ams9-pb1-ptx.nl.eu (2001:41d0::2745) 21.441 ms 21.512 ms 21.422 ms
11 scaleway.as12876.nl.eu (2001:41d0::2783) 21.916 ms 21.477 ms 22.216 ms
12 * 2001:bc8:1400:2:: (2001:bc8:1400:2: 23.207 ms *
13 2001:bc8:400:100::b6 (2001:bc8:400:100::b6) 22.681 ms * 2001:bc8:400:100::b8 (2001:bc8:400:100::b8) 22.332 ms
14 2001:bc8:1400:1::9 (2001:bc8:1400:1::9) 23.100 ms 22.630 ms 23.143 ms
15 fr.archive.ubuntu.com (2001:bc8:1600:4:63f:72ff:feaf:a2de) 22.141 ms 22.265 ms 22.498 ms
Mon firewall, c'est les règles par défaut IPv6 de Mikrotik qui drop juste le trafic invalide. J'ai tenté de désactiver toutes les "DROP" rules sans amélioration.
Mon "Actual MTU" est bien à 1492 sur le PPPoE (il se met automatiquement). Sur le bridge, donc mon réseau local, il est à 1500 (et 1514 pour le L2 MTU), c'est la valeur standard et par défaut qui ne pose aucun souci en IPv4. Si c'était le problème, pourquoi n'aurait-il lieu que en IPv6 vers certaines destinations de certains fournisseurs réseau ? Pour moi ça n'aurait pas de sens de chercher là tant que le MTU du PPPoE est bon.
Pour l'utilisation d'un autre routeur :
Quand j'avais tenté sous OpenSense et PFSense en début 2023, j'avais le même genre de soucis incompréhensibles. Mais je ne me souviens plus de la conf IPv6 que j'avais tenté à l'époque... Par contre j'avais aussi du packet drop sur le /29 IP additionnel, raison pour laquelle j'ai pris un Mikrotik qui a montré exactement le même problème... Dans un dernier recours je pourrais réessayer mon serveur PFSense, mais je vais déjà voir si OVH répond au ticket car je sais que c'est au moins 4h à tester alors que le souci vient probablement d'eux.
Après je viens d'acquérir un TP-Link Deco Mesh (XE75 Pro) qui fait routeur et gère le PPPoE, donc ça peut être un test utile et plus rapide, même si ça m'embêterait de devoir le reset et refaire ma conf...
Effectivement, ta conf est ultra simple, ce qui semble indiquer que ton routeur gère des paramètres pour toi. Par exemple le DHCPv6 tu n'as pas de réglage de pool ni de choix de request en mode "info, prefix, address", donc il choisit tout seul.
Pour info, la conclusion que j'avais eue sur le subnet /29 à base d'analyse de wireshark, était qu'OVH faisait du mixed routing sur le subnet en question sur 10 à 20% des paquets, entraînant 10 à 20% de packet drop et de connexions infructueuses... C'est à dire que la route prise par le paquet aller et retour diffère, ce qui est interdit par le protocole TCP et cause le drop du paquet. Mon intuition est qu'ils ont exactement ce même problème en IPv6, en tout cas sur ma ligne.