MrItou (Auteur du topic), Posté le: Mar 30 Avr 2019, 11:52 Sujet du message: (V6) VMware sur CentOS7: problème avec l'IPv6
(V6) VMware sur CentOS7: problème avec l'IPv6188308172114
Bonjour,
Depuis hier je rencontre un problème sur des hosts vmware sous centos7 :
En IPv4 tout fonctionne :
[root@front:~]# ping www.Google.fr
PING www.Google.fr (216.58.213.131) 56(84) bytes of data.
64 bytes from par21s03-in-f3.1e100.net (216.58.213.131): icmp_seq=1 ttl=53 time=17.8 ms
CurtisNewton, Posté le: Mar 30 Avr 2019, 12:20 Sujet du message:
1346111885
Sur l'OS directement, ça marche en IPv6 ?
Free passe en IPv6 maintenant avec l'IPv4 encapsulé, l'inverse d'avant, tu as rebooté la box au cas où ça ne marcherait pas non plus sur l'OS directement ?
MrItou (Auteur du topic), Posté le: Mar 30 Avr 2019, 12:25 Sujet du message:
188308172114
Merci pour ton retour, depuis le host (Windows 7) tout fonctionne très bien :
C:\Users\user>ping www.Google.fr
Envoi d'une requête 'ping' sur www.Google.fr [2a00:1450:4007:809::2003] avec 32
octets de données :
Réponse de 2a00:1450:4007:809::2003 : temps=17 ms
Depuis une VM en centos 7 comme l'indique la trace du premier post ça ne fonctionne pas en IPv6
La box a été rebooté et les VM également.
D'ailleurs apparition depuis dans mon resolv.conf d'une nouvelle entrée en IPv6
MrItou (Auteur du topic), Posté le: Mar 30 Avr 2019, 13:20 Sujet du message:
188308172114
Je vois difficilement en exposant les symptômes comment ça ne pourrait venir de la Freebox mais je peux me tromper
Est-il possible d'obtenir le détail technique de la mise à jour qui a été poussé hier ?
Par ailleurs le phénomène que je n'explique pas c'est que sur un host sous Windows le traceroute et le ping en IPv6 fonctionne, pas sous Linux
Hier matin je joignais Google via IPv4 (réponse au curl de http://Google.fr en IPv4, c'est au moment ou j'ai commencé à recevoir des timeouts que j'ai constaté que ça répondait que en IPv6)
C'est donc bien selon tout cela la Freebox qui force à résoudre les DNS en IPv6
frederic76, Posté le: Mar 30 Avr 2019, 13:24 Sujet du message:
6727861148
Et dans le virtuel tu as un antivirus, pare feu...? Si non peux tu vérifier celui de la bécane générale. Si oui vois les accords. J'avais eu le cas une fois.
Tu peux aussi depuis une fenêtre invite de commande de faire ipconfig/renew
CurtisNewton, Posté le: Mar 30 Avr 2019, 13:36 Sujet du message:
1346111885
MrItou a écrit:
Je vois difficilement en exposant les symptômes comment ça ne pourrait venir de la Freebox mais je peux me tromper
Justement, je disais "Au moins, ça ne vient pas Free.", donc pas de la box.
MrItou a écrit:
Par ailleurs le phénomène que je n'explique pas c'est que sur un host sous Windows le traceroute et le ping en IPv6 fonctionne, pas sous Linux
Hier matin je joignais Google via IPv4 (réponse au curl de http://Google.fr en IPv4, c'est au moment ou j'ai commencé à recevoir des timeouts que j'ai constaté que ça répondait que en IPv6)
C'est donc bien selon tout cela la Freebox qui force à résoudre les DNS en IPv6
Là, je ne comprends plus. C'est en IPv4 ou IPv6 que ça coince ?
Dans le premier post, c'est en IPv4 que ça marche et pas en IPv6.
MrItou (Auteur du topic), Posté le: Mar 30 Avr 2019, 13:44 Sujet du message:
188308172114
La machine virtuelle est une centos 7 sans antivirus ni firewall. Sur le host, pas d'antivirus, le firewall de Windows 7 est configuré pour laisser tout le trafic sortir et d'ailleurs ça fonctionne sans problème.
Le renew de l'IP ne sera nécessaire dans le sens ou j'ai déjà une IP correct que ce soit v4 ou v6 aussi bien sur le host que sur les VM
Ce qu'il faut tenter de comprendre c'est pourquoi depuis la MAJ d'hier je ne résoud plus en IPv6 depuis un host virtualisé en Linux
Code:
[root@front:~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 100 0 0 ens33
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 ens33
[root@front:~]# IP a
1: lo: <LOOPBACK> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:31:83:f8 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.30/24 brd 192.168.0.255 scope global noprefixroute dynamic ens33
valid_lft 24062sec preferred_lft 24062sec
inet6 2a01:e34:ed14:97d0:29e0:596b:fd6:ae96/64 scope global noprefixroute dynamic
valid_lft 86199sec preferred_lft 86199sec
inet6 fe80::4378:2deb:724e:a9f3/64 scope link noprefixroute
valid_lft forever preferred_lft forever
[root@front:~]# ping www.Google.fr
PING www.Google.fr (216.58.213.131) 56(84) bytes of data.
64 bytes from par21s03-in-f3.1e100.net (216.58.213.131): icmp_seq=1 ttl=53 time=17.2 ms
^C
--- www.Google.fr ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 17.266/17.266/17.266/0.000 ms
[root@front:~]# ping6 www.Google.fr
PING www.Google.fr(par10s27-in-x03.1e100.net (2a00:1450:4007:809::2003)) 56 data bytes
^C
--- www.Google.fr ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms
[root@front:~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.0.254
nameserver fd0f:ee:b0::1
[root@front:~]# curl -v http://Google.fr
* About To connect() To Google.fr port 80 (#0)
* Trying 2a00:1450:4007:817::2003...
^C
[root@front:~]# curl -v http://free.fr
* About To connect() To free.fr port 80 (#0)
* Trying 2a01:e0c:1::1...
^C
[root@front:~]# nslookup -query=AAAA www.Google.fr
Server: 192.168.0.254
Address: 192.168.0.254#53
Non-authoritative answer:
www.Google.fr has AAAA address 2a00:1450:4007:809::2003
MrItou (Auteur du topic), Posté le: Mar 30 Avr 2019, 13:53 Sujet du message:
188308172114
Nouveau test et nouvelle précision :
En NAT : La résolution IPv6 étant déportée sur le host ça fonctionne
En Bridge : Avec une IP en IPv4 (normal car dans mon réseau interne) ça ne fonctionne pas
MrItou (Auteur du topic), Posté le: Mar 30 Avr 2019, 14:36 Sujet du message:
188308172114
Bon, je n'arrive pas à comprendre pourquoi j'ai ce comportement :
Code:
[root@front:~]# ping www.Google.fr
PING www.Google.fr (172.217.22.131) 56(84) bytes of data.
64 bytes from par21s12-in-f3.1e100.net (172.217.22.131): icmp_seq=1 ttl=53 time=17.8 ms
64 bytes from par21s12-in-f3.1e100.net (172.217.22.131): icmp_seq=2 ttl=53 time=17.3 ms
64 bytes from par21s12-in-f3.1e100.net (172.217.22.131): icmp_seq=3 ttl=53 time=17.5 ms
^C
--- www.Google.fr ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 17.362/17.596/17.863/0.256 ms
[root@front:~]# curl www.Google.fr -v
* About To connect() To www.Google.fr port 80 (#0)
* Trying 2a00:1450:4007:810::2003...
^C
[root@front:~]# telnet www.Google.fr 80
Trying 2a00:1450:4007:805::2003...
^C
Quoiqu'il en soit (je suis pas fan mais bon pas le choix...) j'ai désactivé l'IPv6 sur mes serveurs via :
Code:
[root@front:~]# vi /etc/sysctl.conf (ajouter la ligne : net.IPv6.conf.all.disable_ipv6 = 1)
[root@front:~]# sysctl -p
C'est moche mais je n'ai pour le moment pas d'autre solution..
Merci pour votre aide, le topic peut être en [résolu] laissez le ouvert si jamais quelqu'un peut apporter des explications sur le comportement je suis preneur
Vous ne pouvez pas poster de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas voter dans les sondages de ce forum
FAQ
Rechercher
Liste des Membres
Groupes d'utilisateurs
S'enregistrer
Est-ce que tu peux tester depuis un partage mobile ?