Distribution EOLE

Bonjour,

après plusieurs tests, je suis arrivé à reproduire ce message d'erreur MAIS avec une configuration un peu bancale qui ne semble pas acceptable pour netplan.
En partant de la configuration de base suivante :
eth0:
- 192.168.0.11/24
eth1:
- 172.30.101.0/24
route par défaut via 192.168.0.1 (donc via eth0)

1. Si je rajoute une route statique sur eth1 192.168.55.0/24 via 192.168.55.1 -> erreur
2. Si je rajoute une route statique sur eth1 192.168.55.0/24 via 172.30.101.204 -> OK

Malheureusement, netplan et systemd-netword sont avares en logs. Néanmoins, je suppose que le problème vient de l'accessibilité de la gateway. En effet, dans mon exemple, la gw 192.168.55.1 n'est disponible que via l'interface eth0. Donc, je ne peux pas ajouter de route sur eth1 avec pour gateway une machine inatteignable sur cette interface.

Pouvez-vous vérifier la configuration de votre réseau svp ? Si le problème ne vient pas de votre configuration, pourriez-vous m'envoyer votre config.eol sans données sensibles (avec eole@ac-dijon.fr en copie) svp ?

J'apporte des précisions supplémentaires par rapport à la demande initiale. Le serveur Sphynx a fini par se reconfigurer correctement et les messages d'erreur concernant les services netplan ont disparus. Cependant le besoin initial concernant l'ajout d'une route statique n'est pas satisfait. Actuellement il existe des routes statiques telles que les suivantes:

Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 192.168.4.6 0.0.0.0 UG 0 0 0 ens160
172.16.0.0 192.168.4.6 255.248.0.0 UG 0 0 0 ens160
172.19.0.0 192.168.9.126 255.255.252.0 UG 100 0 0 ens192
172.19.16.0 192.168.9.126 255.255.252.0 UG 100 0 0 ens192
172.19.24.0 192.168.9.126 255.255.252.0 UG 100 0 0 ens192
172.19.68.0 192.168.9.126 255.255.252.0 UG 100 0 0 ens192
172.19.116.0 192.168.9.126 255.255.252.0 UG 100 0 0 ens192
172.19.124.0 192.168.9.126 255.255.252.0 UG 100 0 0 ens192
172.19.144.0 192.168.9.126 255.255.252.0 UG 100 0 0 ens192
172.19.200.0 192.168.9.126 255.255.252.0 UG 0 0 0 ens192
172.19.200.0 192.168.9.126 255.255.252.0 UG 100 0 0 ens192
172.19.220.0 192.168.9.126 255.255.252.0 UG 100 0 0 ens192
172.23.254.160 192.168.9.126 255.255.255.224 UG 100 0 0 ens192
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 ens160
192.168.9.124 0.0.0.0 255.255.255.252 U 0 0 0 ens192

Or si j'essaie d'ajouter une route supplémentaire j'obtiens une erreur:

root@sphynx-adriatic-cd45:~# route add -net 172.19.156.0 netmask 255.255.252.0 gw 192.168.9.126 dev ens192
SIOCADDRT: Le réseau n'est pas accessible

Cette route est similaire aux autres déjà présentes donc je ne comprends pas pourquoi elle est indiquée inaccessible.
Et si je tente d'ajouter une route déjà présente j'obtiens une autre erreur:

root@sphynx-adriatic-cd45:~# ip route add 172.19.24.0/22 via 192.168.9.126 dev ens192
Error: Nexthop has invalid gateway.

Dans vos routes, je vois une route vers 172.16.0.0/13. Si je ne me trompe pas, les adresses utilisables dans ce réseau vont de 172.16.0.1 à 172.23.255.254 et donc recouvrent quasiment toutes les autres routes. Je ne la vois pas dans votre config.eol.
D'où vient cette route ? Est-il possible de l'enlever pour voir si ce n'est pas la source des problèmes ?

La route 172.16.0.0/13 n'est pas dans le genconfig car il ne s'agit pas d'une route statique. Cette route est configurée par la mise en place de tunnels vers adriatic. Actuellement il y a 3 tunnels pointant vers ce réseau:
172.23.254.160/27
192.168.9.124/27
172.19.0.0/16

Est-ce que vous pourriez me transmettre le résultat de la commande :

networkctl status ens192

root@sphynx-adriatic-cd45:~# networkctl status ens192
● 3: ens192
Link File: /usr/lib/systemd/network/99-default.link
Network File: /run/systemd/network/10-netplan-ens192.network
Type: ether
State: routable (configured)
Online state: online
Alternative Names: enp11s0
Path: pci-0000:0b:00.0
Driver: vmxnet3
Vendor: VMware
Model: VMXNET3 Ethernet Controller
HW Address: 00:50:56:81:ec:d5 (VMware, Inc.)
MTU: 1500 (min: 60, max: 9000)
QDisc: mq
IPv6 Address Generation Mode: none
Queue Length (Tx/Rx): 2/2
Auto negotiation: no
Speed: 10Gbps
Duplex: full
Port: tp
Address: 192.168.9.125
Activation Policy: up
Required For Online: yes

mai 06 10:35:19 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Re-configuring with /run/systemd/network/10-netplan-ens192.network
mai 06 10:35:19 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Could not drop route, ignoring: Invalid prefix for given prefix length. Invalid argument
mai 06 10:35:19 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Could not set route: Invalid prefix for given prefix length. Invalid argument
mai 06 10:35:19 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Failed
mai 09 07:00:12 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Link DOWN
mai 09 07:00:12 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Lost carrier
mai 09 07:00:15 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Re-configuring with /run/systemd/network/10-netplan-ens192.network
mai 09 07:00:15 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Could not drop route, ignoring: Invalid prefix for given prefix length. Invalid argument
mai 09 07:00:15 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Link UP
mai 09 07:00:16 sphynx-adriatic-cd45 systemd-networkd³⁵⁹: ens192: Gained carrier

Bonjour,

Pourrais-je avoir votre /etc/ipsec.conf svp ? Par mail, comme pour le config.eol.

Bonjour,

Je n'arrive pas à reproduire le problème. Sans un accès direct au serveur, difficile de diagnostiquer l'erreur.
Cependant, je constate une petite différence entre ce que vous me dites et ce qui est inscrit dans les fichiers de conf : ce n'est pas 192.168.9.124/27 mais 192.168.9.124/30 qui pointe vers Adriatic
Sauf erreur, je constate aussi 2 réseaux recouvrants dans ipsec.conf (déclarés via arv) :
- 172.19.192.0/22 -> 172.23.254.192/26
- 172.19.0.0/16 -> 172.16.0.0/13
Par exemple, quelle route devrait prendre 172.19.195.254 vers 172.23.254.254 ?
Pourriez-vous vérifier que la configuration écrite dans arv correspond bien à ce que vous avez dans /etc/ipsec.conf ?
Et pourriez-vous essayer de corriger ces réseaux recouvrants ? Systemd-networkd a changé sa manière de détecter les réseaux recouvrants il n'y a pas si longtemps, c'est peut-être lié.