Certificats racine Sectigo E46/R46
Blog Evolix
19 juin 2025
L’autorité de certification Sectigo a commencé à vendre depuis quelques semaines des certificats SSL/TLS signés par un certificat racine non reconnus sur certains systèmes. On vous explique pourquoi et comment résoudre ce problème.
Lorsqu’un logiciel tente d’établir une connexion SSL/TLS avec un tiers (souvent un serveur distant) il reçoit un certificat de ce serveur et vérifie s’il a été signé par un certificat racine de confiance.
La liste des certificats racine de confiance peut être gérée de plusieurs manières. En général, les navigateurs embarquent leur propre liste qui est mise à jour en même temps que le navigateur. Mais la plupart des logiciels ou bibliothèques utilisent le dépôt de confiance de leur système d’exploitation.
Il est assez rare que des nouveaux certificats racine soient ajoutés (ou retirés) et les mises à jour sont peu fréquentes et habituellement anticipables. De plus, les nouveaux certificats racine sont généralement signés de manière croisée par des certificats existants et déjà reconnus, pour faciliter leur mise en œuvre. À titre d’exemple, Let’s Encrypt a mis plusieurs années pour enfin pouvoir utiliser son propre certificat racine et se passer des signatures croisées d’autres autorités de certification.
Dans le cas présent, Sectigo (une autorité de certification majeure) a commencé il y a quelques semaines à signer des certificats avec 2 nouveaux certificats racine (appelés « E46 » et « R46 »).
Ces certificats racine ont été créés en 2021. Ils ont été diffusés en 2023 et par exemple Mozilla a commencé à les incorporer dans son dépôt de confiance en 2023.
Lors de connexions SSL/TLS à des services utilisant des certificats signés par E46 ou R46, les logiciels qui utilisent un dépôt de confiance contenant les certificats racine E46 et R46 peuvent valider la chaîne de confiance sans problème. Mais si les logiciels ne peuvent pas valider la chaîne de confiance, la connexion échoue. En cas d’erreur SSL/TLS on incrimine prioritairement (souvent à raison) une erreur de configuration du serveur qui présente le certificat, mais ici c’est plutôt le dépôt de confiance qui doit être mis à jour.
Debian – que nous utilisons sur nos serveurs – gère sa liste de certificats racine via le paquet ca-certificates. La première mention concrète de cette question remonte à février 2025 (l’intégration des certificats a été ralentie par des questions à propos de signatures croisées et de clarté sur l’utilisation effective de ces certificats). Depuis vendredi 13 juin 2025, un nouveau paquet ca-certificates contenant les certificats racine de Sectigo est disponible pour Debian 12 (la version stable actuelle).
Depuis jeudi 19 juin 2025, des paquets faits par Evolix sont disponibles pour Debian 9, 10 et 11 et ont été déployés sur nos serveurs (et conteneurs) infogérés. Et en parallèle les équipes Debian LTS et eLTS préparent des paquets plus officiels pour Debian 8/9/10/11. Les Debian en versions inférieures à 8 ne receveront pas de mise à jour par paquet. Pour rappel, Evolix supporte uniquement Debian 10, 11 et 12.
À noter qu’il est également possible d’intégrer des certificats racine manuellement si besoin.
Tout cela montre d’une part à quel point la notion de « chaîne de confiance » sur laquelle repose SSL/TLS est à la fois critique et fragile, et qu’une bonne communication entre les parties prenantes est nécessaire.
J’ai un serveur dédié infogéré par Evolix, suis-je concerné ?
Vous pouvez être concerné uniquement si vous faites des connexions SSL/TLS vers un service réseau externe qui a changé récemment son certificat. Depuis vendredi 20 juin 2025, si votre serveur (ou conteneur) est en Debian 9, 10, 11 et 12 vous ne devriez plus avoir de problème avec le dépôt de confiance du système. Si vous constatez un souci, ouvrez nous un ticket.
J’ai un serveur avec un Apache/Nginx en HTTPS, suis-je concerné ?
Vous êtes potentiellement concerné si vous avez mis en place un nouveau certificat Sectigo depuis environ 3 semaines. Dans ce cas, l’impact est que certains de vos utilisateurs ou clients risquent d’avoir des problèmes pour vous joindre tant qu’ils n’ont pas mis à jour le dépôt de confiance du système.
J’utilise Java sur mon serveur infogéré par Evolix, suis-je concerné ?
Java utilise sa propre liste de certificats racine, mais si vous utilisez Java installé par défaut sur le système, la liste devrait être identique et tout devrait être résolu à partir du vendredi 20 juin 2025 en Debian 9, 10, 11 et 12. Par contre, si vous utilisez une version spécifique de Java, vous devez gérer vous-même la liste des certificats avec la commande keytool.
J’utilise Docker sur mon serveur infogéré par Evolix, suis-je concerné ?
Pour rappel, Docker est un « mini-système indépendant », donc chaque conteneur intègre sa propre liste de certificats racine. Si vous avez besoin de mettre à jour cette liste, vous devrez reconstruire vos images.
Le mix audio des 20 ans d’Evolix
Blog Evolix
30 janvier 2025
En 2024, Evolix a soufflé ses 20 bougies lors d’une soirée mémorable, entourée de nos clients, partenaires et amis. Pour prolonger cette énergie, on vous fait revivre ce moment avec mix préparé spécialement pour l’occasion ! Bonne écoute
Retour sur le Chaos Communication Congress (38C3)
Blog Evolix
03 janvier 2025
Le Chaos Communication Congress (CCC) est un rendez-vous incontournable pour les passionnés de technologies, de cybersécurité, de sciences, et de culture hacktiviste. Nous nous sommes rendus à Hambourg pour la 38ᵉ édition du CCC, qui avait pour thème « Illegal Instructions ».
Avec 15 000 participants rassemblés au Centre des Congrès de Hambourg, le 38C3 a proposé un programme foisonnant, couvrant un large spectre de sujets :
- Des présentations techniques approfondies,
- Des conférences axées sur des enjeux politiques ou sociétaux,
- Des explorations artistiques et culturelles,
- Et des interventions scientifiques pointues.
L’événement s’est organisé autour de cinq salles principales : trois gérées directement par l’organisation du CCC (« Saal 1 », « Saal Glitch » et « Saal Zigzag ») et deux nouvelles (« Saal Huff » et « Saal Yell »), dont le contenu a été sélectionné par la communauté. Ces deux dernières salles, plus petites, ont permis d’enrichir encore le programme tout en étant retransmises et enregistrées, avec des traductions simultanées en anglais et en allemand.
Parmi les présentations marquantes, voici notre sélection de temps forts :
- La cérémonie d’ouverture
- Le retour des hackers polonais ayant manipulé des systèmes ferroviaires
- La révélation d’une fuite massive de données chez Volkswagen impliquant 800 000 véhicules électriques et leurs propriétaires (publiée aussi sur bleepingcomputer)
- OMG WTF SSO – A beginner’s guide to SSO (mis)configuration : une exploration des erreurs fréquentes dans la mise en place des solutions d’authentification unique
- io_uring, eBPF, XDP et AF_XDP : une plongée dans les technologies permettant d’optimiser les entrées/sorties
- Le protocole WHOIS : explications sur ce protocole historique et ses évolutions
- we made a globally distributed DNS network for shits and giggles
- 38C3: Infrastructure Review : une vue d’ensemble des chiffres et des coulisses techniques de l’événement.
Au total, c’est plus de 270 conférences à retrouver en vidéo sur media.ccc.de.
Le CCC est aussi un événement social : il offre une occasion unique de rencontrer des personnes d’horizons variés et de s’immerger dans une culture collaborative et bienveillante. Par exemple nous avons eu la chance de participer au sein de https://c3lingo.org/. Nous avons pu interpréter en direct plusieurs présentations en français, renforçant ainsi l’accessibilité du contenu pour les participants non anglophones.
Pour conclure, participer au Chaos Communication Congress c’est assister à des conférences qui diffusent de l’expérience et de nouvelles idées, et c’est s’immerger dans une communauté mondiale de passionnés partageant des connaissances et des valeurs d’inclusion et d’innovation. Une expérience que nous recommandons !
mysqldump génère des dumps non rétro-compatibles
Blog Evolix
24 décembre 2024
En raison d’une importante faille de sécurité de type « Remote Code Execution », les dumps générés avec mysqldump sous Debian 9/10/11 ne sont plus compatibles avec des mysql non corrigés. En effet, mysqldump ajoute une ligne pour forcer les clients MySQL non corrigés à se stopper :
/*!999999- enable the sandbox mode */
Si vous exportez vos dumps vers des serveurs MySQL non corrigés, vous devrez donc retirer cette ligne (par exemple avec la commande tail +2) pour permettre de restaurer le dump.
Comment savoir si mon mysqldump est concerné ?
Il vous suffit de jouer la commande mysqldump foobarbaz et vous devriez obtenir la ligne /*!999999- enable the sandbox mode */ si votre mysqldump intègre cette « correction ».
Sous Debian 9, 10 et 11, vous devriez être concernés.
Comment savoir si mon client MySQL est corrigé ou non ?
Si vous jouez la commande mysql –sandbox vous ne devriez pas avoir le message mysql: unknown option '--sandbox' sinon c’est que votre client MySQL n’est pas corrigé !
Je suis sous Debian 12, suis-je concerné ?
Pour l’instant (décembre 2024), MySQL n’est pas encore corrigé sous Debian 12 ! L’une des conséquences c’est qu’un dump généré sous Debian 9/10/11 n’est donc pas compatible pour Debian 12 ! Il faut donc retirer la 1ère ligne pour l’instant.
Une version corrigée pour Debian 12 est disponible dans stable-proposed-updates, mais elle est pour l’instant bloquée. Nous espérons qu’elle se débloque bientôt ou alors nous forcerons son utilisation sur nos serveurs infogérés.
EDIT 15 mars 2025 : une version corrigée est désormais dans Debian 12 depuis la sortie de la release mineure Debian 12.10, si vos systèmes sont bien à jour les dumps sous Debian 9/10/11/12 sont donc désormais compatibles entre les différentes versions !
mysql –sandbox
Nous vous conseillons d’utiliser l’option –sandbox le plus souvent possible, cela permet de s’assurer qu’aucune commande shell ne peut être injectée par le serveur MySQL.
Plus d’informations sur :
Je quitte Twitter
Jérémy Lecour
08 décembre 2024
Après Facebook en 2019 et Dropbox en 2020, j’ai fermé mon compte Twitter.
C’est drôle qu’à la fin de mon post sur la fin de mon compte Dropbox je disais « il me reste principalement Instagram et Gmail » en oubliant complètement Twitter.
Je pense qu’à l’époque je considérais Twitter comme acquis et pas du tout problématique. Et depuis l’ouverture de mon compte en 2009 j’avais toujours eu beaucoup de chance (ou une bonne curation) et jamais ressenti de toxicité dans mon fil. Je ne suivais pas de comptes trop populaires, pas de médias mainstream. Tant que j’ai pu, j’ai utilisé un client sans pub ni bullshit d’algorithmes.
Twitter a participé activement à mon instruction, à l’élargissement de mes connaissances sociales et techniques, à l’ouverture de mon esprit à des idées nouvelles et progressistes… Il a tenu une des promesses d’Internet.
Depuis le rachat de Twitter par Elon Musk, ses décisions éthiques et techniques désastreuses et enfin le naufrage d’extrême droite qu’il incarne, je ne pouvais plus supporter ça.
En janvier 2024, j’avais décidé de ne plus utiliser Twitter, pour 1 mois (comme un « dry january »), pour voir si j’arrivais à m’en détacher. Le mois s’est transformé en une année pendant laquelle je ne me suis connecté que 2 ou 3 fois. Ça a été un sevrage sans effort ni frustration. Pas de ressenti à la Trainspotting ou d’Arizona Dream pour moi.
Depuis 2019 j’utilise Mastodon sur l’instance interne d’Evolix (on en a aussi une ouverte à tou⋅tes). J’utilise aussi un client sans pub ni bullshit.
Je n’ai pas retrouvé toutes les mêmes personnes, mais j’en ai rencontré d’autres. et pour les grandes lignes je n’ai rien perdu.
J’ai aussi repris l’habitude de consulter des flux RSS de sites, blogs, médias… C’est tellement simple et propre. Ça aussi c’est une des promesses d’Internet qui est tenue.
Il y a quelques jours/semaines, j’ai téléchargé une dernière archive de mes données Twitter/X, et j’ai demandé à fermer mon compte. Je ne me fais pas d’idée, je ne pense pas qu’ils suppriment les données, mais je n’y suis plus.
Il paraît qu’il y a un risque de squatting sur les comptes fermés. Je n’ai pas trop pensé à ça (alors que j’y avais pensé en quittant Wordpress). On verra bien.
Freebox en bridge, edgerouter et IPv6
Jérémy Lecour
07 décembre 2024
Il existe plusieurs guides en lignes pour arriver à un résultat similaire (voir en bas d’article), mais chaque cas étant un peu particulier j’ai choisi de faire un retour sur le mien.
Je vais probablement écrire des bêtises ou montrer que j’ai fait des choses un peu débiles, mais je suis sûr que vous me les pointerez avec bienveillance.
Depuis les débuts de l’ADSL en France, je suis chez Free. Tout n’est pas parfait, mais j’ai toujours eu plus de raisons de rester que de partir.
J’ai la Freebox v6 « Revolution » depuis sa sortie en 2010/2011. Pendant longtemps j’ai utilisé la multitude de services : Wifi, UPnP/DLNA, passerelle DECT, stockage/seedbox, player TV/DVD/…
À une certaine période, à chaque orage je perdais ma Freebox (probablement à cause d’installations communes mal isolées) et j’ai sérieusement songé à quitter Free. Ils ne sont pas responsables des orages ni des défauts d’isolation de l’ADSL, mais l’électronique de la Freebox est notoirement peu résistante aux surtensions venant du réseau téléphonique.
J’ai donc petit-à-petit réduit ma dépendance aux services proposés, jusqu’à avoir un “vrai” routeur ainsi qu’un réseau Wifi et un système multimédia indépendants. Je n’utilise plus le DECT (plus de fixe à la maison). Par contre j’utilise encore la passerelle VoIP interne avec mon alarme qui est branchée en RJ11 sur la Freebox Server.
Je ne sais pas pourquoi mais j’ai toujours cru que passer ma Freebox Server en mode “bridge” (au lieu de “routeur”) allait me désactiver Freebox Player et la passerelle VoIP. C’est pourquoi je restais en mode “routeur” avec un double-NAT.
Aussi, mon ADSL s’est fortement dégradé dans le temps. Alors que je suis à 500m du DSLAM, mon débit max en upload s’était réduit d’environ 1 Mo/s à 450 ko/s ces derniers mois.
Très récemment (en septembre), j’ai découvert par hasard que j’étais éligible à un raccordement à la fibre optique depuis un certain temps, mais Orange qui a posé les fibres avait référencé des adresses qui n’existent pas sur le cadastre, donc les outils de tests d’éligibilité me disaient toujours d’arrêter de rêver. Il a fallu que je fouille sur les outils de l’ARCEP pour voir que j’étais éligible.
Ça a été tout un périple – je le raconterai peut-être plus tard – mais je suis raccordé à la fibre depuis début décembre.
Je dois dire d’ailleurs que le service client de Free (et la procédure de transition ADSL/Fibre) a été incroyable. J’étais resté sur des équipes sous-dimensionnées, délocalisées, limites incompétentes… Mais je constate que ça s’est énormément amélioré.
Et qu’est-ce qu’on fait quand on passe à la fibre ? On court tester à quel point ça va vite. Un copain qui héberge un “speedtest” chez lui (chez Free aussi) m’a demandé de tester la liaison entre nos deux connexions. Sauf que les services qu’il héberge ne sont accessibles qu’en IPv6 et par flemme (notamment à cause de l’empilement de routeurs chez moi) je n’avais pas fait en sorte de pouvoir faire de l’IPv6.
Après tant d’années à procrastiner, j’ai voulu faire l’effort et activer l’IPv6. Et une des approches les plus simples était de passer le Freebox Server en mode bridge. J’étais prêt à renoncer complètement au Freebox Player, mais des pages mentionnaient qu’en bidouillant un truc avec un VLAN 100… on pouvait le faire remarcher. Idem pour la passerelle VoIP qui n’était pas listée dans les services désactivés en passant en mode bridge.
Fin du contexte, début de la technique.
Lorsque la Freebox Server passe en mode bridge, elle attribue l’IP publique (probablement par DHCP) à la première machine qui la demande sur son switch ethernet.
En passant dans ce mode, j’ai perdu accès à Internet et au FreeboxOS.
Sur le switch intégré du Freebox Server j’avais aussi une sonde Atlas (86.83% d’uptime depuis avril 2012) en plus du FreePlug et de mon routeur.
Donc soit l’adresse publique a été donnée d’abord à la sonde Atlas au lieu de mon routeur, soit mon routeur n’avait pas encore refait de requête DHCP et il était resté sur son adresse locale.
J’ai eu peur d’avoir fait une belle connerie ; j’ai tout débranché du Freebox Server et rebooté mon routeur. Ça l’a forcé à refaire une requête DHCP et il a donc pris l’adresse publique. Et comme il n’avait rien changé à sa configuration de serveur DHCP, NAT… j’ai retrouvé accès à Internet et au FreeboxOS.
Pour l’accès au FreeboxOS par https://mafreebox.freebox.fr, je n’ai pas en tête le détail exact, mais je suppose que le Freebox Server intercepte les requêtes à 212.27.38.253
. En tous cas on ne perd pas l’accès quand on est mode bridge. On peut toujours revenir en arrière… C’est aussi utile pour retrouver l’adresse IPv6 du lien local (pour plus tard).
Au final, j’ai rebranché ma sonde Atlas en aval du routeur et elle remarché directement. Pour le FreePlug, j’y reviens plus tard, mais y’a pas de souci.
Pour la partie IPv6, j’ai suivi des articles à droite et à gauche mais voici en gros ma configuration (valide pour EdgeOS v2.0.9-hotfix.7
).
NB : J’ai mis des ******
à la place d’informations spécifiques et sans intérêt.
J’ai mis <IPV6-PREFIX>
qui correspond aux 4 premiers “champs” de votre bloc d’IPv6 donné par Free.
Enfin, j’ai mis <FREEBOX-IPV6-LINK-LOCAL>
pour la route statique, qui correspond à l’adresse IPv6 locale de votre Freebox Server. On récupère cette information dans FreeboxOS > Paramètres de la Freebox > Mode Avancé > Configuration IPv6 > Général
.
firewall {
all-ping enable
broadcast-ping disable
group {
network-group RFC1918 {
description "RFC1918 ranges"
network 10.0.0.0/8
network 172.16.0.0/12
network 192.168.0.0/16
}
}
ipv6-name WANv6_IN {
default-action drop
description "WAN inbound traffic forwarded to LAN"
enable-default-log
rule 10 {
action accept
description "Allow established/related sessions"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
rule 30 {
action accept
description "Allow ICMPv6"
protocol icmpv6
}
}
ipv6-name WANv6_LOCAL {
default-action drop
description "WAN inbound traffic to the router"
enable-default-log
rule 10 {
action accept
description "Allow established/related sessions"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
rule 30 {
action accept
description "Allow ICMPv6"
protocol ipv6-icmp
}
rule 40 {
action accept
description "Allow DHCPv6"
destination {
port 546
}
protocol udp
source {
port 547
}
}
}
ipv6-receive-redirects disable
ipv6-src-route disable
ip-src-route disable
log-martians enable
name IOT_IN {
default-action accept
description ""
rule 1 {
action accept
description "Allow established/related"
log disable
protocol all
state {
established enable
invalid disable
new disable
related enable
}
}
rule 2 {
action drop
description "Drop invalid state"
log disable
protocol all
state {
established disable
invalid enable
new disable
related disable
}
}
rule 3 {
action drop
description "Block local access"
destination {
group {
network-group RFC1918
}
}
log disable
protocol all
source {
group {
}
}
}
}
name IOT_LOCAL {
default-action drop
description ""
rule 1 {
action accept
description "Allow established/related"
log disable
protocol all
state {
established enable
invalid disable
new disable
related enable
}
}
rule 2 {
action drop
description "Drop invalid state"
log disable
protocol all
state {
established disable
invalid enable
new disable
related disable
}
}
rule 3 {
action accept
description "Allow DNS"
destination {
port 53
}
log disable
protocol tcp_udp
}
rule 4 {
action accept
description "Allow DHCP"
destination {
port 67
}
log disable
protocol udp
}
}
name WAN_IN {
default-action drop
description "WAN to internal"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
name WAN_LOCAL {
default-action drop
description "WAN to router"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
name WAN_OUT {
default-action accept
description "router to WAN"
rule 1 {
action drop
description "TV out (ethernet)"
log enable
protocol all
source {
mac-address ******
}
}
rule 2 {
action drop
description "TV out (wifi)"
log enable
protocol all
source {
mac-address ******
}
}
rule 3 {
action accept
description NTP
destination {
port 123
}
log enable
protocol udp
}
}
receive-redirects disable
send-redirects enable
source-validation disable
syn-cookies enable
}
interfaces {
ethernet eth0 {
address dhcp
address fe80::1/64
description Internet
duplex auto
firewall {
in {
ipv6-name WANv6_IN
name WAN_IN
}
local {
ipv6-name WANv6_LOCAL
name WAN_LOCAL
}
out {
name WAN_OUT
}
}
speed auto
}
ethernet eth1 {
description Local
duplex auto
speed auto
}
ethernet eth2 {
description Local
duplex auto
speed auto
}
ethernet eth3 {
description Local
duplex auto
speed auto
}
ethernet eth4 {
description Local
duplex auto
poe {
output off
}
speed auto
}
loopback lo {
}
switch switch0 {
address 10.10.0.1/24
address <IPV6-PREFIX>::1/64
description Local
ipv6 {
dup-addr-detect-transmits 1
router-advert {
cur-hop-limit 64
link-mtu 0
managed-flag false
max-interval 600
other-config-flag false
prefix <IPV6-PREFIX>::/64 {
autonomous-flag true
on-link-flag true
valid-lifetime 2592000
}
reachable-time 0
retrans-timer 0
send-advert true
}
}
mtu 1500
switch-port {
interface eth1 {
}
interface eth2 {
}
interface eth3 {
}
interface eth4 {
}
vlan-aware disable
}
vif 20 {
address 10.10.20.1/24
description IOT
firewall {
in {
name IOT_IN
}
local {
name IOT_LOCAL
}
}
mtu 1500
}
}
}
protocols {
static {
route6 ::/0 {
next-hop <FREEBOX-IPV6-LINK-LOCAL> {
description Freebox
interface eth0
}
}
}
}
service {
dhcp-server {
disabled false
hostfile-update disable
shared-network-name IOT {
authoritative disable
subnet 10.10.20.0/24 {
default-router 10.10.20.1
dns-server 10.10.20.1
lease 86400
start 10.10.20.2 {
stop 10.10.20.254
}
static-mapping shellyplugsg3-****** {
ip-address 10.10.20.11
mac-address ******
}
}
}
shared-network-name LAN {
authoritative enable
subnet 10.10.0.0/24 {
default-router 10.10.0.1
dns-server 10.10.0.1
domain-name ******
lease 86400
start 10.10.0.21 {
stop 10.10.0.240
}
static-mapping TV-ethernet {
ip-address 10.10.0.33
mac-address ******
}
static-mapping TV-wifi {
ip-address 10.10.0.48
mac-address ******
}
}
}
static-arp disable
use-dnsmasq disable
}
dns {
forwarding {
cache-size 500
listen-on switch0
listen-on switch0.20
}
}
gui {
http-port 80
https-port 443
older-ciphers enable
}
mdns {
reflector
}
nat {
rule 5010 {
description "masquerade for WAN"
outbound-interface eth0
type masquerade
}
}
ssh {
port 22
protocol-version v2
}
unms {
disable
}
}
system {
analytics-handler {
send-analytics-report true
}
crash-handler {
send-crash-report true
}
domain-name ******
host-name ******
login {
user ****** {
authentication {
encrypted-password ******
}
level admin
}
}
ntp {
server 0.ubnt.pool.ntp.org {
}
server 1.ubnt.pool.ntp.org {
}
server 2.ubnt.pool.ntp.org {
}
server 3.ubnt.pool.ntp.org {
}
}
offload {
hwnat enable
}
syslog {
global {
facility all {
level notice
}
facility protocols {
level debug
}
}
}
time-zone Europe/Paris
}
Je précise tout de même quelques caractéristiques de la configuration de mon routeur :
- J’utilise
eth0
pour le WAN et j’ai crééswitch0
aveceth1-4
pour le LAN. Je n’utilise pas le PoE sureth4
. - J’ai une TV connectée (à mon grand regret) à qui je refuse la sortie sur Internet à part pour le NTP (et en écrivant ces lignes je capte que cette règle ne s’applique qu’en IPv4 et pas encore en IPv6).
- J’ai un réseau Wifi spécial pour les objets connectés (car certains doivent accéder à Internet) qui tague les paquets avec le VLAN 20. Ça permet au routeur de les cantonner à un LAN spécial (séparé du LAN principal), tout en les laissant sortir sur Internet. Ça protège contre la latéralisation (depuis un object connecté on ne peut pas voir les ordis/NAS/téléphones/…).
- La plupart de mes appareils (ordis,NAS, téléphones…) ont une IP fixe dans la plage du DHCP, mais j’ai omis ça exprès. Vous n’avez pas besoin de savoir ce qu’il y a chez moi.
Avec cette configuration, j’ai bien de l’IPv6 sortant sans problème.
Il y a par contre un truc étrange ; lorsque je suis en SSH sur le routeur, un ping en IPv6 ne marche pas alors qu’il marche depuis un ordi sur le LAN. Je m’en fiche pas mal mais c’est probablement que j’ai raté quelque chose.
Il reste un détail, le Freebox Player. Même si la plupart du temps j’utilise un autre système multimédia, j’aime savoir que je peux utiliser le lecteur DVD/BluRay du Player.
J’avais noté que selon les Freebox il y avait des astuces pour faire marche le Player quand le Server est en mode bridge. Pour la Freebox « Révolution » il y a une histoire de VLAN 100.
Mais en branchant un câble ethernet (ou les FreePlugs) entre le Freebox Player et le switch intégré du Freebox Server, ça marche directement. Je n’ai eu aucune configuration à faire.
J’ai même essayé de reboot le Freebox Server et le routeur, pour vérifier si l’histoire du DHCP pour l’IP publique n’allait pas casser, mais non, c’est resté fonctionnel.
Je n’ai pas encore fait le test de l’appel sortant par mon alarme. Je brancherai un téléphone à la place pour essayer, mais j’ai toute raison de penser que c’est OK.
Quelques références utiles