Outils pour utilisateurs
Nota à posteriori :
j'ai beaucoup erré ci-après avec le paramétrage de la connexion car :
- le réseau c'est pas simple, ce n'est pas mon métier et je ne m'y suis jamais vraiment intéressé,
- j'ai confondu serveurs DHCP (ceux qui traduisent vos adresses IP numériques en adresses de noms de domaines) et connexion DHCP. J'ai “bâti” mon petit réseau en IP statique à l'origine parce que je voulais pouvoir paramétrer simplement mon firewall - guardedog à l'époque, avec des IP fixes, et depuis je l'ai gardé ainsi - ça fonctionne et ça me convient. Or ici j'aurais donc dû choisir une connexion manuelle sous les outils réseaux avec mes IP statiques et non pas du DHCP :)
- J'étais persuadé que le couple resolvconf / network-manager prenait en charge la recherche de serveurs DNS puis la sélection du meilleur candidat. Mais visiblement ce n'est pas le cas, il faut saisir soi-même la liste des serveurs DNS, et network-manager se charge de retenir le moins encombré. Donc je suis passé à côté des champs sans rien y saisir (et rien y comprendre :) pendant un bon moment.
- La connexion IPv6 fonctionne un peu différemment de l'IPv4 (notamment pour l'IP forwarding) et il manque encore d'outils pour l'IP masquerading en IPv6 (guidedog ne supporte que l'IPv4 pour l'instant).
- Le résultat final est résumé ici : Le Réseau ethernet (filaire)
J'ouvre un nouveau paragraphe, car je constate un souci de réseau sur le PC de rédaction du Bottin (il est relié au PC “Internet”, celui-ci étant relié à ma box) via un simple câble Ethernet, le tout en IP statique : j'ai du réseau (un “# ping 192.168.2.1” - l'adresse du PC “Internet”, abouti bien), mais il n'arrive plus à se connecter aux sites internet. Ça doit venir du côté de la configuration DNS (/etc/resolv.conf).
Je saurais le résoudre rapidement en désinstallant le paquet resolvconf puis en écrasant le lien symbolique /etc/resolv.conf par un fichier contenant 2 lignes successives correspondant aux adresses DNS de Free (217.27.40.240 et 217.27.40.241, c'est ce que je faisais avant), mais c'est pas ça que je veux.
J'ai envie que ce soit mon système qui retienne automatiquement les adresses des serveurs DNS les moins chargés (les temps d'accès n'ont rien à voir, à la longue c'est pénible d'attendre 2 à 3 secondes pour une connexion à un site). Et pour ça, il me faut un couple resolvconf / network-manager fonctionnel.
/etc/resolv.conf est une succession de liens symboliques jusqu'à /etc/resolvconf/run/resolv.conf qui est vide (sauf les commentaires habituels “DO NOT EDIT THIS FILE BY HAND …”, …).
Du coup je relance la commande :
# dpkg-reconfigure resolvconf
Et redémarre (puisqu'il me le demande dans ses messages). Ca ne fonctionne toujours pas. Donc pour l'instant, j'efface ce fichier vide et je récupère mon fichier précédent manuel dans /etc/resolv.conf/resolv.conf.d/original que je met dans /etc/resolvconf/run/ et renomme resolv.conf Je réactualise un onglet sous Firefox : ça marche, j'ai à nouveau l'accès internet :)
Sauf qu'au démarrage suivant il a écrasé le fichier (j'aurais dû m'en douter, c'est de ma faute) et m'en a remis un autre vierge, en attendant de résoudre ce problème de DNS non trouvé par resolvconf, je relance la configuration :
# dpkg-reconfigure resolvconf Faut-il préparer /etc/resolv.conf pour les mises à jour dynamiques ? Non (provisoirement)
Puis je remet mon fichier précédent et redémarre. Et … ça ne fonctionne toujours pas : il me l'a encore écrasé.
Autre informations intéressantes en rapport : dans l'historique des mises à jour de Synaptic je vois qu'avant mon souci de plantage de Grub (outre grub et ses amis) j'avais mis à jour iproute2 en version 5.2.0-1 (vs 4.20.0-2), installé resolvconf (et désinstallé openresolv par le jeu des dépendances), et il me propose à présent de mettre à jour network-manager en version 1.18.0-3 (vs 1.14.6-2).
Lors de la mise en place du Wi-Fi j'avais aussi beaucoup expérimenté du côté de network-manager (pourtant de mémoire, j'avais vérifié que tout fonctionnait - mais peut-être pas après un démarrage, je vais relire mes notes : à priori non, je n'ai pas eut le temps puisque Grub m'avait tout planté dans l'intervalle).
Comme j'ai beaucoup aimé le trio nm-tray / network-manager / network-manager-gnome (paquets éponymes, voir ci-dessus au paragraphe Wi-Fi), j'ai très envie de jouer avec.
Je passe donc une fois de plus par le Centre de contrôle de MATE, puis dans la section Internet et réseau, je clique sur Configuration réseau avancée. Là je clique sur “+” pour ajouter une connexion, je sélectionne “Ethernet”, puis je clique sur le bouton “Créer…”.
Onglet Ethernet :
- Périphérique : enp24s0 (via le déroulant)
- Adresse MAC clonée : (vide)
- MTU : (vide)
- Service : automatique (par défaut)
- Wake on LAN : Par défaut (par défaut)
- Mot de passe Wake on LAN : (vide)
- Négociation de lien : Automatique
- Vitesse : (désactivé)
- Duplex : (désactivé)
Onglet Général :
- ☑ Se connecter automatiquement avec priorité 0 (par défaut)
- ☑ Tous les utilisateurs peuvent se connecter à ce réseau (par défaut)
- ☐ Se connecter automatiquement au VPN (par défaut)
- Connexions limitées : Automatique (par défaut)
Onglet Sécurité 802.1X
- ☐ Utiliser la sécurité 802.1X pour cette connexion (par défaut)
Onglet DCB
- ☐ Utiliser Data Center Bridging (DCB) pour cette connexion (par défaut)
Onglet Proxy
- Méthode : Aucune
Onglet Paramètres IPv4
- Méthode : Partagé avec d'autres ordinateurs
Adresse statique supplémentaire : (aucune définie, par défaut)- Adresse (optionnel) : 192.168.2.2 (adresse), 24 (Masque de réseau), 192.168.2.1 (Passerelle)
- Serveurs DNS supplémentaires : vide (par défaut)
- Domaines de recherche supplémentaires : vide (par défaut)
- ID de client DHCP : vide (par défaut)
- ☐ Requiert un adressage IPv4 pour que cette connexion fonctionne (par défaut)
- Bouton “Routes…” : (désactivé)
Onglet Paramètres IPv6
- (non renseigné)
Je clique sur le bouton “Enregistrer”
- Je redémarre le PC pour être sûr que mes modifications puissent être prises en compte.
- J'essaie d'activer l'interface sous nm-tray : ça ne marche pas :(
- Je vois pourtant mon interface enp24s0 sous Gkrellm
Je vais rechercher de l'aide sur le web. Des documentations : Krisna (How to Setup network on centos 7) et AskUBUBTU (network manager says “device not managed”)
Je teste la commande nmcli (paquet network-manager, permettant de visualiser les connexions) :
Lorsque connecté en Wi-Fi : $ nmcli connection show NAME UUID TYPE DEVICE Wi-Fi via la Freebox 8745f(...) wifi wlo1 (la ligne est affichée en vert lorsque connecté) Connexion Ethernet 1 b03f5(...) ethernet -- (la ligne est affichée en gris) Lorsque déconnecté du Wi-Fi : $ nmcli connection show NAME UUID TYPE DEVICE Connexion Ethernet 1 b03f5(...) ethernet -- (la ligne est affichée en gris) Wi-Fi via la Freebox 8745f(...) wifi -- (la ligne est affichée en blanc lorsque déconnecté) (la ligne est affiché en marron lorsqu'en cours de connexion)
Autre paramétrage :
Lorsque connecté en Wi-Fi : $ nmcli d DEVICE TYPE STATE CONNECTION wlo1 wi-Fi connecté Wi-Fi via la Freebox (la ligne est affichée en vert lorsque connecté) enp24s0 ethernet non-géré -- (la ligne est affichée en gris) lo loopback non-géré -- (la ligne est affichée en gris) Lorsque déconnecté du Wi-Fi : $ nmcli d DEVICE TYPE STATE CONNECTION wlo1 wi-Fi indisponible -- (la ligne est affichée en gris) enp24s0 ethernet non-géré -- (la ligne est affichée en gris) lo loopback non-géré -- (la ligne est affichée en gris)
J'essaie ensuite (toujours grâce à la même documentation), la commande nmtui (permet le paramétrage et l'activation d'une interface), et je me retrouve avec l'interface en mode texte disponible sous nm-tray pour le paramétrage, donc je connais :
NetworkManager TUI
Modifier une connexion
Activer une connexion
Définir le nom d'hôte du système
Quitter
<Valider>
Je teste “Activer une connexion”, je choisi “Connexion Ethernet 1” définie précédemment et valide, un message s'affiche : “Impossible d'activer la connexion : 'Connection 'Connexion Ethernet 1' is not available on device enp24s0 because device is strictly unmanaged”
Ok, ça se précise. C'est au moins une indication. Je reprend la doc de Krisna ci-dessus.
Je paramètre mon réseau comme indiqué :
- Je sélectionne mon interface : enp24s0
- Pour IPv4 et IPv6 je change pour “Automatic”
Je tente comme précisé un redémarrage du réseau par
# systemctl restart network Failed to restart network.service: Unit network.service not found.
Visiblement ça ne fonctionne pas donc je reboot. Ca ne marche pas :(
Ok, ça se précise (bis). Grâce à cette autre très bonne documentation : blackMORE Ops (How to fix Wired Network interface “Device not managed” error in Debian or Kali Linux?)
Cela se produit lorsque l'on a défini à la fois une configuration de l'interface dans /etc/network/interfaces (exact, voir Réseau ci-avant, avec néanmoins la ligne “dns-nameservers” commentée) et un paramétrage comme suit dans /etc/NetworkManager/NetworkManager.conf :
[main] plugins=ifupdown,keyfile [ifupdown] managed=false
Il faut changer ce paramètre “managed=false” par “managed=true”
Puis on redémarre le réseau par :
# service network-manager restart
(et non pas “# systemctl restart network” comme indiqué ci-dessus)
Ca ne fonctionne pas encore mais il y a du mieux : l'icône de connexion de network-manager-gnome dans la barre des tâches devient actif, et quand je clique dessus je vois un menu qui ressemble à çà :
Réseau Ethernet déconnecté .......Disponible...... Connexion Ethernet1 Réseau Wi-Fi Le réseau Wi-Fi est désactivé ....................... Connexions VPN >
(j'ai désactivé la connexion Wi-Fi pour mes tests)
Je n'ai toujours pas de connexion DNS mais je sent que l'on approche du but.
Avant l'activation (“managed=true”) de NetworkManager, j'avais une interface comme suit :
$ ifconfig -a
enp24s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::2d8(...)
(...)
(...)
et à présent j'ai :
$ ifconfig -a
enp24s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::(...)
ether 00:d8:61(...)
(...)
(...)
Rappel : je passe par le PC “Internet”, ma passerelle en 192.168.2.1, et l'adresse que j'ai donné à mon interface est la 192.168.2.2
Je pense qu'il faut juste que je rétablisse la passerelle dans mes paramétrages.
Je retente via le Centre de contrôle de MATE. Dans l'onglet “Paramètres IPv4”, je clique sur le bouton “Routes” et lui ajoute : 192.168.2.2 (adresse), 24 (Masque de réseau), 192.168.2.1 (Passerelle), 192.168.2.1 (Passerelle), et rien pour Métrique (je ne sais pas ce que c'est). et j'efface ce qui est mis sur “Adresse statique supplémentaire.
je relance le réseau (et même reboot ensuite pour être sûr) : ça ne marche pas.
Pourtant :
$ ifconfig -a
enp24s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::2d8(...)
(...)
(...)
$ nmcli d
DEVICE TYPE STATE CONNECTION
enp24s0 ethernet connecté enp24s0 (la ligne est affichée en vert)
wlo1 wi-Fi indisponible -- (la ligne est affichée en gris)
lo loopback non-géré -- (la ligne est affichée en gris)
Et de plus il m'a créé un nouveau fichier de configuration accessible sous network-manager-gnome portant le nom enp24s0.
Et lorsque je clique sur l'icône de connexion de network-manager-gnome dans la barre des tâches je vois çà :
Réseau Ethernet enp24s0 Se déconnecter .......Disponible...... Connexion Ethernet1 Réseau Wi-Fi Le réseau Wi-Fi est désactivé ....................... Connexions VPN >
Sous ce nouveau fichier de connexion enp24s0 j'ai : Onglet Ethernet :
- Périphérique : enp24s0 (via le déroulant)
- Adresse MAC clonée : (vide)
- MTU : automatique
- Wake on LAN : ☑ Par défaut (par défaut)
- Mot de passe Wake on LAN : (vide)
- Négociation de lien : Ignorer
- Vitesse : (désactivé)
- Duplex : (désactivé)
Onglet Général :
- ☐ Se connecter automatiquement avec priorité 0 (par défaut)
- ☑ Tous les utilisateurs peuvent se connecter à ce réseau (par défaut)
- ☐ Se connecter automatiquement au VPN (par défaut)
- Connexions limitées : Automatique (par défaut)
Onglet Sécurité 802.1X
- ☐ Utiliser la sécurité 802.1X pour cette connexion (par défaut)
Onglet DCB
- ☐ Utiliser Data Center Bridging (DCB) pour cette connexion (par défaut)
Onglet Proxy
- Méthode : Aucune
Onglet Paramètres IPv4
- Méthode : Manuel
- Adresses : 192.168.2.2 (adresse), 24 (Masque de réseau), 192.168.2.1 (Passerelle)
- Serveurs DNS supplémentaires : vide (par défaut)
- Domaines de recherche supplémentaires : vide (par défaut)
- ID de client DHCP : désactivé (par défaut)
- ☐ Requiert un adressage IPv4 pour que cette connexion fonctionne (par défaut)
- Bouton “Routes…” : (vide)
Onglet Paramètres IPv6
- Méthode : Lien-local uniquement
- Serveurs DNS : désactivé (par défaut)
- Domaines de recherche : désactivé (par défaut)
- Extension de confidentialité IPv6 : désactivé (par défaut)
- Mode de génération d'adresse IPv6 : Confidentialité stable (par défaut)
* ☐ Requiert un adressage IPv6 pour que cette connexion fonctionne (par défaut)
- Bouton “Routes…” : (désactivé)
J'ai modifié mon fichier de configuration personnalisé (qui s'appelle pour l'instant “Connexion Ethernet (enp24s0)” en recopiant les données de celui créé automatiquement (enp24s0) afin d'effectuer des tests dessus.
J'arrive à le connecter via nm-trai (dans “Information de débogage” puis dans la zone “Toutes les informations” je déplie “root” et à “connexion(s)” je double-clique sur “Connexion Ethernet (enp24s0)”.
Sous nm-tray (dans “Informations de connexion”) je vois ma connexion avec ses paramétrages, notamment :
Général Interface: Ethernet (enp24s0) Adresse matériel: 00:D8:xx:xx:xx:xx pilote: igb Vitesse: 1000000 Kb/s IPv4 Adresse IP: 192.168.2.2 Masque de sous-réseau: 255.255.255.0 Route par défaut: 192.168.2.1 IPv6 Adresse IP: fe80::91(...) Masque de sous-réseau: ffff:ffff:ffff:ffff:
D'après mes lectures, dans le doute, j'ai commenté toutes les entrées de mon fichier /etc/network/interfaces, ne laissant que :
auto lo iface lo inet loopback
et ai relancé le réseau :
# service network-manager restart
$ nmcli d
DEVICE TYPE STATE CONNECTION
enp24s0 ethernet connecté Connexion Ethernet 1 (la ligne est affichée en vert)
wlo1 wi-Fi indisponible -- (la ligne est affichée en gris)
lo loopback non-géré -- (la ligne est affichée en gris)
mais :
$ ping 198.168.2.1
PING 198.168.2.1 (192.168.2.1) 56(84) bytes of data
(Ctrl C)
--- 198.168.2.1 ping statistics ---
94 packets transmitted, 0 received, 100% packet loss, time 94984ms
$ ifconfig -a
enp24s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::2d8(...)
(...)
(...)
$ route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
Default _gateway 0.0.0.0 UG 100 0 0 enp24s0
localnet 0.0.0.0 255.255.255.0 U 100 0 0 enp24s0
Je n'ai pas de ping :(
Et elle m'a l'air un peu étrange cette table de routage.
Avec l'option -n :
$ route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 enp24s0 localnet 0.0.0.0 255.255.255.0 U 100 0 0 enp24s0
Comme je sèche un peu là, je vais remettre en route ma méthode manuelle pour voir la différence.
Là ça marche (mais c'est pas la méthode finale que je souhaite retenir), çà me donne :
$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.123 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.141 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.166 ms
(Ctrl C)
--- 192.168.2.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2043ms
$ route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
Default _gateway 0.0.0.0 UG 0 0 0 enp24s0
localnet 0.0.0.0 255.255.255.0 U 0 0 0 enp24s0
$ route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 enp24s0
localnet 0.0.0.0 255.255.255.0 U 0 0 0 enp24s0
$ ifconfig -a
enp24s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::2d8(...)
(...)
- Punaise, je me rend compte (par un rappel via la flèche sous ma console) de ma bêtise : tout à l'heure je faisais un ping 198.168.2.1 au lieu de 192.168.2.1 arrghh
- Je vois une seule différence : le Metric à régler est de 0 (vs 100)
Effectivement tout à l'heure je me demandais ce que c'était ce “Métrique” lors du paramétrage via le bouton “Routes”, donc je reprend mon réglage de network-manager-gnome dans le Centre de contrôle : Onglet “Paramètres IPv4 :
- Méthode : Automatique (DHCP)
- Adresse statique supplémentaire : (j'efface tout)
- Serveurs DNS supplémentaires : vide (par défaut)
- Domaines de recherche supplémentaires : vide (par défaut)
- ID de client DHCP : vide (par défaut)
- ☐ Requiert un adressage IPv4 pour que cette connexion fonctionne (par défaut)
- Bouton “Routes…” : 192.168.2.2 (adresse), 24 (Masque de réseau), 192.168.2.1 (Passerelle), 0 (Métrique : visiblement ça doit avoir son importance)
J'enlève ma connexion statique provisoire (je recommente mes entrées dans /etc/network/interfaces et remet managed=true dans /etc/NetworkManager/NetworkManager.conf) et redémarre mon PC.
Suspens :)
Ca marche pas. Mais mon p'tit doigt me dit que je ne suis pas loin :)
Via nm-tray (“informations de connexion”) je vois que je n'ai plus d'IPv4, je n'ai que de l'IPv6, et le ping m'affiche :
$ ping 192.168.2.1 ping: connect: Le réseau n'est pas accessible $ nmcli d DEVICE TYPE STATE CONNECTION enp24s0 ethernet connecté enp24s0 (la ligne est affichée en vert) wlo1 wi-Fi indisponible -- (la ligne est affichée en gris) lo loopback non-géré -- (la ligne est affichée en gris)
je reprend mon réglage de network-manager-gnome dans le Centre de contrôle : le seul moyen d'obtenir une adresse IPv4 est de renseigner la zone “Adresse statique supplémentaire” : mais il n'y a pas de zone de saisie pour le “Metric”, on ne peux renseigner ce dernier qu'en cliquant sur le bouton “Routes…”. Par ailleurs si l'on sélectionne “Lien-local uniquement” ou “Partagé avec d'autres ordinateurs” ça déselectionne le bouton “Routes…”, donc ça réduit un peu le champ des possibles.
J'ai retenu : Onglet “Paramètres IPv4 :
- Méthode : Automatique (DHCP)
- Adresse statique supplémentaire : 192.168.2.2 (adresse), 255.255.255.0 (Masque de réseau), 192.168.2.1 (Passerelle) (nécessaire pour obtenir de l'IPv4)
- Serveurs DNS supplémentaires : vide (par défaut)
- Domaines de recherche supplémentaires : vide (par défaut)
- ID de client DHCP : vide (par défaut)
- ☐ Requiert un adressage IPv4 pour que cette connexion fonctionne (par défaut)
- Bouton “Routes…” : 192.168.2.2 (adresse), 24 (Masque de réseau), 192.168.2.1 (Passerelle), 0 (Métrique)
Je relance le réseau.
Via nm-tray (“informations de connexion”) je vois que j'ai à nouveau de l'IPv4.
$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.131 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.132 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.153 ms
(Ctrl C)
--- 192.168.2.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2025ms
rtt min/avg/max/mdev = 0.131/0.138/0.153/0.010 ms
$ route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
Default _gateway 0.0.0.0 UG 100 0 0 enp24s0
localnet _gateway 255.255.255.0 UG 0 0 0 enp24s0
localnet 0.0.0.0 255.255.255.0 U 100 0 0 enp24s0
$ route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 enp24s0
192.168.2.0 192.168.2.1 255.255.255.0 UG 0 0 0 enp24s0
192.168.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp24s0
$ ifconfig -a
enp24s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::2d8(...)
(...)
Et toujours pas d'accès aux serveurs DNS :(
Punaise, ça devais être une formalité ce truc :))
Le routage est foireux et je ne sais pas comment m'en sortir avec cette interface pour n'avoir qu'une ligne d'adresse avec un métrique de 0 et de l'IPv4.
Je vais tenter la mise à jour (en Wi-Fi) de network-manager (j'ai vu qu'il y avait une nouvelle version 1.18.0-3 vs 1.14.6-2) et network-manager-gnome (v.1.8.22-2 vs 1.8.20-11).
Ensuite je redémarre le PC.
C'est pas mieux.
Dans le bouton “Routes” j'ai coché en plus :
- ☑ Ignore automatically obtained routes
- ☑ Use this connection only for resources on its network
Ce qui me donne :
$ route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.2.0 192.168.2.1 255.255.255.0 UG 0 0 0 enp24s0
192.168.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp24s0
$ ifconfig -a
enp24s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::2d8(...)
(...)
Rappel, il faut que j'obtienne :
$ route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 enp24s0 localnet 0.0.0.0 255.255.255.0 U 0 0 0 enp24s0
Au mieux je n'obtiens (en supprimant mon paramétrage via le bouton “Routes…” et en choissant “Automatic (DHCP) adress only” avec son adresse sans Metric):
$ route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 enp24s0 192.168.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp24s0
et donc pas de connexion :(
Avec la commande ifmetric (paquet éponyme à installer) je m'en rapproche, mais toujours pas d'internet :
# ifmetric enp24s0 0 $ route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 enp24s0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 enp24s0 $ route Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface default _gateway 0.0.0.0 UG 0 0 0 enp24s0 localnet 0.0.0.0 255.255.255.0 U 0 0 0 enp24s0 $ ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1025ms 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.099 ms (Ctrl C) --- 192.168.2.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1025ms rtt min/avg/max/mdev = 0.099/0.113/0.128/0.014 ms
Alors là je ne comprend pas pourquoi je n'ai pas de connexion DNS ???
Le 15/07/2019 : (aka la nuit a une fois de plus porté conseil :)
J'ai ensuite changé de méthode de connexion (onglet “IPv4 Settings” sous network-manager-gnome) car après réflexion, je suis à peu près certain que je ne dois pas pas me connecter en DHCP (je suis en IP statique), mais en IP statique, donc j'ai retenu : Method : “Manual”, toujours en précisant le chemin : 192.168.2.2/24 gateway : 192.168.2.1 sans rien préciser via le bouton “Routes…”. Mais ça ne marche pas non plus, même après un redémarrage.
J'ai trouvé une solution fonctionnelle, mais ça me semble étonnant que çà soit çà : Toujours avec Method “Manual”, j'ajoute les serveur DNS de Free sur le champ “DNS Servers” du même onglet, ce qui donne : Onglet “Paramètres IPv4 :
- Méthode : Manual
- Adresse statique supplémentaire : 192.168.2.2 (adresse), 24 (Masque de réseau), 192.168.2.1 (Passerelle)
- Serveurs DNS supplémentaires : 217.27.40.240, 217.27.40.241
- Domaines de recherche supplémentaires : vide (par défaut)
- ID de client DHCP : vide (par défaut)
- ☐ Requiert un adressage IPv4 pour que cette connexion fonctionne (par défaut)
- Bouton “Routes…” : vide (par défaut)
Onglet Paramètres IPv6
- Méthode : ignore
- (le reste est désactivé)
Ce qui me donne :
$ route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 enp24s0 192.168.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp24s0 $ route Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface default _gateway 0.0.0.0 UG 100 0 0 enp24s0 localnet 0.0.0.0 255.255.255.0 U 100 0 0 enp24s0
Donc avec un Metric de 100, ça ne le gêne pas du tout :))
Ce qui me gêne c'est que je pensais qu'il allait trouver ses serveurs DNS tout seul.
J'ai testé avec les DNS de Google (8.8.8.8) : ça fonctionne bien aussi.
Ce qui me donne sous nm-tray (dans “Informations de connexion”) :
Général Interface: Ethernet (enp24s0) Adresse matériel: 00:D8:xx:xx:xx:xx pilote: igb Vitesse: 1000000 Kb/s IPv4 Adresse IP: 192.168.2.2 Masque de sous-réseau: 255.255.255.0 Route par défaut: 192.168.2.1 DNS(1): 8.8.8.8
Et si je modifie encore les DNS comme suit :
Onglet “Paramètres IPv4 :
- Serveurs DNS supplémentaires : 217.27.40.240, 217.27.40.241, 8.8.8.8
nm-tray (dans “Informations de connexion”) m'affiche :
Général Interface: Ethernet (enp24s0) Adresse matériel: 00:D8:xx:xx:xx:xx pilote: igb Vitesse: 1000000 Kb/s IPv4 Adresse IP: 192.168.2.2 Masque de sous-réseau: 255.255.255.0 Route par défaut: 192.168.2.1 DNS(1): 217.27.40.240 DNS(2): 217.27.40.241 DNS(3): 8.8.8.8
Une excellente doc sur les serveurs DNS gratuits alternatifs disponibles : Lifewire (Free and Public DNS Servers)
IPv6
Bon maintenant que l'IPv4 fonctionne bien, j'aimerai bien arriver à me connecter aussi en IPv6, pour le futur probable.
Toujours sous l'interface de network-manager-gnome (dans le Centre de configuration de MATE), j'effectue les réglages ci-après.
Nota : après la mise à jour du paquet network-manager-gnome en version 1.8.22, les libellés sont passés en Anglais (pas gênant).
Pour mes tests, je suis contraint provisoirement d'enlever mes paramètres IPv4 (Method : Disabled) pour être sûr que lorsque çà fonctionne, c'est bien via le paramétrage IPv6.
Pour trouver les adresses IPv6 de mon PC et de ma passerelle, j'ai lançé la commande “$ ifconfig -a” sur chacun d'entre eux :
Sur mon vieux PC “Internet” :
$ ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::221:85ff:xxxx:xxxx prefixlen 64 scopeid 0x20<link>
ether 00:21:85:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 43424 bytes 3678694 (3.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 65304 bytes 84809911 (80.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
(...)
Je renseigne l'onglet IPv6 Settings de la même manière que celui d'IPv4 (aux adresses près, qui sont ici en IPv6) :
- Method : Manual
- Address : fe80::2d8:61ff:xxxx:xxxx:xxx (celle du PC du Bottin, obtenue par # ifconfig -a)
- Prefix : 64 (=le netmask d'un réseau local en IPv6)
- Gateway : fe80::221:85ff:xxxx:xxxx (adresse IPv6 du “PC Internet, obtenue de la même manière sur le “PC Internet”)
- DNS servers : 2620:119:35::35, 2620:119:53::53, 2a01:e0c:1:1599::22, 2a01:e0c:1:1599::23
Et je valide.
Mon fournisseur d'accès (Free) propose des serveurs DNS en IPv6, j'avais activé l'IPv6 sur ma box et j'ai testé ma connectivité (ici : test-ipv6.com : çà fonctionne.
D'après ce même site, j'utilise “un tunnel 6RD géré pour transporter IPv6 au-dessus d'IPv4” (ce qui est moins performant que de l'IPV6 natif, selon mes lectures, et effectivement selon ce même site, les résultats des temps d'accès en IPv4 sont 30% meilleurs qu'en IPv6).
Les 2 premiers serveurs DNS retenus pour mes tests correspondent à ceux d'OpenDNS.
Depuis nm-tray j'active/désactive le réseau pour relancer le réseau.
Je n'ai pas de réseau.
J'effectue quelques tests :
Tout d'abord l'adresse de la passerelle :
ping6 fe80::221:85ff:xxxx:xxxx PING fe80::221:85ff:xxxx:xxxx (fe80::221:85ff:xxxx:xxxx) 56 data bytes 64 bytes from fe80::221:85ff:xxxx:xxxx: icmp_seq=1 ttl=64 time=0.087 ms 64 bytes from fe80::221:85ff:xxxx:xxxx: icmp_seq=2 ttl=64 time=0.187 ms (...) (Ctrl C) --- fe80::221:85ff:xxxx:xxxx ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3063ms rtt min/avg/max/mdev = 0.073/0.126/0.187/0.047 ms
Donc les paquets sont bien envoyés et reçus. Par contre, ce que je ne comprend pas, c'est que l'inverse ne fonctionne pas, que ce soit en IPv4 ($ ping 192.168.2.2) ou en IPv6 ($ ping6 fe80::2d8:61ff:xxxx:xxxx:xxx). Mais je vois bien la diode réseau clignoter sur le PC du Bottin ainsi que les ping arriver sur gkrellm sur l'interface eno24s0.
Je n'ai pourtant pas de firewall sur le PC du Bottin. Enfin je ne crois pas. Peut-être que si finalement : nftables est installé (remplace iptables d'après mes lectures).
Je le désinstalle et redémarre pour voir. De toute façon je suis infoutu de l'utiliser, trop compliqué / arride pour moi (je regrette feu guarddog disparu des dépôts).
Mais il reste toujours injoignable.
Ok, j'ai compris, ça sent le débutant :)) En désactivant l'IPv4 j'ai aussi déconfiguré mon interface réseau ($ ifconfig -a ne me donnait plus qu'une adresse IPv6).
J'ai donc réactivé l'IPv4 mais sans les serveurs DNS IP v4 pour l'instant, et du coup le ping depuis le “PC Internet” fonctionne bien à présent, et le ping6 aussi, aussi bien depuis le “PC Internet” que depuis le PC du Bottin :).
J'ai aussi re-vérifié (j'avais un petit doute sur IPv6) : j'ai désactivé l'IPv4 en mettant Method sur “Disabled” dans l'onglet “IPv4 Settings”, puis désactivé/réactivé le réseau via nm-tray (décidémment très pratique cette application) et le ping ne fonctionne plus dans les 2 sens en IPv4 mais fonctionne bien dans les 2 sens en IPv6.
- Par contre je n'ai toujours pas d'internet / DNS en IPv6
- J'ai aussi testé d'autres serveurs DNS en IPv6 (Lifewire (Free and Public DNS Servers)).
- Et une connexion sur Google.com au cas où ce serait les sites en question qui ne supporteraient pas une connexion en IPv6
Je vais regarder si je trouve d'autres infos sur le net.
Sur le PC du Bottin j'ai :
$ ping6 google.com ping6: google.com: Nom ou service inconnu
Alors que depuis mon vieux “PC Internet” çà marche :))
$ ping6 google.com PING google.com(par10s27-in-x0e.1e100.net (2a00:1450:4007:809::200e)) 56 data bytes PING google.com(par10s27-in-x0e.1e100.net (2a00:1450:4007:809::200e)) 56 data bytes 64 bytes from par10s27-in-x0e.1e100.net (2a00:1450:4007:809::200e): icmp_seq=1 ttl=57 time=27.10 ms 64 bytes from par10s27-in-x0e.1e100.net (2a00:1450:4007:809::200e): icmp_seq=2 ttl=57 time=27.6 ms 64 bytes from par10s27-in-x0e.1e100.net (2a00:1450:4007:809::200e): icmp_seq=3 ttl=57 time=28.6 ms 64 bytes from par10s27-in-x0e.1e100.net (2a00:1450:4007:809::200e): icmp_seq=4 ttl=57 time=27.5 ms 64 bytes from par10s27-in-x0e.1e100.net (2a00:1450:4007:809::200e): icmp_seq=5 ttl=57 time=27.5 ms ^C --- google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 10ms rtt min/avg/max/mdev = 27.491/27.835/28.608/0.427 ms
C'est le monde à l'envers :))
Bon au moins ça fonctionne sur l'un des PC, donc ça ne vient pas de ma box, et de plus ça valide l'utilisation du test avec ping6.
J'ai un doute sur l'adressage à utiliser dans l'onglet “IPv6 Settings”, en particulier le Prefix (64). Non à priori c'est bon, c'est le masque de sous-réseau et son format me semble bon d'après mes lectures : “La taille du sous-réseau d’une adresse IPv6 étant de 64bits, les hôtes disposent des 64 bits restants pour la numérotation à l’intérieur du sous-réseau.” (IT-Connect.fr (IPv6 : Assignation des adresses dans un réseau local)
Encore une excellente doc, devinez chez qui : Ubuntu-fr (L'ipv6) :) Et aussi : Linux IPv6 HOWTO (fr)
J'ai l'impression que ce qui pêche c'est ma route :
$ route Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface
ou alors il y a une commande spécifique là aussi pour l'IPv6 (la commande “$ route6” ne semble pas exister) ?
La route est probablement à revoir pour l'IPv6 et peut-être aussi un truc à configurer sur ma passerelle pour forwarder l'IPv6 (actuellement elle forwarde l'IPv4)
Note à posteriori : Non, la table de routage de l'IPv6 s'obtient avec la commande :
La table de routage :
$ ip -6 route
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp24s0 proto kernel metric 256 pref medium
default via fe80::221:85ff:xxxx:xxxx dev enp24s0 proto static metric 100 pref medium
Les adresses IPv6 sont obtenues par :
$ ip -6 addr
1: lo <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp24s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtp 1500 state UP qlen 1000
enet6 fe80::2d8:61ff:xxxx:xxxx:xxx scope link noprefixroute
valid_lft forever preferred_lft forever
(moi y'en a parler alien :))
Sur le “PC Internet” j'ai (table de routage) :
$ ip -6 route ::1 dev lo proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev eth1 proto kernel metric 256 pref medium
Une autre doc : Léa Linux (Configurer l'IPv6 Natif)
La suite demain :)
Le 18/07/2019 :
J'ai testé guidedog : visiblement l'outil est vieux, il ne prend pas en charge l'IPv6. Je vais regarder si je trouve dans les dépôts autre-chose pour forwarder l'IPv6.
Quelques logiciels à regarder de plus près :
- Miredo
- ndisc6 (des outils réseau, à priori plutôt pour le PC du Bottin)
- frr
Je vais tester ces outils mais je suis un peu pessimiste. J'atteind les limites de mes compétences et de mes envies à creuser le sujet. S'il n'y a pas une interface simple de type guidedog je pense que je ne vais pas pousser très loin (je ne vais pas y passer ma vie, on n'est pas tous des professionnels / passionnés du réseau).
Après test :
- Miredo : un outil vraisemblablement très puissant, mais c'est encore un truc pour les barbus du réseau, pas pour les juvéniles (j'ai 54 ans :) comme moi.
- frr : idem
- ndisc6 : je verrai plus tard
C'est bon, je jette l'éponge pour l'IPv6 (marre d'y passer des soirées à lire des trucs rasoirs et/ou compliqués) tant qu'il n'y aura pas au moins un outil un peu graphique (à la guidedog) pour l'IP forwarding IPv6.
Le 19/07/2019 :
La nuit porte conseil, je n'ai pas résisté (quand un truc me travaille :))
En IPv4, si je désactive “Enable routing” sous guidedog sur le “PC Internet”, je n'ai plus de connexion internet sur le PC du Bottin. Sous Guidedog, après activation de cette option, sur la même page j'ai validé “Enable IP Masquerade” puis “Masquerade FTP” et “Masquerade IRC” pour 3 adresses, dont celle du PC du Bottin : 192.168.2.2/24.
Il faudrait que je parvienne à faire de même manuellement pour l'IPv6.
Pour forwarder temporairement les paquets en IPv6, on peux lancer la commande :
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
Mais :
- ça reste temporaire,
- pas sûr que ça suffise.
Une très bonne documentation (selon mes critères : claire, à la portée du débutant, exacte selon toute vraisemblance :)) : IT connect (Activer l’IP forwarding sous Linux (IPv4/IPv6))
Voir où en est l'IP forwarding :
Pour l'IPv4 (1=activé, 0=désactivé): cat /proc/sys/net/ipv4/ip_forward 1 Pour l'IPv6 (1=activé, 0=désactivé): # cat /proc/sys/net/ipv6/conf/all/forwarding 0
Pour l'activer temporairement :
Pour l'IPv4 (1=activé, 0=désactivé): # sysctl -w net.ipv4.ip_forward=1 Pour l'IPv6 (1=activé, 0=désactivé): # sysctl -w net.ipv6.conf.all.forwarding=1 # cat /proc/sys/net/ipv6/conf/all/forwarding 1
Nota : toujours pas de réseau, ça ne suffit pas comme je m'y attendais un peu, mais je pense que c'est quand même une condition nécessaire
Toujours selon cette même documentation (mais je l'avais déjà lu ailleurs et l'avais déjà activé pour l'IPv4 il y a longtemps de cette manière), pour activer de manière pérenne l'IPv4 et l'IPv6, on édite (sur le PC passerelle, le “PC Internet”) le fichier /etc/sysctl.conf et l'on décommente les lignes correspondantes :
# Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1 # Uncomment the next line to enable packet forwarding for IPv6 # Enabling this option disables Stateless Address Autoconfiguration # based on Router Advertisements for this host net.ipv6.conf.all.forwarding=1
J'enregistre et redémarre (le PC Internet) tout de même ;).
Mais ça ne suffit pas.
Une autre doc sur l'IPv6 : debian-handbook(Le cahier de l'administrateur Debian - IPv6)
(Par contre elle n'explique pas comment l'auteur choisi son adresse addresse 2001:db8:1234:5::1:1 ???)
À priori, la suite semble converger vers nftables (le successeur plus évolué d'iptables). J'ai lu un peu de doc sur le sujet, mais ça me semble immonde ce truc. Elles sont où les interfaces “à la guidedog” ?
Je me refuse à rentrer dans ce truc immonde (plutôt passer sous Windows que de me taper ces lignes de codes) où j'ai 99 chances sur 100 de me prendre les pieds dans le tapis et d'y passer des dizaines de soirées à m'arracher les cheveux, tout çà pour une configuration qui, lorsqu'elle sera mise en place, restera inchangée pendant des années, et quand j'aurais à nouveau besoin de m'y pencher, soit tout aura changé, soit j'aurais tout oublié, voir les deux :))
Je ne comprend pas que les barbus Linuxiens n'aient pas pensés aux non barbus. Avoir 2 PC dont 1 vieux qui servirait de PC de secours et de routeur est-il si exotique que personne ne se donne la peine de rendre la configuration du routage accessible aux novices ?
Pas étonnant que la part de marché de Linux reste confidentielle. Ca me gave de me battre avec çà.
Donc pour l'instant je reste en IPv4, l'IPv6 n'est pas à ma portée (ça me fait mal de dire ça).
Nota : j'ai bien compris (à la lecture de différents sites) que les adresses IPv6 en “fe80:” étaient des adresses locales (comme les “192.” en IPv4) et n'étaient donc pas visibles de l'extérieur du réseau local.
Voilà autre chose : ce soir je teste à nouveau l'IPv6 sur le “PC Internet” via test-ipv6.com (avec l'idée de voir quelle est mon adresse IPv6 publique) : çà ne fonctionne plus. Je suis à peu près certain que ça fonctionnait il y a quelques jours.
Je confirme que ça fonctionnait (puisque je l'avais noté) : 2a01:e35:xxxx:xxxx:xxx:xxxx:xxxx:xxx
À présent il m'affiche :
Votre adresse IPv4 sur l'Internet semble être xx.xx.xx.xx Votre Fournisseur d'Accès Internet (FAI) semble être PROXAD Pas d'adresse IPv6 détectée [plus d'info] Il semble que vous n'êtes capable que d'aller sur la partie IPv4 de l'Internet seulement. Vous n'êtes pas capable de visiter des sites qui sont seulement IPv6. To ensure the best Internet performance and connectivity, ask your ISP about native IPv6. [plus d'info] HTTPS support is now available on this site. [plus d'info] Votre serveur DNS (qui est peut-être chez votre FAI) semble avoir un accès IPv6 à Internet. 0/10 pour la stabilité et la préparation de votre IPv6, quand les éditeurs offriront leur contenu uniquement en IPv6 Détail : Test avec enregistrement DNS IPv4 OK (0.213s) en ipv4 Test avec enregistrement DNS IPv6 échec (0.066s) Test avec enregistrement DNS en double pile OK (0.212s) en ipv4 Test DNS double pile et grand paquet OK (0.068s) en ipv4 Test IPv4 sans DNS OK (0.093s) en ipv4 Test IPv6 sans DNS échec (0.009s) Test grand paquet IPv6 échec (0.064s) Test si le serveur DNS de votre FAI utilise IPv6 OK (0.288s) en ipv4 Détermination de votre Fournisseur d'Accès Internet IPv4 OK (0.368s) en ipv4 ASN 12322 Détermination de votre Fournisseur d'Accès Internet IPv6 échec (0.211s)
Super. En plein milieu de mes tests :))
Le 20/07/2019 :
Pour ce problème d'IPv6 qui ne fonctionne plus j'ai suspecté des services que j'avais désactivé (dans /etc/cron hier, j'avais juste isolé les fichiers dans des répertoires), mais je les ai tous réactivé ce matin et redémarré le PC et ça ne fonctionne toujours pas. Je n'ai rien touché côté paramétrage de ma box sur le site de Free.
Le site internet me renvoi le même message que ci-avant et : ~$ ping6 google.com connect: Le réseau n'est pas accessible ~$ ping google.com PING google.com (172.217.19.238) 56(84) bytes of data. 64 bytes from par21s11-in-f14.1e100.net (172.217.19.238): icmp_seq=1 ttl=50 time=27.8 ms 64 bytes from par21s11-in-f14.1e100.net (172.217.19.238): icmp_seq=2 ttl=50 time=26.10 ms 64 bytes from par21s11-in-f14.1e100.net (172.217.19.238): icmp_seq=3 ttl=50 time=25.10 ms ^C --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 4ms rtt min/avg/max/mdev = 25.969/26.896/27.760/0.756 ms
Donc je vais attendre quelques jours (peut-être une panne provisoire) avant de m'y remettre - éventuellement.
Quand j'ai un truc qui me trotte dans la tête, … :))
J'ai trouvé, c'est mon paramétrage de /etc/sysctl.conf. J'ai recommenté ma ligne “net.ipv6.conf.all.forwarding=1” :
# Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1 # Uncomment the next line to enable packet forwarding for IPv6 # Enabling this option disables Stateless Address Autoconfiguration # based on Router Advertisements for this host # net.ipv6.conf.all.forwarding=1
et après un nouveau redémarrage, l'IPv6 fonctionne à nouveau sur le “PC Internet”
$ ping6 google.com PING google.com(par10s38-in-x0e.1e100.net (2a00:1450:4007:805::200e)) 56 data bytes 64 bytes from par10s38-in-x0e.1e100.net (2a00:1450:4007:805::200e): icmp_seq=1 ttl=57 time=33.9 ms 64 bytes from par10s38-in-x0e.1e100.net (2a00:1450:4007:805::200e): icmp_seq=2 ttl=57 time=27.3 ms 64 bytes from par10s38-in-x0e.1e100.net (2a00:1450:4007:805::200e): icmp_seq=3 ttl=57 time=28.2 ms
et sur test-ipv6.com j'ai bien :
Votre adresse IPv4 sur l'Internet semble être xx.xx.xx.xx Votre adresse IPv6 sur l'Internet semble être 2a01:e35:xxxx:xxxx:xxx:xxxx:xxxx:xxx Votre Fournisseur d'Accès Internet (FAI) semble être PROXAD Comme vous avez IPv6, nous avons ajouté un onglet indiquant la qualité de votre connexion IPv6. [plus d'info] Il semblerait que vous utilisez un tunnel 6RD géré pour transporter IPv6 au-dessus d'IPv4. [plus d'info] HTTPS support is now available on this site. [plus d'info] Votre serveur DNS (qui est peut-être chez votre FAI) semble avoir un accès IPv6 à Internet. Votre score de préparation 10/10 pour la stabilité et la préparation de votre IPv6, quand les éditeurs offriront leur contenu uniquement en IPv6 Test avec enregistrement DNS IPv4 OK (0.150s) en ipv4 Test avec enregistrement DNS IPv6 OK (0.158s) en ipv6 Test avec enregistrement DNS en double pile OK (0.242s) en ipv6 Test DNS double pile et grand paquet OK (0.091s) en ipv6 Test IPv4 sans DNS OK (0.103s) en ipv4 Test IPv6 sans DNS OK (0.108s) en ipv6 Test grand paquet IPv6 OK (0.231s) en ipv6 Test si le serveur DNS de votre FAI utilise IPv6 OK (0.617s) en ipv6 Détermination de votre Fournisseur d'Accès Internet IPv4 OK (0.650s) en ipv4 ASN 12322 Détermination de votre Fournisseur d'Accès Internet IPv6 OK (0.321s) en ipv6 ASN 12322
Donc lorsque j'active l'IP forwarding en IPv6 sur le “PC Internet” je n'ai plus d'IPv6 sur cette machine ???
Donc non résolu, je laisse de côté pour l'instant.
Nouvelle avancée significative sur l'IPv6 le 21/07/2019 !
(nota : je réalise cette rédaction en Wi-Fi et en IPv6 sur le WIKI du Bottin)
L'idée était de tester l'IPv6 sans passerelle via le Wi-Fi sur le PC du Bottin.
Condition de mes tests :
- Pour mes tests, j'arrête le “PC Internet” (ma passerelle ethernet), ce qui m'évite de désactiver l'IPv4. En effet, l'inconvénient de network-manager-gnome c'est que lorsque l'on désactive la connexion via l'onglet “IPv4 Settings” ou “IPv6 Settings”, l'interface réinitialise les paramétrages de l'onglet, ce qui nous fait perdre nos réglages. Ainsi je suis sûr que s'il y a une connexion, ce sera par le moyen que j'ai choisi (et pas par une voie détournée qui me ferait croire que ça fonctionne).
- J'avais défini 2 fichiers de paramétrages : “Connexion Ethernet (enp24s0)” (inchangé, voir ci-avant) et “Wi-Fi via la Freebox” (qui va me servir pour mes tests).
J'ai d'abord testé si le fait de laisser activé le fichier “Connexion Ethernet (enp24s0)” (rappel : le PC passerelle est éteint donc il ne pourra pas se connecter via ce fichier) perturbait ou non la connexion.
Réponse : non. Que je laisse ce fichier activé ou non, avec le PC passerelle éteint, ça ne perturbe pas la connexion (qu'il ne peux faire que par Wi-Fi dans ces conditions).
Je modifie mon fichier “Wi-Fi via la Freebox” comme suit :
Onglet IPv4 Settings
- Method : Disabled (provisoire, après mes tests je le remet sur “Automatic (DHCP)” pour sa connexion avec ma box en DHCP IPv4)
Onglet IPv6 Settings
- Method : Automatic
- Additional DNS servers : 2620:119:35::35, 2620:119:53::53 (ceux d'OpenDNS, car il s'agit ici de serveurs complémentaires au cas où ceux de Free - qu'il trouve tout seul, feraient défaut)
- Additional search domains : vide (par défaut)
- IPv6 privacy extensions : Disabled (par défaut)
- IPv6 address generation mode : Stable privacy (par défaut)
* ☐ Requiert un adressage IPv6 pour que cette connexion fonctionne (désactivé, par défaut)
- Bouton “Routes…” : (pas utilisé, rien de défini sous ce menu additionnel)
J'enregistre puis désactive/active la connexion Wi-Fi pour qu'il prenne en compte mes nouveaux paramétrages et relance la connexion et çà marche !
Mais pour l'instant (le 21 juillet 2019) de nombreux sites ne sont pas prêts et lorsque je tente de m'y connecter uniquement en IPv6 ça ne fonctionne pas avec nombre d'entre eux :
- Google.com : Ok
- DuckduckGo : ne fonctionne pas en IPv6.
- Qwant : ne fonctionne pas en IPv6.
- Wikipedia : Ok
- Mastodon : Ok
- GitHub : ne fonctionne pas en IPv6.
- Bitbucket : Ok
- Debian : Ok
- YouTube : ne fonctionne pas en IPv6.
- Le Bottin des Jeux Linux : Ok (grâce à Tuxfamily ! Bravo TuxFamily !)
- etc…
Récapitulons
Pour pouvoir utiliser le “PC Internet” en passerelle je dois activer à la fois :
- l'IP forwarding (en IPv4 dans /etc/sysctl.conf on décommente la ligne “net.ipv4.ip_forward=1”, en IPv6 dans le même fichier on décommente la ligne “net.ipv6.conf.all.forwarding=1” mais dans ce cas la connexion IPv6 sur le “PC Internet” n'est plus reconnue)
- et l'IP masquerading pour la translation d'adresse réseau (Network address translation, en IPv4 j'utilise guidedog, un outil graphique dédié, en IPv6 il n'y a pas d'interface graphique pour l'instant). Sans une interface dédiée il faut passer par iptables ou nftables (le successeur), et là non ! pour moi :))
Conclusions provisoires :
- Je suis à peu près autonome pour l'IPv4 (grâce à guidedog, en espérant qu'il ne disparaisse pas celui-là aussi, sinon je ne pourrais plus passer par ma passerelle)
- Je ne suis pas mûr pour l'IPv6 en ethernet via une passerelle (l'IPv6 fonctionne en direct sur le “PC Internet” à condition de ne pas activer l'IP forwarding IPv6) car guidedog ne supporte pas l'IPv6 pour l'instant (je ne sais pas s'il est toujours vivant, je ne crois pas).
- L'IPv6 fonctionne en Wi-Fi en direct (sans passerelle) sur le PC du Bottin.
Pour l'instant je suis à court d'idées pour l'IPv6 ethernet via une passerelle. Retour au Bottin ;)
