La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
OVH FAI => Discussion démarrée par: LROB le 08 mars 2024 à 04:21:56
-
Update : Workaround trouvé (merci @skid9000 de m'avoir mis sur la piste) pour corriger le non respect d'OVH de la RFC4638 permettant PMTUD.
/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=pppoe-ovh passthrough=yes protocol=tcp tcp-flags=syn
L'histoire n'est pas finie, il faut encore voir si OVH corrige sa config.
Update 2 : OVH ne bougera pas le moindre orteil pour corriger leur infra. Donc je switch vers Orange Pro sur l'offre 8/2Gbit/s (down/up).
--------------------------------------------------
Hello à tous ! :D
Après avoir longuement exploré le forum et testé des configs sans succès, je me lance enfin et sollicite votre expertise en réseau !
Bossant dans le sysadmin/web depuis une dizaine d'années, je ne suis pas expert réseau mais je ne suis pas non-plus débutant total.
J'ai crée un réseau local sympa (je crois qu'on peut dire un homelab) pour mes besoins perso-pro, en 10G à base de routeur Mikrotik RB5009UG+S+ et de Switch CRS309-1G-8S+ (et du Wifi 6E relié en 2.5G et bien-sûr un NAS et un hôte de virtualisation avec des apps cool comme PiHole, Jitsi, Uptime-Kuma, un serveur de jeux...). Cette configuration m'offre une totale liberté, avec une connexion directe au boîtier ONT d'OVH via PPPoE, fonctionnant parfaitement en IPv4.
Cependant, je rencontre un problème avec IPv6 avec mes tentatives de configuration : j'arrive éventuellement à fiablement pinger des adresses IPv6 ou accéder à certaines pages web, mais d'autres web résultent en time-outs sans explication. :-[
Des sites comme https://ipv6-test.com/ affichent (quand ils chargent) mon IPv6. Et le non fonctionnement semble random, en tout cas je n'ai pas déterminé la cause. Random, comme tous les tests que j'ai faits car je ne maîtrise pas IPv6 au point de pouvoir avancer sans aucune documentation. Car malgré des heures de recherche y-compris sur ce forum, je n'ai rien trouvé qui semble s'appliquer à mon cas. Mais peut-être que je cherche mal ou que j'ai trop de lacunes sur IPv6 (chaque fois que je creuse davantage IPv6 j'ai l'impression de ne connaître que 2% de ce qu'il faut savoir).
La seule doc officielle OVH trouvée pour les connexions type "Kosc" est celle-ci https://help.ovhcloud.com/csm/fr-internet-access-router-manual-configuration?id=kb_article_view&sysparm_article=KB0059164
C'est un peu léger en ce qui me concerne...
Une possibilité est que ma conf soit tout à fait correcte mais qu'il y aie un souci côté OVH. Mais avant de partir sur cette hypothèse et de me retrouver face au support qui me dira forcément "le problème vient de votre configuration, nous sommes parfaits", j'aimerais pouvoir m'assurer d'appliquer une configuration correcte.
Ma question est donc la suivante :
Existe-t-il une quelconque documentation sur laquelle s'appuyer pour configurer IPv6 correctement OVH FTTH sur routeur Mikrotik ?
Et si non, en existe-t-il d'autres qu'on puisse extrapoler ?
Je peux partager mes tentatives de configuration si ça aide, mais je préférerais toutefois partir d'une base sûre.
Merci par avance pour votre aide. :)
-
Je n'ai pas de Mikrotik mais la configuration sur Edgerouter est assez simple.
Pour un peu de contexte, je suis en collecte Kosc sur réseau Orange, eth0 est mon arrivée WAN (ONT) et eth2&3 mes interfaces LAN.
Contrairement à ce qui est indiqué dans la documentation, je n'ai pas de VLAN à configurer.
Voici un extrait de configuration, avec mes commentaires en rouge :
EdgeRouter-4# show interfaces ethernet eth0 pppoe
pppoe 0 {
default-route auto #Injection d'une route par défaut quand le pppoe est actif, de tête, c'est IPv4 et IPv6
dhcpv6-pd { #Cette partie concerne la délégation sur mes différentes interfaces LAN
pd 1 {
interface eth2.10 {
host-address ::1
prefix-id ::a
service dhcpv6-stateless
}
interface eth3.101 {
host-address ::1
prefix-id ::1
service dhcpv6-stateless
}
interface eth3.150 {
host-address ::1
prefix-id ::5
service dhcpv6-stateless
}
interface eth3.200 {
host-address ::1
prefix-id ::2
service dhcpv6-stateless
}
prefix-length 56
}
rapid-commit enable
}
ipv6 { #La configuration pour récupérer le préfixe IPv6
address {
autoconf
}
dup-addr-detect-transmits 1
enable {
}
}
mtu 1492 #MTU à réduire de 8 octets à cause de l'encapsulation PPPoE
name-server auto
password {Mot de passe PPPoE}
user-id {Nom d'utilisateur PPPoE}
En espérant que cela t'aide...
-
Merci beaucoup pour ta réponse @Zeda !
Je te confirme que ça aide.
J'ai également un ami qui a fait fonctionner Mikrotik avec une config similaire avec Orange, je me suis pas mal appuyé sur ses réglages et ce que je sais des tiens.
Je pense avoir trouvé une conf fonctionnelle... Et je l'avais sûrement déjà trouvée avant vu que j'ai vraiment testé toutes les confs possibles et imaginables... Sauf que... J'ai compris un truc fondamental : Le problème semble être un problème d'interco en IPv6 TCP avec certains providers de réseau.
CF le ticket que je viens d'ouvrir à OVH.
Il est impossible de communiquer en TCP en IPv6 avec certaines fournisseurs de réseau depuis ma connexions OVH FTTH.
Dans la mesure où certains fournisseurs fonctionnent et d'autres pas, cela suggère que ma config est bonne mais qu'un problème de routage existe dans l'infra OVH. ICMP ne pose strictement aucun problème peu importe la source/destination. Mais TCP ne passe pas du tout avec certains fournisseurs alternatifs (les plus gros fonctionnent mais pas les plus petits).
Exemples de fournisseurs OK en TCP IPv6 :
OVH
CloudFlare
Google / Google Cloud
Facebook
Amazon
Exemples de fournisseurs inaccessibles en TCP IPv6 :
Hetzner
Scaleway
Ikoula
Exemples de sites/domaines inaccessibles :
https://ip.lafibre.info
https://www.lrob.fr
Traceroute de Hetzner vers mon IPv6 :
1) Classique via ICMP
root@ds ~ # traceroute6 2001:41d0:fc02:1f03::1
traceroute to 2001:41d0:fc02:1f03::1 (2001:41d0:fc02:1f03::1), 30 hops max, 80 byte packets
1 2a01:4f8::a:17:a (2a01:4f8::a:17:a) 2.323 ms 2.232 ms 2.328 ms
2 core23.fsn1.hetzner.com (2a01:4f8:0:3::165) 0.592 ms 2a01:4f8:0:3::531 (2a01:4f8:0:3::531) 4.623 ms 4.608 ms
3 2a01:4f8:0:3::4d2 (2a01:4f8:0:3::4d2) 4.963 ms 2a01:4f8:0:3::4da (2a01:4f8:0:3::4da) 4.947 ms core1.fra.hetzner.com (2a01:4f8:0:3::4c6) 4.932 ms
4 core8.fra.hetzner.com (2a01:4f8:0:3::315) 5.145 ms core9.fra.hetzner.com (2a01:4f8:0:3::2fa) 5.130 ms core9.fra.hetzner.com (2a01:4f8:0:3::34e) 5.115 ms
5 ae101.fra-fr5-pb1-ptx.de.eu (2001:41d0::580) 5.216 ms * 5.184 ms
6 2001:41d0:aaaa:100::7 (2001:41d0:aaaa:100::7) 31.257 ms 2001:41d0:aaaa:100::5 (2001:41d0:aaaa:100::5) 17.853 ms 2001:41d0:aaaa:100::7 (2001:41d0:aaaa:100::7) 41.304 ms
7 2001:41d0:aaaa:100::11 (2001:41d0:aaaa:100::11) 20.348 ms 2001:41d0:aaaa:100::5 (2001:41d0:aaaa:100::5) 28.985 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3) 12.357 ms
8 2001:41d0:aaaa:100::6 (2001:41d0:aaaa:100::6) 5.740 ms * *
9 be101.sbg-g1-nc5.fr.eu (2001:41d0::444) 8.378 ms * *
10 * be103.par-th2-sbb1-nc5.fr.eu (2001:41d0::447) 14.219 ms *
11 * be302.par-gsw-pb2-nc5.fr.eu (2001:41d0::25c7) 14.040 ms *
12 th2-dsl2-n93.fr.eu (2001:41d0::2432) 14.416 ms 14.423 ms th2-dsl1-a1.fr.eu (2001:41d0::b76) 14.186 ms
13 2001:41d0:fde0:80::121 (2001:41d0:fde0:80::121) 14.428 ms 2001:41d0:fde0:80::123 (2001:41d0:fde0:80::123) 14.442 ms 2001:41d0:fde0:80::125 (2001:41d0:fde0:80::125) 14.367 ms
14 * * 2001:41d0:fc02:1f03::1 (2001:41d0:fc02:1f03::1) 26.046 ms
2) En TCP forcé
root@ds ~ # traceroute6 -T 2001:41d0:fc02:1f03::1
traceroute to 2001:41d0:fc02:1f03::1 (2001:41d0:fc02:1f03::1), 30 hops max, 80 byte packets
1 2a01:4f8::a:17:a (2a01:4f8::a:17:a) 0.446 ms 0.424 ms 0.527 ms
2 core23.fsn1.hetzner.com (2a01:4f8:0:3::165) 0.404 ms core22.fsn1.hetzner.com (2a01:4f8:0:3::545) 0.397 ms 0.503 ms
3 2a01:4f8:0:3::4e2 (2a01:4f8:0:3::4e2) 5.054 ms 4.911 ms 2a01:4f8:0:3::4de (2a01:4f8:0:3::4de) 4.905 ms
4 core9.fra.hetzner.com (2a01:4f8:0:3::2fa) 5.190 ms core8.fra.hetzner.com (2a01:4f8:0:3::52) 5.183 ms core8.fra.hetzner.com (2a01:4f8:0:3::7e) 5.176 ms
5 ae101.fra-fr5-pb1-ptx.de.eu (2001:41d0::580) 5.168 ms * *
6 2001:41d0:aaaa:100::9 (2001:41d0:aaaa:100::9) 24.653 ms 2001:41d0:aaaa:100::5 (2001:41d0:aaaa:100::5) 41.570 ms 2001:41d0:aaaa:100::11 (2001:41d0:aaaa:100::11) 25.976 ms
7 2001:41d0:aaaa:100::7 (2001:41d0:aaaa:100::7) 26.651 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3) 21.476 ms 2001:41d0:aaaa:100::11 (2001:41d0:aaaa:100::11) 13.612 ms
8 2001:41d0:aaaa:100::12 (2001:41d0:aaaa:100::12) 5.864 ms * *
9 be101.sbg-g2-nc5.fr.eu (2001:41d0::44a) 8.235 ms be101.sbg-g1-nc5.fr.eu (2001:41d0::444) 8.199 ms be101.sbg-g2-nc5.fr.eu (2001:41d0::44a) 8.162 ms
10 * be103.par-gsw-sbb1-nc5.fr.eu (2001:41d0::44d) 14.373 ms *
11 * * *
12 th2-dsl2-n93.fr.eu (2001:41d0::2432) 14.392 ms 14.500 ms th2-dsl1-a1.fr.eu (2001:41d0::b74) 14.366 ms
13 2001:41d0:fde0:80::121 (2001:41d0:fde0:80::121) 14.445 ms * *
14 * * *
[...]
30 * * *
Cela pourrait être lié au problème que j'ai déjà observé et que vous n'avez pas résolu avec le subnet additionnel où 10 à 20% des paquets étaient perdu, avec pour cause selon moi un problème de mixed routing sur vos équipements. Vous aviez suggéré que le souci provenait de mes équipements et je n'en suis toujours pas convaincu car ma config est simple et standard et reproduite sur plusieurs types de routeurs avec de nombreux essais de configuration.
Voilà... Plausible mon diagnostic selon vous ?
-
Bonjour,
Je ne peut malheureusement pas t’aider pour Mikrotik mais étant moi même chez OVH en FTTH je peut te confirmer que les sites que tu mentionnes marchent bien en TCP/IPv6.
Par exemple un curl -6 ip.lafibre.info me renvoie bien une page qui mentionne bien mon IPv6 comme adresse source.
-
Merci pour le feedback @bugmenot
Donc le souci n'est pas global chez OVH. Sais-tu si comme moi tu passes par Kosc et terminaison Orange ? (un indicateur simple est ton identifiant PPPoE qui contient "Kosc" ou non)
Aussi, je suppose que la localité peut avoir un impact sur les routes, de mon côté je suis d'Orléans.
Le même test chez moi :
lr@lr-desktop:~$ host ip.lafibre.info
ip.lafibre.info has address 51.158.154.169
ip.lafibre.info has IPv6 address 2001:bc8:1600:4:63f:72ff:feaf:a2de
lr@lr-desktop:~$ curl -6 ip.lafibre.info
#(ça n'abouti jamais donc j'annule avec ctrl +c)
^C
lr@lr-desktop:~$ curl -6 ifconfig.me
2001:41d0:fc02:1f04[...]]
Je vois pas trop comment un tel souci pourrait venir de ma configuration... A ce stade je suis parvenu à avoir un comportement parfaitement normal sur tous les points (attributions d'IP, détection des neighbors qui ne sont plus en erreur sur le routeur, ping OK de toutes les IP testées, accès HTTP(s) IPv6 de la plupart des sites...). Je suis convaincu que le souci vient d'OVH.
Cependant, voici ma conf Mikrotik complète au cas où, que j'ai repassée au peigne fin plusieurs fois mais qui sait... :
(Pour info j'ai déjà tenté en désactivant mes règles NAT IPv4, en désactivant toute règle de drop firewall IPv4 et IPv6, en activant/désactivant l'encryption PPPoE -> même comportement.)
# 2024-03-09 10:34:25 by RouterOS 7.14
# software id = Y9Q5-Q5D5
#
# model = RB5009UG+S+
# serial number = HE708[HIDDEN]
/interface bridge
add admin-mac=48:A9:8A:[HIDDEN] auto-mac=no comment=defconf name=bridge port-cost-mode=short
/interface ethernet
set [ find default-name=ether1 ] name=ether1-2.5G
set [ find default-name=ether2 ] name=ether2_Servers
set [ find default-name=ether8 ] name=ether8-1G_WAN
set [ find default-name=sfp-sfpplus1 ] name=sfpplus
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec proposal
set [ find default=yes ] disabled=yes
/ip pool
add name=dhcp ranges=192.168.1.65-192.168.1.250
/ip dhcp-server
add address-pool=dhcp interface=bridge lease-time=5m name=defconf
/ipv6 dhcp-server
add address-pool="" interface=bridge lease-time=1h name=LAN_v6
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether8-1G_WAN name=pppoe-ovh profile=default-encryption use-peer-dns=\
yes user=[HIDDEN]@ovh.kosc
/interface bridge port
add bridge=bridge comment=defconf interface=ether2_Servers internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether3 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether4 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether5 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether6 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether7 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=sfpplus internal-path-cost=10 path-cost=10
add bridge=bridge interface=ether1-2.5G internal-path-cost=10 path-cost=10
/ip firewall connection tracking
set udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN lldp-med-net-policy-vlan=1
/ipv6 settings
set accept-router-advertisements=yes
/interface detect-internet
set detect-interface-list=WAN internet-interface-list=WAN lan-interface-list=LAN wan-interface-list=WAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment="OVH WAN" interface=pppoe-ovh list=WAN
add comment="OVH WAN PPPoE" interface=ether8-1G_WAN list=WAN
/ip address
add address=192.168.1.1/24 comment=defconf interface=bridge network=192.168.1.0
/ip dhcp-server lease
add address=192.168.1.30 comment="Philips Hue Hub1" mac-address=EC:B5:FA:[HIDDEN] server=defconf
add address=192.168.1.25 client-id=1:0:bb:c1:[HIDDEN] comment="Imprimante Canon" mac-address=00:BB:C1:[HIDDEN] \
server=defconf
add address=192.168.1.64 client-id=1:80:61:5f:[HIDDEN] comment="Main PC SFP+" mac-address=80:61:5F:[HIDDEN] server=\
defconf
add address=192.168.1.33 comment="Meross Plug3" mac-address=48:E1:E9:[HIDDEN] server=defconf
add address=192.168.1.32 comment="Meross Plug2" mac-address=48:E1:E9:[HIDDEN] server=defconf
add address=192.168.1.31 comment="Meross Plug1" mac-address=48:E1:E9:[HIDDEN] server=defconf
add address=192.168.1.62 client-id=1:8:16:d5:[HIDDEN] comment=Pico4 mac-address=08:16:D5:[HIDDEN] server=defconf
add address=192.168.1.60 client-id=1:8a:4b:59:[HIDDEN] comment="Mi 9T Pro" mac-address=8A:4B:59:[HIDDEN] server=\
defconf
add address=192.168.1.2 client-id=1:78:9a:18:[HIDDEN] comment="CRS309 SW10G_01" mac-address=78:9A:18:[HIDDEN] server=\
defconf
add address=192.168.1.10 client-id=ff:a9:7a:36:[HIDDEN] comment="NAS 10G" \
mac-address=64:9D:99:[HIDDEN] server=defconf
/ip dhcp-server network
add address=192.168.1.0/24 comment=defconf dns-server=192.168.1.254 gateway=192.168.1.1 netmask=24 next-server=\
192.168.1.254
/ip dns
set allow-remote-requests=yes cache-max-ttl=30s cache-size=4096KiB query-total-timeout=4s servers=192.168.1.254
/ip dns static
add address=192.168.1.1 comment=defconf name=router.lan
/ip firewall address-list
add address=109.190.121.43 comment="OVH 109.190.121.43" list=WAN-IP
/ip firewall filter
add action=accept chain=input comment="Defconf accept related established" connection-state=established,related
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related \
hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="Hairpin LAN" disabled=yes dst-address=192.168.1.0/24 src-address=\
192.168.1.0/24
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface-list=WAN
add action=dst-nat chain=dstnat comment="NAS FTP backups" disabled=yes dst-address-list=WAN-IP dst-port=2121 \
protocol=tcp to-addresses=192.168.1.10
add action=dst-nat chain=dstnat comment="FTP Backup passive ports" disabled=yes dst-address-list=WAN-IP dst-port=\
49152-65534 protocol=tcp to-addresses=192.168.1.10
add action=dst-nat chain=dstnat comment="Web reverse proxy" disabled=yes dst-address-list=WAN-IP dst-port=443 \
protocol=tcp to-addresses=192.168.1.254
add action=dst-nat chain=dstnat comment="Web reverse proxy" disabled=yes dst-address-list=WAN-IP dst-port=80 \
protocol=tcp to-addresses=192.168.1.254
add action=dst-nat chain=dstnat comment="Web Jitsi UDP" disabled=yes dst-address-list=WAN-IP dst-port=10000,3478 \
protocol=udp to-addresses=192.168.1.254
add action=dst-nat chain=dstnat comment="Jitsi TCP fallback" disabled=yes dst-address-list=WAN-IP dst-port=5349,5350 \
protocol=tcp to-addresses=192.168.1.254
add action=dst-nat chain=dstnat comment="Game server DMZ" disabled=yes dst-address-list=WAN-IP to-addresses=\
192.168.1.16
/ip ipsec policy
set 0 disabled=yes
/ip tftp
add ip-addresses=192.168.1.254 real-filename=/netboot.xyz/netboot.xyz.efi req-filename=.*
/ip upnp
set enabled=yes
/ip upnp interfaces
add interface=pppoe-ovh type=external
add interface=bridge type=internal
/ipv6 address
add address=::1 from-pool=ovh-v6 interface=bridge
/ipv6 dhcp-client
add add-default-route=yes interface=pppoe-ovh pool-name=ovh-v6 request=prefix use-peer-dns=no
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
add address=::224.0.0.0/100 comment="defconf: other" list=bad_ipv6
add address=::127.0.0.0/104 comment="defconf: other" list=bad_ipv6
add address=::/104 comment="defconf: other" list=bad_ipv6
add address=::255.0.0.0/104 comment="defconf: other" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=33434-33534 protocol=udp
add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp \
src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=forward comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN
/ipv6 nd
set [ find default=yes ] managed-address-configuration=yes other-configuration=yes ra-interval=20s-1m
/system clock
set time-zone-name=Europe/Paris
/system identity
set name=home.lrob.net
/system note
set show-at-login=no
/tool graphing interface
add allow-address=192.168.1.0/24
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
Si c'est imbuvable je peux éditer ça pour ne laisser que les infos IPv6.
(Mon IP publique est vraiment publique pour le coup, j'héberge des services, donc pas de souci à l'afficher)
Voici aussi les IPv6 attribuées (la /64 publique sur le bridge est la seule que j'ai ajoutée manuellement, sans elle la connexion IPv6 ne fonctionne pas)
(https://cloud.lrob.fr/s/aHqkDP9PxHKdoGe/download/ipv6-attributed-ovh-mikrotik.png)
Et enfin les routes IPv6 push par PPPoE
(https://cloud.lrob.fr/s/RRZFfmCTTfNokT4/download/routes-ipv6-defaut-ovh-mikrotik.png)
Pour la science ;D
-
Oui je suis bien en collecte Kosc (mais sur l’infra Altitude de mon département). Terminaison de mon lien PPPoE sur 145.239.153.19.
Quelques idées:
- ping6 sur ip.lafibre.info donne quoi ?
- une histoire de firewall ou de mtu ?
- le test ultime en prenant un autre routeur sous un autre OS et une config basique ? Quand j’ai eu des soucis de perf avec OVH ca a été mon argument massue pour démontrer que le souci ne venait pas de chez moi.
Pour comparaison ma config WAN est super simple
config interface 'wan'
option device 'br-wan'
option proto 'pppoe'
option username 'xxx@ovh.kosc'
option password 'xxx'
option ipv6 'auto'
option mtu '1492'
config interface 'wan6'
option device 'br-wan'
option proto 'dhcpv6'
-
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 (https://www.lrob.fr/).</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 (https://www.lrob.fr/).</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.
-
Si tu as un desktop sous Linux le plus simple serait de te brancher en ethernet derrière l’ONT, monter la session pppoe, un coup de dhcpv6 et tu seras vite fixé.
-
bonjour,
vu que tu as une connectivité IPv6 et qu'il n'y a que vers certains serveurs que ça bloque, ça sent le "blocage" de la plage IPv6 chez les destinataires.
Peut être que cette plage était "flagguée" Datacenter avant et qu'ils n'ont pas mis à jour.
-
Si tu as un desktop sous Linux le plus simple serait de te brancher en ethernet derrière l’ONT, monter la session pppoe, un coup de dhcpv6 et tu seras vite fixé.
Bonne idée.
Mais IPv6 non fonctionnel en PPPoE en direct. DHCPv6 ne semble pas faire le job attendu, je n'ai pas d'IPv6 publique assignée.
(https://cloud.lrob.fr/s/F2Q3QGAsDZJocMz/download/Screenshot%20from%202024-03-09%2012-14-16.png)
Hello @buddy
Possible, un anti-ddos bloqué sur ce range ou autre... Mais comment vérifier ?
Je vais peut-être tenter un ticket à Hetzner pour voir s'ils ont un avis.
-
Un truc bizarre, sous Linux j'ai tenté un pppoe-discovery, puis sous Mikrotik un PPPoE Scan (c'est pareil), je trouve dans les deux cas deux résultats en "Access Concentrator" :
MAC 06:00:C2:00:00:00
AC Name: 1012.sra8.p44nts.west
MAC: 06:00:87:00:00:00
AC Name: 1008.sra8.p69vnx.rhone-alpes
Avec une recherche Google je trouve deux résultats qui détectent "1008.sra8.p69vnx.rhone-alpes" sur une image. (et comme par hasard ça pointe encore sur ce forum ! ;D )
https://lafibre.info/ovh-fai/partage-dexperience-ovh-fibre-ftth-1g/
https://lafibre.info/milkywan/milkywan-as57199/432/
N'est-on pas sensés en trouver qu'un seul ? Sur les captures de @Aize147 il n'y en a qu'un, le 1008.sra8.p69vnx.rhone-alpes.
Edit: Sûrement une fausse piste. J'étais sur 1012.sra8.p44nts.west, j'ai tenté de forcer l'autre, pas de changement.
-
Bonjour,
+1 pour un problème de MTU.
au pire, tu peux essayer:
curl https://ipv6.lafibre.info/ip.php
c'est exactement la même ip que ip.lafibre.info, mais avec une page bcp plus petite, vu qu'elle contient que ton ip.
si ça fonctionne, le problème de MTU se confirmera.
-
Bonjour,
+1 pour un problème de MTU.
au pire, tu peux essayer:
curl https://ipv6.lafibre.info/ip.php
c'est exactement la même ip que ip.lafibre.info, mais avec une page bcp plus petite, vu qu'elle contient que ton ip.
si ça fonctionne, le problème de MTU se confirmera.
Hello !
A quel niveau le MTU poserait problème selon toi ? En PPPoE il est bien à 1492 comme attendu.
curl -6 https://ipv6.lafibre.info/ip.php ne fonctionne pas mieux.
Je me disais que ça pourrait être la version de TLS qui joue mais non, certains sites en TLS 1.3 fonctionnent et d'autres pas.
Avec un peu plus de verbosité :
lr@lr-desktop:~$ curl -6 --verbose -S -X HEAD https://ipv6.lafibre.info/ip.php
Warning: Setting custom HTTP method to HEAD with -X/--request may not work the
Warning: way you want. Consider using -I/--head instead.
* Trying 2001:bc8:1600:4:63f:72ff:feaf:a2de:443...
* Connected to ipv6.lafibre.info (2001:bc8:1600:4:63f:72ff:feaf:a2de) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
^C
lr@lr-desktop:~$ curl -6 --verbose -S -X HEAD http://ipv6.lafibre.info/ip.php
Warning: Setting custom HTTP method to HEAD with -X/--request may not work the
Warning: way you want. Consider using -I/--head instead.
* Trying 2001:bc8:1600:4:63f:72ff:feaf:a2de:80...
* Connected to ipv6.lafibre.info (2001:bc8:1600:4:63f:72ff:feaf:a2de) port 80 (#0)
> HEAD /ip.php HTTP/1.1
> Host: ipv6.lafibre.info
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sun, 10 Mar 2024 10:13:39 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Access-Control-Allow-Origin: *
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Content-Type: text/plain;charset=UTF-8
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection 0
lr@lr-desktop:~$ curl -6 --verbose -S -X HEAD https://chat.openai.com
Warning: Setting custom HTTP method to HEAD with -X/--request may not work the
Warning: way you want. Consider using -I/--head instead.
* Trying 2606:4700:4400::ac40:961c:443...
* Connected to chat.openai.com (2606:4700:4400::ac40:961c) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=chat.openai.com
* start date: Oct 25 00:00:00 2023 GMT
* expire date: Oct 23 23:59:59 2024 GMT
* subjectAltName: host "chat.openai.com" matched cert's "chat.openai.com"
* issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5590cf444620)
> HEAD / HTTP/2
> Host: chat.openai.com
[...]
Autre output avec openssl qui fonctionne en IPv4 mais pas IPv6... :
lr@lr-desktop:~$ openssl s_client -6 -connect www.lrob.fr:443
CONNECTED(00000003)
^C
lr@lr-desktop:~$ openssl s_client -4 -connect www.lrob.fr:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = lrob.fr
verify return:1
---
Certificate chain
0 s:CN = lrob.fr
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF/DCCBOSgAwIBAgISA0yeW1+/1+MN3PPjh0299TobMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYw
[...]
J'ai tenté avec les autres MTU PPPoE proposés par OVH :
MTU: 1432 ou 1456 ou 1492 (recommandé)
1432 n'est pas accepté par Mikrotik, et 1456 donne le même résultat.
J'ai tenté de mettre 1492 MTU sur le bridge, pas de changement.
MTU 1492 sur l'ethernet où arrive le WAN directement : Internet ne fonctionne plus et ça abaisse le PPPoE MTU à 1484.
Je commence à devenir zinzin. ::)
-
Hetzner demande des MTR. J'aurais dû penser à en faire avant...
Alors j'suis vraiment pas expert, mais j'ai vraiment l'impression que tout merde côté OVH.
OVH -> Hetzner
lr@lr-desktop:~$ mtr -6 -b -s 1000 -r -c 200 ds.lrob.net
Start: 2024-03-10T15:02:03+0100
HOST: lr-desktop Loss% Snt Last Avg Best Wrst StDev
1.|-- 2001:41d0:fc02:1f03::1 0.0% 200 0.9 3.6 0.8 15.6 4.0
2.|-- 2001:41d0:fde0::28 0.5% 200 19.3 24.9 19.0 81.4 10.3
3.|-- fd00::145:239:153:165 0.0% 200 19.7 20.6 19.4 35.6 2.4
4.|-- be51.par-gsw-pb1-nc5.fr.e 49.0% 200 19.6 527.3 19.2 7514. 1559.4
2001:41d0:fde0::28
2001:41d0:aaaa:100::8
fd00::145:239:153:165
2001:41d0:aaaa:100::5
2001:41d0:fc02:1f03::1
google.as15169.fr.eu (2001:41d0::171)
google.as15169.fr.eu (2001:41d0::269d)
5.|-- be310.par-th2-sbb1-nc5.fr 25.0% 200 20.1 382.6 19.5 9379. 1642.1
2001:41d0:aaaa:100::8
2001:41d0:aaaa:100::13
fd00::145:239:153:165
be315.par-th2-pb3-nc5.fr.eu (2001:41d0::25e3)
2001:41d0:aaaa:100::7
2001:41d0:fc02:1f03::1
6.|-- be102.sbg-g1-nc5.fr.eu (2 48.0% 200 32.2 524.3 25.2 8175. 1707.8
2001:41d0:aaaa:100::9
google.as15169.fr.eu (2001:41d0::832)
fd00::145:239:153:165
2001:41d0:fde0::28
2001:41d0:aaaa:100::10
2001:41d0:aaaa:100::8
2001:41d0:fc02:1f03::1
7.|-- be105.fra-fr5-sbb1-nc5.de 17.0% 200 29.0 82.0 28.0 8224. 635.8
fd00::145:239:153:165
8.|-- ae304.fra-fr5-pb1-ptx.de. 0.0% 200 28.2 30.4 27.4 47.0 4.3
9.|-- hetzner.as24940.de.eu (20 0.0% 200 28.6 29.0 27.7 37.6 2.3
10.|-- core0.fra.hetzner.com (2a 0.0% 200 28.7 29.1 27.8 37.5 2.7
11.|-- core24.fsn1.hetzner.com ( 0.0% 200 33.3 34.0 32.5 40.9 2.1
12.|-- ex9k1.dc8.fsn1.hetzner.co 0.0% 200 33.5 34.9 32.5 50.1 3.3
13.|-- ds.lrob.net (2a01:4f8:171 0.0% 200 33.3 34.5 32.5 45.9 3.3
OVH -> Hetzner TCP
lr@lr-desktop:~$ mtr -6 -T -b -s 1000 -r -c 200 ds.lrob.net
Start: 2024-03-10T15:01:56+0100
HOST: lr-desktop Loss% Snt Last Avg Best Wrst StDev
1.|-- 2001:41d0:fc02:1f03::1 0.0% 200 1.3 2.1 1.1 18.6 2.9
2.|-- 2001:41d0:fde0::28 0.0% 200 19.6 22.8 19.2 77.8 9.7
3.|-- fd00::145:239:153:165 0.0% 200 20.1 21.0 19.6 31.2 2.8
4.|-- be51.par-gsw-pb2-nc5.fr.e 73.0% 200 19.6 2555. 19.6 9497. 3125.1
be51.par-gsw-pb1-nc5.fr.eu (2001:41d0::b75)
be305.par-th2-pb3-nc5.fr.eu (2001:41d0::25d1)
2001:41d0:aaaa:100::7
2001:41d0:fde0::28
google.as15169.fr.eu (2001:41d0::171)
fd00::145:239:153:165
5.|-- 2001:41d0:aaaa:100::7 1.5% 200 52.1 428.0 25.5 7950. 1347.4
2001:41d0:aaaa:100::5
2001:41d0:aaaa:100::13
2001:41d0:aaaa:100::3
2001:41d0:aaaa:100::9
2001:41d0:aaaa:100::11
2001:4860:0:1::1a5b
2001:4860:0:1::23b9
6.|-- 2001:41d0:aaaa:100::7 2.5% 200 36.5 482.5 25.5 7269. 1442.6
2001:41d0:aaaa:100::5
2001:41d0:aaaa:100::9
2001:41d0:aaaa:100::3
2001:41d0:aaaa:100::11
2001:41d0:aaaa:100::13
2001:41d0:fc02:1f03::1
google.as15169.fr.eu (2001:41d0::171)
7.|-- 2001:41d0:aaaa:100::8 25.5% 200 3130. 1770. 19.8 9627. 2361.7
2001:41d0:aaaa:100::12
2001:41d0:aaaa:100::4
2001:41d0:aaaa:100::6
2001:41d0:aaaa:100::2
2001:41d0:aaaa:100::10
2001:41d0:fde0::28
2001:41d0:aaaa:100::9
8.|-- be102.sbg-g2-nc5.fr.eu (2 37.5% 200 7190. 2036. 25.7 9686. 2601.9
be102.sbg-g1-nc5.fr.eu (2001:41d0::446)
ams-1-a9.nl.eu (2001:41d0::257d)
2001:4860:0:1::19d1
fd00::145:239:153:165
google.as15169.fr.eu (2001:41d0::269d)
2001:41d0:fc02:1f03::1
2001:41d0:aaaa:100::13
9.|-- be105.fra-fr5-sbb2-nc5.de 35.5% 200 1044. 2084. 28.1 7278. 2565.0
be105.fra-fr5-sbb1-nc5.de.eu (2001:41d0::445)
2001:41d0:fc02:1f03::1
2001:4860:0:1::1f97
be315.par-th2-pb3-nc5.fr.eu (2001:41d0::25e3)
2001:4860:0:1::7001
10.|-- ae304.fra-fr5-pb1-ptx.de. 3.5% 200 28.0 970.1 27.7 7304. 1719.4
2001:41d0::27cf
ae310.fra-fr5-pb1-ptx.de.eu (2001:41d0::2631)
2001:41d0::27d1
2001:41d0:aaaa:100::13
2001:41d0:fc02:1f03::1
11.|-- hetzner.as24940.de.eu (20 0.0% 200 28.1 29.9 27.9 43.0 2.8
hetznr.as24940.de.eu (2001:41d0::2595)
12.|-- core5.fra.hetzner.com (2a 0.0% 200 29.3 30.1 27.9 41.9 3.1
core0.fra.hetzner.com (2a01:4f8:0:3::34d)
core1.fra.hetzner.com (2a01:4f8:0:3::2f9)
core1.fra.hetzner.com (2a01:4f8:0:3::7d)
core5.fra.hetzner.com (2a01:4f8:0:3::31a)
core4.fra.hetzner.com (2a01:4f8:0:3::51)
core0.fra.hetzner.com (2a01:4f8:0:3::33e)
core4.fra.hetzner.com (2a01:4f8:0:3::2fd)
13.|-- core22.fsn1.hetzner.com ( 0.0% 200 32.9 34.7 32.5 44.4 3.3
core24.fsn1.hetzner.com (2a01:4f8:0:3::4c5)
core23.fsn1.hetzner.com (2a01:4f8:0:3::4b5)
core23.fsn1.hetzner.com (2a01:4f8:0:3::4b9)
core21.fsn1.hetzner.com (2a01:4f8:0:3::4d1)
core24.fsn1.hetzner.com (2a01:4f8:0:3::4cd)
core22.fsn1.hetzner.com (2a01:4f8:0:3::4e9)
core21.fsn1.hetzner.com (2a01:4f8:0:3::4dd)
core24.fsn1.hetzner.com (2a01:4f8:0:3::4c1)
14.|-- 2a01:4f8:0:3::546 0.0% 200 51.4 36.8 32.7 56.2 4.4
ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::166)
2a01:4f8:0:3::532
ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::16a)
15.|-- ds.lrob.net (2a01:4f8:171 0.0% 200 34.3 33.7 32.7 42.6 2.0
Hetzner -> OVH
root@ds ~ # mtr -6 -b -s 1000 -r -c 200 2001:41d0:fc02:1f03:5919:d591:207a:f643
Start: 2024-03-10T15:02:20+0100
HOST: ds.lrob.net Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:4f8::a:17:a 0.0% 200 2.0 1.2 0.3 20.8 2.1
2.|-- core23.fsn1.hetzner.com ( 0.0% 200 0.6 2.9 0.3 34.4 5.8
3.|-- core5.fra.hetzner.com (2a 0.0% 200 5.0 5.0 4.9 5.3 0.1
4.|-- core8.fra.hetzner.com (2a 0.0% 200 5.6 5.3 5.2 5.7 0.1
5.|-- be104.fra-fr5-pb4-nc5.de. 98.5% 200 8.5 7.9 7.6 8.5 0.5
6.|-- 2001:41d0::27ce 16.0% 200 6.3 6.2 5.9 6.6 0.2
7.|-- be101.sbg-g1-nc5.fr.eu (2 75.5% 200 8.6 12.7 8.3 75.8 13.8
8.|-- be103.par-th2-sbb1-nc5.fr 40.5% 200 14.4 14.3 14.0 14.7 0.2
9.|-- be312.par-gsw-pb2-nc5.fr. 60.5% 200 14.4 32.3 14.1 1437. 160.2
be103.par-gsw-sbb1-nc5.fr.eu (2001:41d0::44d)
10.|-- th2-dsl1a-n93.fr.eu (2001 0.0% 200 14.8 14.6 14.4 15.2 0.1
11.|-- ??? 100.0 200 0.0 0.0 0.0 0.0 0.0
12.|-- 2001:41d0:fc02:1f03::1 0.0% 200 32.8 32.2 31.8 32.8 0.2
13.|-- 2001:41d0:fc02:1f03:5919: 0.5% 200 32.8 32.3 32.0 33.1 0.2
Hetzner -> OVH TCP
root@ds ~ # mtr -6 -T -b -s 1000 -r -c 200 2001:41d0:fc02:1f03:5919:d591:207a:f643
Start: 2024-03-10T15:02:14+0100
HOST: ds.lrob.net Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:4f8::a:17:a 0.0% 200 0.6 2.2 0.3 22.0 4.2
2.|-- core22.fsn1.hetzner.com ( 0.0% 200 32.8 6.0 0.4 53.9 11.0
core23.fsn1.hetzner.com (2a01:4f8:0:3::165)
2a01:4f8:0:3::531
core24.fsn1.hetzner.com (2a01:4f8:0:3::169)
3.|-- 2a01:4f8:0:3::4d6 0.0% 200 5.3 5.2 4.9 5.6 0.2
core0.fra.hetzner.com (2a01:4f8:0:3::4c2)
core5.fra.hetzner.com (2a01:4f8:0:3::4be)
core4.fra.hetzner.com (2a01:4f8:0:3::4ba)
2a01:4f8:0:3::4ea
core5.fra.hetzner.com (2a01:4f8:0:3::4ce)
2a01:4f8:0:3::4de
2a01:4f8:0:3::4d2
2a01:4f8:0:3::4e2
4.|-- core9.fra.hetzner.com (2a 0.0% 200 5.6 5.4 5.1 5.9 0.2
core9.fra.hetzner.com (2a01:4f8:0:3::2fe)
core8.fra.hetzner.com (2a01:4f8:0:3::315)
core8.fra.hetzner.com (2a01:4f8:0:3::7e)
core9.fra.hetzner.com (2a01:4f8:0:3::319)
core9.fra.hetzner.com (2a01:4f8:0:3::34e)
core8.fra.hetzner.com (2a01:4f8:0:3::52)
core8.fra.hetzner.com (2a01:4f8:0:3::33d)
5.|-- ae101.fra-fr5-pb1-ptx.de. 3.0% 200 3038. 1028. 5.2 7291. 1726.8
be104.fra-fr5-pb4-nc5.de.eu (2001:41d0::2594)
6.|-- 2001:41d0:aaaa:100::13 0.0% 200 27.8 20.3 11.1 35.7 5.1
2001:41d0:aaaa:100::7
2001:41d0:aaaa:100::5
2001:41d0:aaaa:100::11
2001:41d0:aaaa:100::3
2001:41d0:aaaa:100::9
7.|-- 2001:41d0:aaaa:100::5 0.0% 200 22.4 20.4 11.4 42.6 5.8
2001:41d0:aaaa:100::3
2001:41d0:aaaa:100::11
2001:41d0:aaaa:100::7
2001:41d0:aaaa:100::9
2001:41d0:aaaa:100::13
8.|-- 2001:41d0:aaaa:100::10 43.0% 200 3055. 2100. 5.6 7306. 2502.3
2001:41d0:aaaa:100::12
2001:41d0:aaaa:100::8
2001:41d0:aaaa:100::6
2001:41d0:aaaa:100::4
2001:41d0:aaaa:100::2
9.|-- be101.sbg-g2-nc5.fr.eu (2 39.5% 200 7287. 2577. 8.1 7312. 2907.6
be101.sbg-g1-nc5.fr.eu (2001:41d0::444)
10.|-- be103.par-th2-sbb1-nc5.fr 50.5% 200 3045. 2146. 14.1 7311. 2464.3
be103.par-gsw-sbb1-nc5.fr.eu (2001:41d0::44d)
11.|-- be313.par-th2-pb2-nc5.fr. 53.5% 200 3031. 2643. 14.1 7285. 2830.0
be301.par-th2-pb1-nc5.fr.eu (2001:41d0::25cb)
be303.par-th2-pb2-nc5.fr.eu (2001:41d0::25cf)
be310.par-gsw-pb1-nc5.fr.eu (2001:41d0::25d7)
be311.par-th2-pb1-nc5.fr.eu (2001:41d0::25df)
be312.par-gsw-pb2-nc5.fr.eu (2001:41d0::25d9)
be302.par-gsw-pb2-nc5.fr.eu (2001:41d0::25c7)
be300.par-gsw-pb1-nc5.fr.eu (2001:41d0::25c5)
12.|-- gsw-dsl2-n93.fr.eu (2001: 0.0% 200 14.6 14.7 14.3 18.7 0.4
be100.th2-dsl1a-n93.fr.eu (2001:41d0::b72)
be101.th2-dsl1a-n93.fr.eu (2001:41d0::2430)
th2-dsl1-a1.fr.eu (2001:41d0::b76)
th2-dsl2-n93.fr.eu (2001:41d0::2432)
th2-dsl1-a1.fr.eu (2001:41d0::b74)
th2-dsl1a-n93.fr.eu (2001:41d0::2434)
be45.gsw-dsl1a-n93.fr.eu (2001:41d0::b70)
13.|-- 2001:41d0:fde0:80::125 9.0% 200 3036. 974.6 14.3 7313. 1570.2
2001:41d0:fde0:80::121
2001:41d0:fde0:80::123
14.|-- 2001:41d0:fc02:1f03::1 7.5% 200 7137. 1104. 31.8 7316. 1829.2
15.|-- 2001:41d0:fc02:1f03::1 5.5% 200 3050. 1075. 31.9 7275. 1773.6
16.|-- ??? 100.0 200 0.0 0.0 0.0 0.0 0.0
OVH -> ifconfig.me
lr@lr-desktop:~$ mtr -6 -b -s 1000 -r -c 200 ifconfig.me
Start: 2024-03-10T15:01:17+0100
HOST: lr-desktop Loss% Snt Last Avg Best Wrst StDev
1.|-- 2001:41d0:fc02:1f03::1 0.0% 200 9.6 2.0 0.8 15.9 2.5
2.|-- 2001:41d0:fde0::28 0.5% 200 19.2 23.4 18.9 55.4 6.1
3.|-- fd00::145:239:153:165 0.0% 200 28.8 21.3 8.4 33.8 3.1
be102.sbg-g2-nc5.fr.eu (2001:41d0::44c)
4.|-- be51.par-gsw-pb2-nc5.fr.e 39.5% 200 19.3 1403. 19.3 9774. 2959.2
2001:4860:0:1::23b9
2001:4860:0:1::1609
2001:41d0:fde0::28
fd00::145:239:153:165
google.as15169.fr.eu (2001:41d0::171)
2001:4860:0:1::586d
google.as15169.fr.eu (2001:41d0::269d)
5.|-- be312.par-th2-sbb1-nc5.fr 20.5% 200 34.4 656.9 3.8 8680. 1913.0
2001:4860:0:1::19d1
google.as15169.fr.eu (2001:41d0::171)
2001:4860:0:1::51fd
2001:41d0:fc02:1f03::1
fd00::145:239:153:165
be311.par-th2-pb1-nc5.fr.eu (2001:41d0::25df)
2001:41d0:fde0::28
6.|-- be310.par-gsw-pb1-nc5.fr. 49.5% 200 19.7 2475. 14.0 9891. 3135.4
2001:41d0:aaaa:100::2
2001:4860:0:1::586d
2001:41d0:fc02:1f03::1
2001:41d0:fde0::28
2001:4860:0:1::19d1
be315.par-th2-pb3-nc5.fr.eu (2001:41d0::25e3)
2001:4860:0:1::23bb
7.|-- google.as15169.fr.eu (200 0.0% 200 39.3 30.4 26.8 47.2 4.7
8.|-- 2001:4860:0:1::1a5b 0.0% 200 26.9 28.4 24.0 37.7 2.7
2001:41d0:fc02:1f03::1
9.|-- 2001:4860:0:1::7005 0.0% 200 36.3 29.6 27.1 42.0 3.7
10.|-- 2600:1901:0:bbc3:: 0.0% 200 36.5 29.5 26.7 43.7 3.6
OVH -> ifconfig.me TCP
lr@lr-desktop:~$ mtr -6 -b -T -s 1000 -r -c 200 ifconfig.me
Start: 2024-03-10T15:01:11+0100
HOST: lr-desktop Loss% Snt Last Avg Best Wrst StDev
1.|-- 2001:41d0:fc02:1f03::1 0.0% 200 5.8 2.7 1.2 21.6 3.4
2.|-- 2001:41d0:fde0::28 0.0% 200 19.5 23.9 19.3 71.2 9.4
3.|-- fd00::145:239:153:165 0.0% 200 21.3 21.4 19.7 44.5 3.2
4.|-- be51.par-gsw-pb2-nc5.fr.e 72.0% 200 3108. 3603. 19.7 9774. 3215.1
be51.par-gsw-pb1-nc5.fr.eu (2001:41d0::b75)
hetzner.as24940.de.eu (2001:41d0::581)
2001:41d0:aaaa:100::13
core24.fsn1.hetzner.com (2a01:4f8:0:3::4c1)
2001:41d0:aaaa:100::3
2a01:4f8:0:3::532
2001:41d0:aaaa:100::10
5.|-- google.as15169.fr.eu (200 1.5% 200 28.1 279.3 26.3 7228. 1061.1
2001:41d0:aaaa:100::11
2001:41d0:aaaa:100::5
2001:41d0:aaaa:100::7
2001:41d0:aaaa:100::9
2001:41d0:aaaa:100::3
2001:41d0:aaaa:100::13
2001:41d0:fc02:1f03::1
6.|-- 2001:41d0:aaaa:100::5 1.0% 200 34.3 336.8 26.0 7255. 1110.2
2001:4860:0:1::23bb
2001:41d0:aaaa:100::7
2001:4860:0:1::19d1
2001:41d0:aaaa:100::9
2001:4860:0:1::1a5b
2001:4860:0:1::23b9
2001:41d0:aaaa:100::11
2001:41d0:aaaa:100::3
7.|-- 2001:41d0:aaaa:100::10 6.0% 200 3152. 853.5 19.8 7246. 1974.4
2001:41d0:aaaa:100::12
2001:4860:0:1::4225
2001:41d0:aaaa:100::2
2001:4860:0:1::5873
2001:4860:0:1::4249
2001:4860:0:1::424b
2001:4860:0:1::51f9
8.|-- be304.par-gsw-pb3-nc5.fr. 3.5% 200 1026. 661.4 19.8 7264. 1600.5
2600:1901:0:bbc3::
be314.par-gsw-pb3-nc5.fr.eu (2001:41d0::25db)
be305.par-th2-pb3-nc5.fr.eu (2001:41d0::25d1)
be311.par-th2-pb1-nc5.fr.eu (2001:41d0::25df)
be315.par-th2-pb3-nc5.fr.eu (2001:41d0::25e3)
be300.par-gsw-pb1-nc5.fr.eu (2001:41d0::25c5)
be301.par-th2-pb1-nc5.fr.eu (2001:41d0::25cb)
9.|-- ams-1-a9.nl.eu (2001:41d0 0.0% 84 25.0 28.6 19.7 45.0 4.3
2600:1901:0:bbc3::
google.as15169.fr.eu (2001:41d0::832)
google.as15169.fr.eu (2001:41d0::269d)
google.as15169.fr.eu (2001:41d0::171)
10.|-- 2001:4860:0:1::19d1 0.0% 24 28.7 29.5 27.0 38.1 2.8
2001:4860:0:1::23b9
2600:1901:0:bbc3::
2001:4860:0:1::1609
2001:4860:0:1::23bb
2001:4860:0:1::160b
11.|-- 2600:1901:0:bbc3:: 0.0% 4 37.9 30.1 27.0 37.9 5.2
2001:4860:0:1::7003
-
N'est-on pas sensés en trouver qu'un seul ?
Non, c'est normal, y'en a deux pour la redondance
-
A quel niveau le MTU poserait problème selon toi ? En PPPoE il est bien à 1492 comme attendu.
Oui c'est la bonne MTU pour une ADSL dans les années 2000, pas pour une FTTH en 2024
-
Oui c'est la bonne MTU pour une ADSL dans les années 2000, pas pour une FTTH en 2024
Euh OK... Sauf que tous les gens en FTTH OVH semblent avoir ce MTU (et beaucoup s'en plaignent...).
Cependant après d'autres tests, le MTU semble bien être la source du problème, mais uniquement en IPv6. J'explique:
Hypothèse : Le MTU côté IPv6 qui est normalement déterminé par le protocole PMTUD. Or ici il ne le pourrait pas.
La cause la plus fréquente est un blocage de ICMPv6 côté opérateur sur les noeuds du réseau... Et à la vue des MTR il semble que ce soit bien ça.
OVH ne respecterait donc pas la RFC4638 permettant PMTUD.
Un ping6 -s avec différentes tailles de paquets permet de mettre cela en évidence :
lr@lr-desktop:~$ ping6 -s 1400 ds.lrob.net
PING ds.lrob.net(ds.lrob.net (2a01:4f8:171:28e8::2)) 1400 data bytes
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=1 ttl=52 time=32.6 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=2 ttl=52 time=32.3 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=3 ttl=52 time=32.1 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=4 ttl=52 time=32.3 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=5 ttl=52 time=32.2 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=6 ttl=52 time=32.1 ms
^C
--- ds.lrob.net ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5293ms
rtt min/avg/max/mdev = 32.053/32.278/32.632/0.183 ms
lr@lr-desktop:~$ ping6 -s 1500 ds.lrob.net
PING ds.lrob.net(ds.lrob.net (2a01:4f8:171:28e8::2)) 1500 data bytes
^C
--- ds.lrob.net ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5186ms
Le protocole QUIC utilisé par les plus grands fournisseurs de services en ligne outrepasse ce problème de MTU, ce qui explique que Amazon, Google et autres qui l'utilisent soient OK, mais pas les autres fournisseurs.
Une réponse trouvée sur un forum Mikrotik explique cela :
https://forum.mikrotik.com/viewtopic.php?t=195044
"You'll have to open a support ticket with your ISP so that they don't block ICMPv6 communication in order to allow PMTUD to work, this might be an easier task for them instead of adding support for RFC4638, and you'll want working ICMPv6 either way.
Regarding google, it uses QUIC which is a totally different beast than TCP, and they use a slightly lower, forced MTU, to avoid issues with broken ISPs :P so PMTUD doesn't kick in and "discovered" MTU remains equal to default interface MTU."
Je transmets l'info à OVH... En espérant une réaction quelconque.
-
Sinon si on oublie OVH, chez Milkywan on a des FTTH en MTU 1500, IPv4 + IPv6 natif, et pas de box fournie. En l'occurrence un RB5009 fait parfaitement le taf ;)
-
Sinon si on oublie OVH, chez Milkywan on a des FTTH en MTU 1500, IPv4 + IPv6 natif, et pas de box fournie. En l'occurrence un RB5009 fait parfaitement le taf ;)
Je viens de regarder :
Lien FTTH - Jusqu'à 1Gbit/s symétrique
Collecte via Orange
Engagement 12 mois
Frais d'accès au service 165€TTC
Partenaire Appliwave
60€TTC/mois
Un peu cher mais à côté du temps perdu avec OVH par rapport à ce que je gagne quand je bosse, j'y gagnerais large... C'est tentant.
Mais :
1) J'ai peut-être un autre plan opérateur alternatif qui se lancerait bientôt.
2) Tant qu'à changer, j'aimerais dépasser le gigabit si possible, donc je songe aussi à Orange Pro... Il me semble qu'ils sont aussi en MTU 1492 si j'en crois l'ami qui m'a partagé sa conf Mikrotik, mais avec un réseau bien configuré derrière, ça ne pose pas de souci chez eux, contrairement à OVH qui code avec le c*l. (Ref :https://youtu.be/aeePeVUW6-k )
-
Tu peux tenter le régler le MSS Clamping TCP à 1432 en IPv6 sur ton Mikrotik. C'est pas la solution la plus sexy mais ça marche chez moi :tm:
-
Tu peux tenter le régler le MSS Clamping TCP à 1432 en IPv6 sur ton Mikrotik. C'est pas la solution la plus sexy mais ça marche chez moi :tm:
OMFG ! Bon sang de bois tu es un génie ! Ça marche !! 8) ;D ;D ;D
/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=pppoe-ovh passthrough=yes protocol=tcp tcp-flags=syn
Pour info si je tente d'appliquer le clamping à tout le traffic :
[admin@home.lrob.net] /ipv6/firewall/mangle> add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=pppoe-ovh passthrough=yes
failure: tcp mss change works only on tcp syn packet
Ça ne corrige pas les ICMPv6 trop gros évidemment vu que ça ne s'applique qu'au SYN TCP, mais ça me suffit je pense... ! En attendant de trouver un FAI digne de ce nom...
Mais du coup tu es familier du problème @skid9000 ? C'est un truc connu chez OVH FTTH ou bien... ?
-
La réponse d'OVH égaux à eux-même...
Monsieur,
Suite aux échanges avec nos référents et à l'analyse de votre retour, je vous confirme que le comportement n'est ni dû à notre réseau, ni à nos équipements. Il apparaît que le protocole RFC4638 est bien pris en charge par notre infrastructure.
Nos modems en IPV6 ne rencontrent pas le comportement. Il apparaît en revanche que ce protocole peut être bloqué par l'utilisation d'un firewall et nécessite la mise en place d'autorisations vis-à-vis de cette dernière.
Ces éléments étant dépendants, donc, du matériel utilisé, nous n'apporterons pas de support sur cette demande. Je vous invite à vous rapprocher du forum https://community.ovh.com/ concernant l'utilisation d'un équipement personnel sur notre réseau.
N'ayant aucune autre réponse à vous fournir et ce retour ne me permettant pas la validation de la réclamation précédemment demandée, je vous invite à fermer ce ticket. En cas de réouverture de ce dernier sur ces sujets, je me verrais dans l'obligation de clore ce dernier.
Cordialement.
Ma réponse :
Firewall off, ou en désactivant toutes les règles de drop de paquets invalides, le problème a quand même lieu.
Cela se reproduit sur PFSense, OPNsense, Mikrotik RouterOS.
Et un autre utilisateur compétent m'a déjà remonté exactement le même souci (et le workaround de triturer MSS, ce qui n'est pas élégant et ne devrait pas avoir lieu d'être) sur le forum lafibre.info en moins de 24h.
Comme il est improbable que tous les équipements utilisateur posent problème, il semble évident que ce soit bien l'infra OVH qui pose problème.
Cela corrobore malheureusement la dégradation de ma confiance sur votre capacité de gestion des problèmes sur les autres services, où j'ai déjà pu observer par le passé que lors d'un dysfonctionnement de votre côté sur la définition d'un NS personnalisé pour un domaine d'une extension un peu plus rare (.cloud) ; votre support et ses administrateurs avaient alors pris plusieurs mois à se remettre en question et identifier le problème. Bien-sûr, vos services avaient pris le soin de rejeter la faute sur l'utilisateur tout ce temps durant, sans même vérifier par eux-même ce qu'il en était.
Sans explication technique concrète ni aucune remise en question de votre configuration, sans même chercher à comprendre ma configuration ou à améliorer votre compatibilité ou à vérifier avec des tests de votre côté ce qu'il en est réellement, et au final, sans implication concrète à fournir un service fonctionnel, je serai malheureusement contraint de mettre fin à notre collaboration sur FTTH ainsi que les autres services, ce pour assurer la pérennité de mon activité en ligne via des prestataires qui se montrent utiles face à l'adversité.
Cordialement
Bon allez, ils ont trop joué avec mes joyeuses, je n'ai plus ni de confiance ni de patience... Je cherche un autre FAI en attendant de voir s'ils se rattrappent. Mais j'en doute.
-
Perso ce qui me choque c'est surtout de ne pas faire de MTU 1500 alors que l'infra de collecte en est parfaitement capable puisqu'on le fait sur les mêmes collectes qu'eux (kosc/bytel/altitude)
-
Perso ce qui me choque c'est surtout de ne pas faire de MTU 1500 alors que l'infra de collecte en est parfaitement capable puisqu'on le fait sur les mêmes collectes qu'eux (kosc/bytel/altitude)
Y'a que ça qui te choque ? ;D
Tu as l'air de faire partie de MilkyWan (ou à minima de bien connaître), tu sais s'il est prévu de proposer plus de 1Gbit/s prochainement ? ;D
-
Hello,
Je vais peut être dire une connerie mais peut être qu'il collecte tout au même endroit, et qu'il peuvent pas mettre la MTU a 1500 sur tout leurs accès. je sais qu'ils ont aussi de la collecte SFR.
ou alors, leur modem fait du clamping et vu que tout fonctionne pour eux, tout va bien :) ils ont pas chercher à faire mieux. il faut savoir que dans le temps la MTU était a 1456 (de mémoire) sur les vieux accès DSL
-
Je vais peut être dire une connerie mais peut être qu'il collecte tout au même endroit, et qu'il peuvent pas mettre la MTU a 1500 sur tout leurs accès. je sais qu'ils ont aussi de la collecte SFR.
C'est super simple à faire en PPPoE d'adapter la MTU au profil.
-
ou alors, leur modem fait du clamping et vu que tout fonctionne pour eux, tout va bien :)
Clairement j'ai la même hypothèse, leur modem doit gérer le clamping pour palier le reste du réseau mal configuré. Mais vu la rapidité de leur réponse ils n'ont même pas cherché à vérifier. A voir s'ils répondent à ma réponse au ticket. Mais les connaissant ils vont encore jouer la carte du "zyxel marche donc t nul".
-
Réponse d'OVH qui clos le ticket et ne fera rien. Donc allez... Bye-bye OVH ! Ils ne méritent pas 1 centime de ma poche. Je vais tout virer de chez eux, y-compris mes noms de domaines (ça va me coûter mais tant pis) et même mon petit VPS pourri qui sert juste de Slave DNS.
(https://cloud.lrob.fr/s/n7XNW9YdYEETnBy/download/Screenshot%202024-03-11%20174052.png)
Je suis éligible au 8/2 Gbit/s (down/up). RDV tech 27 Mars (première date dispo). Ayant relancé l'auto entreprise il y a moins de 2 ans, je suis normalement éligible aux -30% pendant 1 an + l'offre nouveau client, ça me met à pas cher en mensuel au moins la première année. Pour le service fourni, c'est presque du vol pour Orange.
J'aurai donc sûrement la Livebox 7 qui a l'avantage de venir avec un port 10G en RJ45 (dommage, on aurait préféré SFP+ mais c'est déjà bien, et ça a terminé de me convaincre à franchir le pas, c'est la seule chose qu'il me manquait chez Orange). Ce qui signifie que je me passerai de mon Mikrotik car si je veux router du net en 10G je manque d'un port SFP+ sur mon Mikrotik, et sinon c'est mini 500€ pour en acquérir un, et là tout de suite j'ai mieux à dépenser, genre des vacances. 🤣
Pour profiter du 10G, j'ajoute une paire de ça https://www.amazon.fr/Mikrotik-RJ10-10000Mbit-Module-émetteur-Récepteur/dp/B078SLL1G3/ , à priori ils viennent en Rev 2 (notée /r2) pour relier la box 10G et mon Wifi 2.5G à mon switch 10G en direct. (Oui j'ai un wifi avec un RJ45 2.5Gbit/s et oui le débit dépasse le gigabit en wifi, un petit TP-Link XE75 Pro, ça fait le café notamment pour la VR).
Si tout est stable et que je peux avoir du net proche de 10G et faire mes redirections de ports, je serai déjà assez content, et je n'ai plus trop besoin du routeur custom. Tant pis pour la portabilité de mes réglage chez tous les opérateurs avec mon routeur custom.
Chez Orange FTTH Pro j'avais déjà eu une bonne expérience par le passé, que ce soit en entreprise ou à domicile, c'est le seul opérateur qui ne m'a jamais laissé tomber en FTTH avec un service exemplaire.
J'avais test le 10G avec Free et Free Pro : Quelle horreur, il y avait bien le 10G et un port SFP+ directement, par contre l'interco était nullissime, en particulier vers et depuis mon hébergeur Hetzner, où on avait bien du gigabit en burst (donc parfait pour mes visiteurs web), mais le débit continu tombait entre 50 et 250Mbit/s avec une moyenne proche de 100, donc pour les sauvegardes/restaurations de mes serveurs, ça posait de gros problèmes...
Bref, une nouvelle page se tournera bientôt. Vu le texte présent sur ce topic, j'ose espérer que si quelqu'un tombe sur ce topic avec le même problème que moi, il y trouvera ses réponses.
PS: Désolé @Hugues, j'ai vraiment hésité, MilkyWan a l'air vraiment au top en termes de philosophie du DIY et de l'open source, mais l'appel du débit supérieur à tarif inférieur était trop fort. Le port 10G de la Livebox 7 a achevé de me convaincre de prendre Orange Pro. Mais merci en tout cas, je suis très content d'avoir découvert le FAI et je n'hésiterai pas à le recommander !
-
Il y a toujours l'engagement de 12 mois avec OVH Telecom ?
Et le bloc IP /29 est payant ? ou inclus avec l'abonnement ?
-
Il y a toujours l'engagement de 12 mois avec OVH Telecom ?
Et le bloc IP /29 est payant ? ou inclus avec l'abonnement ?
Oui je confirme, ça se vérifie ici : https://www.ovhtelecom.fr/fibre/
Mais j'ai dépassé les 12 mois en Janvier donc yolo. Ça fait beaucoup trop long sans IPv6 mais bon... C'est bientôt du passé.
Le bloc IP /29 est bien-sûr payant. D'ailleurs quand j'avais tenté de demander le tarif au service commercial, personne n'avait pu me confirmer le prix, j'avais dû commander pour savoir. Un service commercial qui te donne pas un prix, t'as jamais vu ça. Mais si, chez OVH ça existe...
Je t'ai retrouvé le prix sur une facture grâce à la date du ticket : 8€ HT l'année passée.
Mais bon, pour moi le bloc était inutilisable avec une connexion sur deux qui arrivait à s'initier... Et le bloc additionnel était la raison pour laquelle j'avais pris OVH à la base, avec un serveur rackable OPNSense et une carte 4xSFP+ pour switcher mon réseau interne en 10G. Comme ça ne marchait pas et qu'OVH blâmait ma conf, j'ai pris le routeur Mikrotik, qui a donné strictement le même résultat. J'ai tenté plusieurs choses, dont principalement le NAT 1:1 qui est quand même ultra standard pour router un subnet vers du local, avec le même résultat. Confirmant donc le problème côté OVH qui n'en a rien eu à cirer et m'a laissé pour compte.
---------
Pour l'histoire, j'avais partagé le ticket support épique et invraisemblable entre OVH et moi pour connaître le tarif de l'option, où on m'a répondu robotiquement qu'il fallait contacter les "sales" via un formulaire sur https://www.ovhcloud.com/fr/contact-sales/ comme si je n'étais pas déjà client. Mais je ne suis pas sûr qu'il soit légal de partager un message envoyé dans un ticket, quand bien même les noms soient masqués et qu'il s'agisse d'une info utile à tous pour voir comment l'entreprise traite les gens... Alors j'ai effacé.
Je ne peux que témoigner du fait que le support a, dans ce cas précis, à peine lu les messages et été incapable de m'indiquer un simple un tarif... Alors quand le problème devient plus complexe, imagine... :-X
Fuyez pauvres fous !