Site web rétabli en IPv6

Palaiseau, le lundi 13 mai 2024

Cher Journal,

En procédant à ma vérification mensuelle des certificats TLS pour les domaines emlwks999.hd.free.fr et emlwks999.eu, j'ai dû procéder à un renouvellement manuel du domaine fourni par Free. Seulement, mes tentatives ont fini en échec répétés pour cause de connexions refusées par mon serveur web, d'après le message d'erreur renvoyé par le certbot. En grattant dans le fichier de journal indiqué dans le message d'erreur, j'ai noté que le cerbot côté Let's Encrypt rebondit sur de multiple domaines pour résoudre emlwks999.hd.free.fr, avant de finalement tenter une connexion via l'adresse IP en version 6. Pour une raison qui m'échappe, mon serveur Apache a cessé d'écouter les requêtes sur les ports IPv6 : toutes mes tentatives de connexion avec n'importe quel client web (Firefox, GET, etc) se sont soldées par des connexions refusées.

Visiblement, j'ai dû avoir cassé quelque chose à un moment dans la configuration des écoutes sélectives par ports. J'ai essayé de voir si je n'ai pas manqué quelque chose dans mon fichier /etc/apache2/ports.conf, mais il n'y a rien de particulier à y signaler :

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
	Listen 443
</IfModule>

<IfModule mod_gnutls.c>
	Listen 443
</IfModule>

Après quelque tentatives de raccorder le service explicitement sur les interfaces IPv6, et essuyer des erreurs de port déjà en cours d'utilisation, j'ai fini par rétablir le fichier de configuraton dans son état que je pensais initial, et redémarré le service :

$ sudo systemctl restart apache2

Les interfaces IPv6 étaient alors de nouveau disponibles. J'ignore pourquoi ou comment le service des addresses IP modernes a cessé, pendant que le schéma historique a continué à fonctionner. Ma conjecture est que ma machine pourrait avoir démarré le serveur web avant que l'interface ne soit disponible en IPv6. J'ai ajouté une configuration SLAAC explicite dans mon fichier d'interface pour m'assurer de bien avoir une configuration IPv6 pour considérer l'interface comme disponible, au format interfaces(5), en vue d'hypothétiquement faciliter les prochains redémarrages :

iface enp1s0 inet6 auto

Après arrêt et redémarrage de l'interface, la déclaration statique en IPv4 est revenue tout de suite, mais la déclaration automatique en SLAAC a pris de l'ordre d'une dizaine de secondes pour revenir, après que l'activation des interfaces réseau ait rendu la main. J'ignore depuis combien de temps le problème est présent, mais si c'est deux jours, alors ça coïnciderait avec le dernier redémarrage de la machine, ce qui validerait la conjecture.

Il y a probablement plusieurs morales à cette histoire. La première est de surveiller activement l'expiration de ses certificats TLS Let's Encrypt, au cas où quelque chose ne se passe pas comme prévu. La deuxième est que bien que techniquement supérieure, l'implémentation d'IPv6 reste manifestement très marginale, et donc il peut s'écouler du temps avant de se rendre compte d'un problème n'affectant que le circuit IPv6. La troisième est qu'il reste probablement quelque points à améliorer pour que le suivi des cibles réseau ne soit pas surprenant, notamment au vu des interfaces qui démarrent à différentes vitesses, et qui peuvent potentiellement affecter le démarrage des services qui dépendent du réseau si ce dernier n'est activé que partiellement.

	Name	Last modified	Size
	Parent Directory		-