Auteur Sujet: [Résolu]configuration de systemd-networkd (Lu 8715 fois)

artemus24 · « **Réponse #36 le:** 21 décembre 2023 à 22:06:30 »

@ Basilix : les bases, je vais les acquérir par la pratique et je commence, selon moi, par le plus simple, bidouiller mon ordinateur Debian. Le but final est de remplacer ma Box SFR par un véritable routeur, mais pour l'instant, je ne me suis toujours pas décidé à l'acheter. J'ai besoin de progresser dans la compréhension de la configuration des interfaces avant de me procurer un module optique ONU/SFP (G-PON) et un routeur, bien sûr.

Ma méconnaissance se porte sur "networkd" que je ne fais que découvrir. J'ai un léger vernis en réseau qui date d'il y a vingt ans mais aucune pratique jusqu'à présent. Et en plus, aucun rapport avec l'ADSL et encore moins avec la fibre optique. Donc oui, je suis totalement débutant.

Je ne désire pas transformer, au final, mon ordinateur Debian en un routeur, mais juste faire des tests de fonctionnalités pour comprendre comment ca fonctionne. Le véritable travail va se faire quand j'aurai fait l'acquisition de mon routeur soit sous RouterOS (Mikrotik) ou soit sous OpenWrt (Banana Pi BPI-R4) ou un autre.

La grosse difficulté sera de configurer le module optique ONU/SFP (G-PON) quand je l'aura acheté. En février 2024, je pourrai changer d'offre et passer à FIBRE SFR POWER, qui est aussi dans l'architecture G-PON. C'est après ce changement que je vais me procurer ce module optique.

@ Zoc : j'ai cru que ma configuration n'était pas correcte. C'est bizarre que le check sum soit correcte à la réception mais pas à l'émission. Je suppose que sous "systemd-networkd", je ne peux rien faire pour corriger cette anomalie.

Je ne cherche pas à désactiver quoi que ce soit.

@ Rooot : merci mais j'avais complètement oublié ce sujet. J'ai relu tes explications, mais cela ne m'a pas aidé pour autant. Si cela ne fait qu'accélérer la demande, en toute logique, j'aurai dû obtenir un préfixe de la délégation de l'IPv6.

@ Basilix : je ne parlais pas de l'adresse de bouclage "::1/128" mais de l'adresse "2a02:84XX:XXXX:XXXX::1/128" qui se termine par "::1/128". Comme je l'ai dit, mon adresse WAN IPv6 est formée du préfixe de la délégation de l'IPv6 sur 64 bits et du suffixe qui est l'adresse MAC de mon interface enp2s0, aussi sur 64 bits. Je désire remplacer ce suffixe, donc l'adresse MAC de enp2s0, par "::1/128".

Cela n'a aucun rapport avec l'adresse "::1/128" qui un "loopback address IPv6".

Tout ce que je cherche à faire est de ne pas renseigner dans ma configuration le préfixe dans la section "[Address]" mais de récupérer le préfixe de la délégation de l'IPv6 que j'obtiens lors de la connexion et de fixer le suffixe à ma convenance. Le problème est que si ce préfixe vient à changer (c'est déjà arrivé par le passé), je suis obligé d'intervenir dans ma configuration pour le corriger.

Si je fais :

Code: [Sélectionner]

[Address]
Address=2a02:84XX:XXXX:XXXX::1/128

j'obtiens bien cette adresse, mais en plus de celle que j'obtiens de la configuration, celle avec le préfixe et dont le suffixe est l'adresse MAC.

J'ai beau lire la documentation, les explications sont minimalistes, et je suppose qu'elles s'adressent à des personnes ayant une maitrise des réseaux. Et je ne parle pas des exemples sur le net qui datent de Mathusalem et ne sont plus en phase avec la dernière version de BookWorm (version 252 de Networkd).

@ tous : j'aborderai un peu plus tard la suite de ce sujet.

rooot · « **Réponse #37 le:** 22 décembre 2023 à 08:26:08 »

Citation de: artemus24 le 21 décembre 2023 à 22:06:30

@ Rooot : merci mais j'avais complètement oublié ce sujet. J'ai relu tes explications, mais cela ne m'a pas aidé pour autant. Si cela ne fait qu'accélérer la demande, en toute logique, j'aurai dû obtenir un préfixe de la délégation de l'IPv6.

Ben non, puisque le dhcpv6 de SFR ne supporte pas cette méthode d'attribution d'ip, elle est donc ignorée, et tu ne reçois donc pas ton ipv6.
Relis le texte que j'avais mis en image écran.
En vert le fonctionnement "normal" (Solicit/advertise/request) pour l'attribution de l'ipv6.
En rouge le fonctionnement en mode "Rapid Commit". Non supporté par SFR.

rooot · « **Réponse #38 le:** 22 décembre 2023 à 08:37:45 »

je trouve quand meme bizarre que par defaut "RapidCommit=Yes", j'aurai trouvé plus "normal" qu'il soit sur "No" par defaut et qu'on l'active de façon volontaire. Ou a minima si la requete "rapid commit" echoue, que ça bascule sur le protocol standard. Donc un mode "automatique"...

zoc · « **Réponse #39 le:** 22 décembre 2023 à 08:38:45 »

Citation de: artemus24 le 21 décembre 2023 à 22:06:30

je ne peux rien faire pour corriger cette anomalie.

Encore une fois, ce n'est pas une anomalie: La carte réseau prenant en charge le calcul du checksum des paquets qu'elle envoie, le système d'exploitation ne le calcule pas et met 0 à la place. tcpdump se "branche" entre la pile réseau dans le système d'exploitation et le driver de la carte. Donc il voit uniquement le checksum tel qu'il a été écrit par l'OS: donc 0.

En réception il est tout à fait normal que le checksum soit correct puisqu'il a été calculé par la machine émettrice du paquet. Par contre là aussi généralement la carte réseau est capable de le vérifier sans intervention de l'OS...

basilix · « **Réponse #40 le:** 22 décembre 2023 à 11:38:06 »

@artemus24: Vous souhaitez remplacer votre boîtier opérateur. Mais vous n'êtes visiblement pas un amateur éclairé.
Donc, quel est l'intérêt pour nous de vous indiquer comment effectuer différentes opérations ? En procédant pas à pas.
Libre à vous d'expérimenter. Mais là, vous nous demandez quasiment d'assurer une assistance technique.

artemus24 · « **Réponse #41 le:** 22 décembre 2023 à 16:14:45 »

@ Rooot : Je comprends mieux. SFR ne gère pas le "RapidCommit" !
Tu as raison, Rooot, par défaut, le paramètre "RapidCommit" dans "systemd-networkd" aurait dû être à "No" et non à "Yes".

@ Zoc : Merci pour vos explications. Je laisse en l'état puisque cela ne pose aucun problème.

@ Basilix : votre remarque est bizarre. L'intérêt d'un forum est d'aider, non ?

kgersen · « **Réponse #42 le:** 22 décembre 2023 à 18:31:37 »

Citation de: artemus24 le 22 décembre 2023 à 16:14:45

@ Rooot : Je comprends mieux. SFR ne gère pas le "RapidCommit" !
Tu as raison, Rooot, par défaut, le paramètre "RapidCommit" dans "systemd-networkd" aurait dû être à "No" et non à "Yes".

C'est plutôt le serveur DHCPv6 coté SFR qui n'est pas "universel" et ne répond pas du tout si RapidCommit est activé au lieu de répondre normalement (4 échanges) ou d'honorer le rapid-commit (2 échanges). Bon après a leur décharge, il est censé n'y avoir que des box SFR comme clients DHCPv6, box qu'ils contrôlent complètement, donc ils sont libres de ne pas répondre si la demande n'est conforme a leur attente.

artemus24 · « **Réponse #43 le:** 28 décembre 2023 à 06:24:48 »

Je m'essayer maintenant à la configuration de "systemd-networkd" sur le pont (Bridge).
Mon ordinateur Debian est derrière la Box SFR cette fois-ci.

Voici le fichier "31-bridge.netdev" :

Code: [Sélectionner]

[NetDev]
Kind=bridge
Name=br1

Le fichier de liaison "32-ethernet.network" :

Code: [Sélectionner]

[Match]
Name=enp2s0

[Network]
Bridge=br1

Et le fichier "33-bridge.network" :

Code: [Sélectionner]

[DHCPv6]
UseAddress=no

[Network]
Address=10.0.0.1/8

[Network]
Address=2a02:84XX:XXXX:XXXX:1234::1/64

[Network]
DHCP=ipv4

[Match]
Name=br1

[Route]
Destination=10.0.0.1/8
Gateway=192.168.1.1/24

[Route]
Destination=2a02:84XX:XXXX:XXXX:1234::1/64
Gateway=2a02:84XX:XXXX:XXXX::1/64

Mon but est d'attribuer une adresse statique pour l'ipv4 & l'IPv6.
Mais surtout, je ne veux pas voir apparaître les adresses DHCP de ma Box Plus SFR.
Voici le compte-rendu de "br1" :

Code: [Sélectionner]

● 6: br1                                                                       
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /etc/systemd/network/33-bridge.network
                         State: routable (configured)
                  Online state: online                                         
                          Type: bridge
                          Kind: bridge
                        Driver: bridge
              Hardware Address: a2:fe:fa:ec:a2:c5
                           MTU: 1500 (min: 68, max: 65535)
                         QDisc: noqueue
  IPv6 Address Generation Mode: eui64
                 Forward Delay: 15s
                    Hello Time: 2s
                       Max Age: 20s
                   Ageing Time: 5min
                      Priority: 32768
                           STP: no
        Multicast IGMP Version: 2
                          Cost: 2000
                    Port State: disabled
      Number of Queues (Tx/Rx): 1/1
              Auto negotiation: no
                         Speed: 1Gbps
                       Address: 10.0.0.1
                                192.168.1.215 (DHCP4 via 192.168.1.1)
                                2a02:84XX:XXXX:XXXX:1234::1
                                fe80::a0fe:faff:feec:a2c5
                       Gateway: 192.168.1.1
                                fe80::XXXX:XXff:feXX:XXXX
                           DNS: 192.168.1.1
                           NTP: 192.168.1.1
             Activation Policy: up
           Required For Online: yes
               DHCP4 Client ID: IAID:0x7ca0808/DUID
             DHCP6 Client IAID: 0x7ca0808
             DHCP6 Client DUID: DUID-EN/Vendor:0000ab114fbd83174dabee7b0000

déc. 28 05:44:13 Debian systemd-networkd[9151]: br1: Configuring with /etc/systemd/network/33-bridge.network.
déc. 28 05:44:13 Debian systemd-networkd[9151]: br1: DHCPv4 address 192.168.1.215/24, gateway 192.168.1.1 acquired from 192.168.1.1
déc. 28 05:52:48 Debian systemd-networkd[9151]: br1: DHCPv6 lease lost
déc. 28 05:52:48 Debian systemd-networkd[9520]: br1: netdev ready
déc. 28 05:52:48 Debian systemd-networkd[9520]: br1: Link UP
déc. 28 05:52:48 Debian systemd-networkd[9520]: br1: Gained carrier
déc. 28 05:52:48 Debian systemd-networkd[9520]: br1: Gained IPv6LL
déc. 28 05:52:48 Debian systemd-networkd[9520]: br1: netdev exists, using existing without changing its parameters
déc. 28 05:52:48 Debian systemd-networkd[9520]: br1: Configuring with /etc/systemd/network/33-bridge.network.
déc. 28 05:52:48 Debian systemd-networkd[9520]: br1: DHCPv4 address 192.168.1.215/24, gateway 192.168.1.1 acquired from 192.168.1.1

A ma grande surprise, j'ai pu configurer comme je le désirais l'IPv6 :

a) l'attribution de l'adresse IPv6 par le DHCPv6 de ma Box n'apparaît pas dans le compte-rendu et c'est ce que je voulais.

b) j'ai créé une adresse IPv6 statique et je l'ai fait routé sur la passerelle IPv6 de ma Box et ça fonctionne.

c) seul les deux adresses IPv4 & IPv6 statiques apparaissent dans le "ifconfig" :

Code: [Sélectionner]

br1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.1  netmask 255.0.0.0  broadcast 10.255.255.255
        inet6 2a02:84XX:XXXX:XXXX:1234::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::a0fe:faff:feec:a2c5  prefixlen 64  scopeid 0x20<link>
        ether a2:fe:fa:ec:a2:c5  txqueuelen 1000  (Ethernet)
        RX packets 24301  bytes 12003178 (11.4 MiB)
        RX errors 0  dropped 34  overruns 0  frame 0
        TX packets 7646  bytes 1492770 (1.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

d) quand je teste l'IPv6, ça fonctionne aussi :

Code: [Sélectionner]

root~> ping -6 google.fr -I br1
PING google.fr(par10s22-in-x03.1e100.net (2a00:1450:4007:80e::2003)) from 2a02:XXXX:XXXX:XXXX:1234::1 br1: 56 data bytes
64 bytes from par10s42-in-x03.1e100.net (2a00:1450:4007:80e::2003): icmp_seq=1 ttl=114 time=30.3 ms
64 bytes from par10s42-in-x03.1e100.net (2a00:1450:4007:80e::2003): icmp_seq=2 ttl=114 time=30.0 ms
64 bytes from par10s42-in-x03.1e100.net (2a00:1450:4007:80e::2003): icmp_seq=3 ttl=114 time=29.8 ms
64 bytes from par10s42-in-x03.1e100.net (2a00:1450:4007:80e::2003): icmp_seq=4 ttl=114 time=29.2 ms

--- google.fr ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 29.150/29.790/30.271/0.411 ms

Comme on peut le constater dans le "ping", le flux passe bien par mon adresse IPv6 et c'est ce que je voulais. Jusque là tout va bien.

J'essaye de faire la même chose pour l'IPv4 et je n'y arrive pas.
e) dans le compte-rendu du pont "br1", j'ai l'adresse "192.168.1.215" qui apparaît.
C'est le DHCPv4 de ma Box SFR qui me l'a attribuée. Va savoir pourquoi ?
Je n'en veux pas et je ne suis pas arrivé à la faire disparaître.

f) si je mets "DHCP=No", je n'ai pas cette adresse IPv4 qui apparaît dans le compte-rendu de "br1".
Sauf que le ping en IPv4 ne fonctionne plus.
A moins de me tromper, il me semble que j'ai quand même besoin de mettre "DHCP=ipv4", sinon ça ne fonctionne pas.

g) Je ne sais pas pourquoi, cette adresse "192.168.1.215" est utilisée par le routage

Pourtant, j'ai bien précisé que la passerelle est "192.168.1.1" dans la configuration.
Je me suis servi de ce lien pour configurer mon pont.

h) Si je teste par le ping, ça fonctionne :

Code: [Sélectionner]

root~> ping -4 google.fr -I br1
PING  (216.58.214.163) from 192.168.1.215 br1: 56(84) bytes of data.
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=1 ttl=117 time=29.0 ms
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=2 ttl=117 time=29.0 ms
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=3 ttl=117 time=28.3 ms
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=4 ttl=117 time=28.7 ms

---  ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 28.266/28.731/29.029/0.303 ms

Et comme on peut le voir dans le "from", l'adresse "192.168.1.215" apparaît.
Ce qui est bizarre, cette adresse n'apparaît pas dans l'ifconfig.

i) qu'à cela ne tienne. Je l'a supprime et plus rien ne fonctionne en IPv4 :

Code: [Sélectionner]

root~> ip addr del 192.168.1.215/24 dev br1
root> ping -4 google.fr -I br1
ping: google.fr: Nom ou service inconnu
root~>

j) j'aimerai faire en sorte que l'adresse IPv4 fournie par le DHCPv4 n'apparaisse pas dans le compte-rendu du pont "br1", à l'identique de l'IPv6.
Et bien sûr, avoir le routage de l'adresse "10.0.0.1" via la passerelle "192.168.1.1" de ma Box SFR opérationelle.

Qu'est-ce que j'ai oublié ou mal fait ?

@+

artemus24 · « **Réponse #44 le:** 28 décembre 2023 à 08:09:57 »

J'ai trouvé cette solution qui fonctionne bien :

Code: [Sélectionner]

DHCPv6]
UseAddress=No

[Match]
Name=br1

[Network]
Address=192.168.1.33/24
DNS=192.168.1.1
Gateway=192.168.1.1

[Network]
Address=2a02:84XX:XXXX:XXXX:1234::1/64
DNS=2a02:84XX:XXXX:XXXX::1
Gateway=2a02:84XX:XXXX:XXXX::1

L'adresse IPv4 du DHCPv4 de la Box SFR n'apparaît plus, et c'est ce que je voulais.
Sauf que je ne désirais pas utiliser "192.168.1.x" mais plutôt "10.x.y.z".

L'adresse IPv6 fonctionne mais je suis quand même obligé de faire "UseAddress=No" sinon l'adresse IPv6 du DHCPv6 apparaît, ce que je ne veux pas.

Voici le test qui le prouve :

Code: [Sélectionner]

root~> ping -4 google.fr -I br1
PING  (216.58.214.163) from 192.168.1.33 br1: 56(84) bytes of data.
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=1 ttl=117 time=28.0 ms
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=2 ttl=117 time=29.4 ms
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=3 ttl=117 time=28.7 ms
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=4 ttl=117 time=29.0 ms

---  ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 27.990/28.748/29.354/0.502 ms
root~> ping -6 google.fr -I br1
PING google.fr(par10s42-in-x03.1e100.net (2a00:1450:4007:80e::2003)) from 2a02:84XX:XXXX:XXXX:1234::1 br1: 56 data bytes
64 bytes from par10s42-in-x03.1e100.net (2a00:1450:4007:80e::2003): icmp_seq=1 ttl=114 time=28.7 ms
64 bytes from par10s42-in-x03.1e100.net (2a00:1450:4007:80e::2003): icmp_seq=2 ttl=114 time=29.4 ms
64 bytes from par10s42-in-x03.1e100.net (2a00:1450:4007:80e::2003): icmp_seq=3 ttl=114 time=28.8 ms
64 bytes from par10s42-in-x03.1e100.net (2a00:1450:4007:80e::2003): icmp_seq=4 ttl=114 time=28.9 ms

--- google.fr ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 28.661/28.940/29.395/0.274 ms
root~>

Comme on peut le voir, les adresses du "from" sont bien celle des adresses IP statique que j'ai déclaré dans ma configuration.

Comment utiliser l'adresse de type "10.x.y.z" et avoir internet bien sûr ?
Pourquoi ce type d'adresse ?
Car cela me permet d'avoir plus d'adresses à gérer que seulement les 256 de celle de la Box SFR.

Même question pour une adresse IPv6 autre que celle commençant par "2a02:84.." ?

@+

kgersen · « **Réponse #45 le:** 28 décembre 2023 à 23:51:11 »

ca devient tres confus tout ca...

tu cherche a utiliser systemd-networkd pour remplacer la box ou juste pour configurer une machine derriere la box ?

Citation de: artemus24 le 28 décembre 2023 à 08:09:57

Comment utiliser l'adresse de type "10.x.y.z" et avoir internet bien sûr ?
Pourquoi ce type d'adresse ?
Car cela me permet d'avoir plus d'adresses à gérer que seulement les 256 de celle de la Box SFR.

Même question pour une adresse IPv6 autre que celle commençant par "2a02:84.." ?

mon avis: ces 3 dernières questions montrent de grosses lacunes en notions de base qui sont a apprendre avant même d'aborder systemd-networkd.

artemus24 · « **Réponse #46 le:** 29 décembre 2023 à 02:37:05 »

Citation de: Kgersen

tu cherche à utiliser systemd-networkd pour remplacer la box ou juste pour configurer une machine derrière la box ?

Je suis en train d'apprendre à configurer "systemd-networkd" et de ce fait, j'y vais progressivement avant d'obtenir ma configuration définitive.
J'ai commencé par ce qui me semble le plus difficile, avoir une connexion internet en mettant mon Debian derrière l'ONT-SFU-v3 de SFR et ça fonctionne.

Je fais des exercices en mettant mon Debian derrière la Box SFR :
--> DHCP
--> adresses IP Statiques
--> Bridge avec DHCP
--> Bridge avec adresses IP Statiques.
Actuellement, ces quatre exercices fonctionnent.

Citation de: Kgersen

mon avis: ces 3 dernières questions montrent de grosses lacunes en notions de base qui sont a apprendre avant même d'aborder systemd-networkd.

Je suis tout à fait conscient d'avoir de grosses lacunes mais comme dit l'adage, c'est en forgeant que l'on devient forgeron.
Si je n'avais pas des lacunes dans le domaine des réseaux, je ne me serai jamais inscrit dans ce forum.

Je suis membre du forum "Developpez" et il n'y a plus personne dans la section réseau pour répondre aux questions.

Pour revenir aux adresses IP statiques du Bridge, je suppose que je ne peux pas mettre n'importe quelles adresses IP.
Comme ma Box SFR attribue des adresses IPv4 de type "192.168.1.x" et pour la délégation du préfixe IPv6 "2a02:84XX:XXXX:XXXX", dois je obligatoirement utiliser ces adresses ?
Je suppose que oui puisque d'une part le teste qui fonctionne utilise ces adresses et d'autre part je suis dans un bridge.

kgersen · « **Réponse #47 le:** 29 décembre 2023 à 17:57:03 »

Citation de: artemus24 le 29 décembre 2023 à 02:37:05

--> DHCP
--> adresses IP Statiques
--> Bridge avec DHCP
--> Bridge avec adresses IP Statiques.
Actuellement, ces quatre exercices fonctionnent.

C'est 'bridge' qui est un peu confus la. on doit pas avoir la même définition. qu’appelle tu un bridge ? quelle serait sa finalité ?

Un bridge est un concept de niveau 2 donc qui ne concerne pas vraiment IP (niveau 3). sauf si on fait du pseudo-brigding (arp proxy ou ndp proxy par exemple).