Passerelles IP multiples sur Atlas

Stefjm · Mars 15, 2026, 6:04

Bonjour,

Le réseau de la box Atlas me fait des blagues.

Hier, 3 reboot pour obtenir la bonne config réseau : ça allait à peu près pour le routage mais pas de DNS alors que mon serveur DHCP les distribue très bien en général.

A priori il y a un relais local à la box Atlas.

cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 127.0.0.1
options edns0 trust-ad

Avec un peu de patience (j’ai lu qu’il n’y avait pas grand chose d’autre à faire), cela a fini par remarcher, mais cela fait quand même un peu peur quand tous les plugins partent en live pour cause de non résolution DNS (et seulement sur l’atlas qui n’atteignait aucune adresse DNS).

Aujourd’hui, j’ai eu une panne de mon FAI principal. La bascule sur les connexions de secours s’est bien passée pour le réseau local sauf pour l’Atlas!

L’Atlas s’est retrouver avec trois passerelles! Cela marche très mal…

nmcli connection show ethernet-eth0

IP4.ADDRESS[1]: 192.168.1.7/24 // Réseau local
IP4.GATEWAY:    192.168.1.1 // FAI Principal
IP4.ROUTE[1]:   dst = 0.0.0.0/0, nh = 192.168.1.254, mt = 100 // FAI de secours
IP4.ROUTE[2]:   dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 0 // encore FAI Principal
IP4.ROUTE[3]:   dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100 // local
IP4.DNS[1]:     1.1.1.1
IP4.DNS[2]:     8.8.8.8

sudo route
Kernel IP routing table
Destination     Gateway         Genmask         Flags  Metric Ref    Use Iface
default         192.168.1.1      0.0.0.0         UG     0      0      0   eth0
default         192.168.1.254    0.0.0.0         UG    100     0      0   eth0
192.168.1.0     0.0.0.0         255.255.255.0    U     100     0       0  eth0

Lors du retour à la normale, il y avait encore trois passerelles identiques (et du coup cela marche mais bizarre quand même).

nmcli connection show ethernet-eth0

IP4.ADDRESS[1]: 192.168.1.7/24
IP4.GATEWAY:    192.168.1.1
IP4.ROUTE[1]:   dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100
IP4.ROUTE[2]:   dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 0

route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         k-box.home      0.0.0.0         UG    0      0        0 eth0
default         k-box.home      0.0.0.0         UG    100    0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0

cat /etc/network/interfaces`
source /etc/network/interfaces.d/*
# Network is managed by Network manager
auto lo
iface lo inet loopback

J’ai l’impression qu’il y a une route statique qui parasite celle donnée par DHCP.

Avez-vous déjà rencontré ce type de gag?
Que feriez-vous d’autres pour diagnostiquer?

Merci d’avance pour le coup de main.
Cordialement

Stefjm · Avril 13, 2026, 11:33

Bonjour,
Je crois que je comprends un peu mieux ce qui se passe (mal) mais je ne sais pas corriger.
Ma box Atlas est en client DHCP et c’est network manager qui gère son réseau.

Elle récupère correctement les deux DNS fournis par la box de mon FAI

IP4.DNS[1]:                             192.168.1.5
IP4.DNS[2]:                             192.168.1.1
DHCP4.OPTION[1]:                        broadcast_address = 192.168.1.255
DHCP4.OPTION[2]:                        dhcp_lease_time = 300
DHCP4.OPTION[3]:                        dhcp_server_identifier = 192.168.1.1
DHCP4.OPTION[4]:                        domain_name_servers = 192.168.1.5 192.168.1.1
DHCP4.OPTION[5]:                        expiry = 1776078380
DHCP4.OPTION[6]:                        host_name = JeedomAtlas
DHCP4.OPTION[7]:                        ip_address = 192.168.1.7
DHCP4.OPTION[8]:                        next_server = 192.168.1.1

Globalement cela se passe bien depuis que j’ai configuré le DNS local de l’Atlas. Je n’ai plus eu d’absence de DNS au démarrage de Jeedom.

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

Sauf quand le DNS secondaire (.1 FAI) est utilisé à la place du primaire (.5 NAS) même quand le primaire est disponible. C’est moyennement ennuyeux, mais je me suis habitué à avoir des noms sympa sur mon réseau local ( .5 serveur DNS de mon NAS).

En ce moment, les DNS sont inversés :

resolvectl status eth0
Link 2 (eth0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.5 192.168.1.1

Le seul « truc » que j’ai trouvé est de forcé un seul DNS puis de remettre les deux, mais c’est statique donc bien moche…

sudo resolvectl dns eth0 192.168.1.5
sudo resolvectl dns eth0 192.168.1.5 192.168.1.1

Savez vous pourquoi et comment Debian choisit les DNS à utiliser?

Cordialement

Stefjm · Avril 14, 2026, 7:10

Visiblement, le comportement de Linux avec les DNS primaire et secondaire n’est pas le même qu’avec Windows.
En Linux, il n’y a pas de priorité entre primaire et secondaire et donc pas de façon propre de faire ce que je voulais.
Si le DNS primaire ne répond pas assez vite, le secondaire est essayé et reste par défaut.

akenad · Avril 14, 2026, 7:31

Bonjour,

A toutes fins utiles :

akenad

Stefjm · Avril 14, 2026, 8:19

Merci beaucoup. Il va falloir que je lise tes « Flash », super intéressant.

Sur mon atlas acheté en avril dernier, systemd-networkd ne tourne pas.

networkctl status
WARNING: systemd-networkd is not running, output will be incomplete.

●   State: n/a
  Address: 192.168.1.7 on eth0
           192.168.1.8 on wlan0
           fe80::cb8:b4ff:fe95:5ffe on eth0
           fe80::cfb5:a5ab:2fd4:5a0e on wlan0
  Gateway: 192.168.1.1 (Icotera A/S) on eth0
           192.168.1.1 (Icotera A/S) on wlan0

ni networking

root@JeedomAtlas:~# systemctl status networking
● networking.service - Raise network interfaces
     Loaded: loaded (/lib/systemd/system/networking.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:interfaces(5)

A priori, c’est bien network manager qui gère.

En tout cas, merci encore.