Discussion :

[Artemus24]

Salut à tous.

Je cherche de l'aide pour configurer le service "systemd-networkd".

Merci.
@+

[Artemus24]

J'ai branché mon ONT-SFU-v3 de SFR directement sur mon ordinateur Debian.
Je n'utilise pas la Box SFR car le but est justement de s'en passer.

J'ai pu enfin avoir l'IPv4 WAN sur mon Debian. Voici le fichier de configuration que j'ai utilisé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[Match]
Name=enp2s0

[Link]
MACAddress=XX:XX:XX:XX:XX:XX

[Network]
DHCP=yes
DNS=109.0.66.10 109.0.66.20

[DHCPv4]
ClientIdentifier=mac
RouteMetric=10
UseDNS=yes
UseDomains=no
UseGateway=yes
UseHostname=no
VendorClassIdentifier=neufbox_bypass

Le XX:XX:XX:XX:XX:XX est l'adresse MAC de ma Box SFR.
Si l'on ne précise pas le VendorClassIdentifier, tel que je l'ai fait, la connexion ne se fait pas.
En fait, il faut juste le début "neufbox".

Pour tester l'internet, il faut faire "ping 8.8.8.8".
A priori, ça fonctionne, sauf que j'utilisais sous cette forme "ping google.fr" et là, ça ne fonctionnait pas.
J'avais oublié de configurer le fichier "/etc/resolv.conf" afin d'introduire les adresses DNS de SFR.

Maintenant, le plus difficile est de passer à l'IPv6, entre autre la délégation de préfixe IPv6.
Un peu d'aide sera la bienvenue.

[boboss123]

Salut,

Je ne connais pas systemd-networkd mais peut-être la première chose à faire est de faire une capture des paquets entre la Box SFR et l'ONT à propos de la transaction qui négocie la délégation de préfixe IPv6 (si la transaction n'est pas cryptée... je ne connais pas le protocole utilisé).

Comme ça, après tu pourras la partager sur un forum dédié à systemd-networkd (ça doit exister) pour leur demander comment avoir le même comportement.

[Artemus24]

Salut Boboss123.

Le service "Systemd-Networkd" me semble bien plus complet que "NetworkManager" ainsi que "networking".
"dhcpcd" n'est plus opérationnel dans la version DebianBookWorm.

J'utilise ce service en remplacement de "dhclient" qui est obsolète depuis le 5 octobre 2022 (le dernière mise à jour officielle).

Pour configurer le service "Systemd-Networkd", j'utilise ce que j'ai fait avec "dhclient".
Celui-ci est opérationnel et me permet d'avoir les adresses IPv4 & IPv6 WAN.

Pour la configuration de l'IPv4, ce fut disons assez facile.
Mais pour la délégation de préfixe IPv6, je n'arrive pas à trouver la bonne configuration.
Entre temps, il y a eu une évolution de ce service, où avant, il était nécessaire de créer une seconde interface.
Alors que maintenant cela n'est plus nécessaire et tout se fait dans le fichier ".network".
Sauf que je ne trouve aucun exemple qui fonctionne chez moi.
J'ai dû mettre à jour mon Debian afin de passer de BullsEye à BookWorm pour avoir la dernière version de systemd qui est la 252.

J'ai une autre solution pour avoir l'adresse IPv6 WAN est d'utiliser celle d'Hurricane Electric puisque j'ai la connexion IPv4 qui fonctionne.
Mais ce n'est pas ce que je recherche et j'aimerai tout faire avec le service "Systemd-Networkd".

Je n'ai pas besoin de faire des captures car je connais déjà le paramétrage à appliquer puisque je l'ai fait avec "dhclient".
C'est la configuration du "Systemd-Networkd" pour la délégation de préfixe IPv6 dans sa nouvelle version qui me pose des problèmes.

[Artemus24]

Je vous communique mon fichier "/etc/systemd/network/30-sfr.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
[Match]
Name=enp2s0

[Link]
MACAddress=XX:XX:XX:XX:XX:XX
RequiredForOnline=yes

[Network]
DHCP=yes
DHCPv6PrefixDelegation=yes
DNS=109.0.66.10 109.0.66.20 2a02:8400::0 2a02:8400::1
IPForward=yes
IPv6AcceptRA=yes
LinkLocalAddressing=ipv6

[DHCPPrefixDelegation]
UplinkInterface=:self
SubnetId=0x1
Announce=no

[DHCPv4]
ClientIdentifier=mac
RouteMetric=10
UseDNS=yes
UseDomains=no
UseGateway=yes
UseHostname=no
UseNTP=no
VendorClassIdentifier=neufbox_bypass

[DHCPv6]
RouteMetric=10
SendOption=16:string:\x00\x00\xA0\x0C\x00\x0E\x6E\x65\x75\x66\x62\x6F\x78\x5F\x62\x79\x70\x61\x73\x73
UseDNS=yes
UseDomains=no
UseHostname=no
UseNTP=no
WithoutRA=solicit

[IPv6AcceptRA]
DHCPv6Client=always
UseDNS=yes
UseDomains=no

Avec cette configuration, j'obtiens bien l'adresse IPv4 WAN de SFR.
Par contre, je n'obtiens pas l'adresse IPv6 Wan de SFR, ce que je cherche à faire.
Voici les différents comptes-rendus du service "systemd-network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
root~> networkctl
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp2s0 ether    routable    configured
  3 wlp4s0 wlan     off         unmanaged

3 links listed.

La suite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
root~> networkctl status
●        State: routable
  Online state: online
       Address: xxx.xxx.xxx.xxx on enp2s0
                fe80::XXXX:XXff:feXX:XXXX on enp2s0
       Gateway: xxx.xxx.xxx.1 on enp2s0
           DNS: 109.0.66.10
                109.0.66.20
                2a02:8400::
                2a02:8400::1

déc. 15 18:43:28 Debian systemd-networkd[6292]: enp2s0: Gained carrier
déc. 15 18:43:28 Debian systemd-networkd[6292]: lo: Link UP
déc. 15 18:43:28 Debian systemd-networkd[6292]: lo: Gained carrier
déc. 15 18:43:28 Debian systemd-networkd[6292]: enp2s0: Gained IPv6LL
déc. 15 18:43:28 Debian systemd-networkd[6292]: Enumeration completed
déc. 15 18:43:28 Debian systemd[1]: Started systemd-networkd.service - Network Configuration.
déc. 15 18:43:28 Debian systemd-networkd[6292]: enp2s0: Configuring with /etc/systemd/network/30-sfr.network.
déc. 15 18:43:28 Debian systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Configured...
déc. 15 18:43:29 Debian systemd-networkd[6292]: enp2s0: DHCPv4 address xxx.xxx.xxx.xxx/26, gateway xxx.xxx.xxx.1 acquired from 84.103.237.164
déc. 15 18:43:29 Debian systemd[1]: Finished systemd-networkd-wait-online.service - Wait for Network to be Configured.

Et pour finir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
root~> networkctl status enp2s0
● 2: enp2s0                     
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /etc/systemd/network/30-sfr.network
                         State: routable (configured)
                  Online state: online
                          Type: ether
                          Path: pci-0000:02:00.0
                        Driver: r8169
                        Vendor: Realtek Semiconductor Co., Ltd.
                         Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
              Hardware Address: xx:xx:xx:xx:xx:xx (SFR)
    Permanent Hardware Address: yy:yy:yy:yy:yy:yy (ASUSTek COMPUTER INC.)
                           MTU: 1500 (min: 68, max: 9194)
                         QDisc: fq_codel
  IPv6 Address Generation Mode: eui64
      Number of Queues (Tx/Rx): 1/1
              Auto negotiation: yes
                         Speed: 1Gbps
                        Duplex: full
                          Port: tp
                       Address: xxx.xxx.xxx.xxx (DHCP4 via 84.103.237.164)
                                fe80::xxxx:xxff:fexx:xxxx
                       Gateway: xxx.xxx.xxx.1
                           DNS: 109.0.66.10
                                109.0.66.20
                                2a02:8400::
                                2a02:8400::1
             Activation Policy: up
           Required For Online: yes
               DHCP4 Client ID: xx:xx:xx:xx:xx:xx
             DHCP6 Client IAID: 0x5de26c15
             DHCP6 Client DUID: DUID-EN/Vendor:0000ab114fbd83174dabee7b0000

déc. 15 18:31:06 Debian systemd-networkd[5513]: enp2s0: Gained carrier
déc. 15 18:31:06 Debian systemd-networkd[5513]: enp2s0: Gained IPv6LL
déc. 15 18:31:06 Debian systemd-networkd[5513]: enp2s0: Configuring with /etc/systemd/network/30-sfr.network.
déc. 15 18:31:06 Debian systemd-networkd[5513]: enp2s0: DHCPv4 address xxx.xxx.xxx.xxx/26, gateway xxx.xxx.xxxx.1 acquired from 84.103.237.164
déc. 15 18:43:28 Debian systemd-networkd[5513]: enp2s0: DHCPv6 lease lost
déc. 15 18:43:28 Debian systemd-networkd[6292]: enp2s0: Link UP
déc. 15 18:43:28 Debian systemd-networkd[6292]: enp2s0: Gained carrier
déc. 15 18:43:28 Debian systemd-networkd[6292]: enp2s0: Gained IPv6LL
déc. 15 18:43:28 Debian systemd-networkd[6292]: enp2s0: Configuring with /etc/systemd/network/30-sfr.network.
déc. 15 18:43:29 Debian systemd-networkd[6292]: enp2s0: DHCPv4 address xxx.xxx.xxx.xxx/26, gateway xxx.xxx.xxx.1 acquired from 84.103.237.164

J'ai masqué l'adresse MAC de ma Box SFR, ainsi que celle de mon ordinateur Asus. J'ai aussi masqué mon adresse IPv4 WAN.
Je me suis, bien sûr, inspiré de ce que j'ai pu trouvé sur le net pour réaliser cette configuration.

J'ai mis en rouge ce qui concerne l'IPv6.

Il doit manquer quelque chose pour obtenir la délégation du préfixe IPv6, mais je ne vois pas quoi.

[Artemus24]

J'ai enfin pu obtenir le préfixe de délégation de l'IPv6 sous le service "systemd-networkd".
Voici mon fichier de configuration à placer dans le répertoire "/etc/systemd/network". Je l'ai baptisé "30-sfr.network".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
[Match]
Name=enp2s0

[DHCPPrefixDelegation]
Announce=No
SubnetId=0x1
UplinkInterface=:self

[DHCPv4]
ClientIdentifier=mac
RouteMetric=10
SendHostname=No
UseHostname=No
VendorClassIdentifier=neufbox_bypass

[DHCPv6]
DUIDType=link-layer-time
PrefixDelegationHint=::/56
RapidCommit=No
RouteMetric=10
UseHostname=No
SendOption=16:string:\x00\x00\xa0\x0c\x00\x0e\x6e\x65\x75\x66\x62\x6f\x78\x5f\x62\x79\x70\x61\x73\x73
UseDelegatedPrefix=Yes
UseHostname=No
WithoutRA=solicit

[Link]
MACAddress=XX:XX:XX:XX:XX:XX
RequiredForOnline=Yes

[Network]
DHCP=Yes
DHCPPrefixDelegation=Yes
DNS=109.0.66.10
DNS=109.0.66.20
DNS=2a02:8400::0
DNS=2a02:8400::1
IPv6AcceptRA=Yes
IPv6PrivacyExtensions=No
LinkLocalAddressing=ipv6

Les X désignes l'adresse MAC de ma Box SFR. A vous de mettre l'adresse MAC de votre Box SFR.
La solution se trouvait dans le paramètre "RapidCommit" qui doit être mis à "No".
Je ne sais pas pourquoi mais par défaut il est à "Yes".
Le problème est que SFR n'a pas implémenté le RapidCommit dans le serveur DHCPv6.
D'où le fait que je n'arrivais pas à obtenir le préfixe de délégation de l'IPv6.

Maintenant, je cherche à utiliser une interface LAN à partir de l'un de mes câbles USB/RJ45.
Cette interface LAN doit avoir l'internet que je vais devoir récupérer depuis l'interface WAN (mon enp2s0) et être un serveur DHCP.

@+

[Artemus24]

Bonne année, bonne santé, mes meilleurs vœux pour l'année 2024, ainsi qu'à vos proches.

Cette fois-ci, mon Debian est derrière la Box SFR, et j'ai fait un exercice sur les VLAN.
J'ai deux câbles USB/RJ45 qui me permettent d'ajouter des interfaces réseaux. Voici ma configuration :
--> l'interface "enp2s0" sera connectée par un câble éthernet à ma Box SFR. Cela me permet d'avoir l'Internet.
--> je vais créer un pont où je vais définir les adresses IPv4 & IPv6.
--> une interface esclave noté "slv0" où je vais mettre derrière une Raspberry Pi.
--> une interface esclave noté "slv1" où je vais mettre derrière une autre Raspberry Pi.

Dans cette configuration, j'ai quatre ports, qui sont ceux des interfaces suivantes :
--> 1 : pont
--> 2 : slv0
--> 3 : slv1
--> 4 : enp2s0

Le test est de pouvoir accéder à la Raspberry Pi derrière l'interface "slv0" mais pas à celle derrière l'interface "slv1".
Je vérifie cela en faisant un "ssh pi@IP" où l'IP est l'adresse IPv4 de l'une de mes Raspberry PI.
Je vérifie au travers de ma Box SFR que j'ai bien accès à la même IP par un ping.
La non accessibilité de l'interface "slv1" ne doit pas empêcher d'avoir l'internet dans la Raspberry Pi.
Pour cela, je test par un ping les adresses IPv4 & IPv6 fournie par le serveur DHCP pour mes Raspberry Pi, depuis ma Box SFR.

Comme j'ai quatre ports, j'ai quatre VLAN. Voici les fichiers de configurations :

Fichier "06-bridge.link" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[Match]
Name=br1

[Link]
MACAddressPolicy=persistent

Fichier "06-bridge.netdev" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
[NetDev]
Kind=bridge
Name=br1

[Bridge]
DefaultPVID=1
VLANFiltering=yes

Fichier "06-bridge.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[Match]
Name=br1
Type=bridge

[Network]
DHCP=yes

[BridgeVLAN]
EgressUntagged=2
PVID=1
VLAN=2

[BridgeVLAN]
EgressUntagged=4
VLAN=4

Fichier "06-ethernet.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Match]
Name=enp2s0
Type=ether

[Link]
RequiredForOnline=yes

[Network]
Bridge=br1

[BridgeVLAN]
EgressUntagged=1-3
PVID=4
VLAN=1-3

Fichier "06-slave0.link" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[Match]
MACAddress=00:50:b6:b0:24:28

[Link]
Name=slv0

Fichier "06-slave0.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[Match]
Name=slv0

[Network]
Bridge=br1

[BridgeVLAN]
EgressUntagged=1
PVID=2
VLAN=1

[BridgeVLAN]
EgressUntagged=4
VLAN=4

Fichier "06-slave1.link" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[Match]
MACAddress=00:50:b6:fb:a3:10

[Link]
Name=slv1

Fichier "06-slave1.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
[Match]
Name=slv1

[Network]
Bridge=br1

[BridgeVLAN]
EgressUntagged=4
PVID=3
VLAN=4

Je ne sais pas trop si l'on peut simplifier cette configuration.

La configuration des paramètres est la suivante :
--> "PVID" est le numéro du port VLAN. J'en ai quatre noté de 1 à 4 .
--> "VLAN", le numéro est celui du flux VLAN que j'autorise à accéder au port. Il s'agit du flux entrant.
--> "EgressUntagged", le numéro est celui du flux VLAN sortant de l'interface qui ne sera plus marqué en tant que VLAN.

Schématiquement, les flux VLAN sont les suivantes :

Port 1 --> reçoit les VLAN 2 et 4.
Port 2 --> reçoit les VLAN 1 et 4.
Port 3 --> reçoit les VLAN 4.
Port 4 --> reçoit les VLAN 1, 2 et 3.

Le port 2 (interface "slv0") est accessible par la commande "ssh" depuis les adresses IP du pont.
Le port 3 (interface "slv1") n'est pas accessible par la commande "ssh" depuis le pont, puisque le flux VLAN=1 n'est pas autorisé.

Je suppose que je peux simplifier en mettant à la place de "PVID=2", le port 2, c'est-à-dire mettre "PVID=1."
Mais ça me parait bizarre d'attribuer le même port alors que physiquement ce sont deux ports distincts.

@+

[boboss123]

Hello,

Tu peux faire un petit schéma réseau en indiquant dans quel VLAN sont les différents services et l'adressage IP, j'ai du mal à comprendre ?... je ne comprends pas pourquoi l'interface slv0 (Raspberry) a deux VLAN de déclarés.

[Artemus24]

Salut Boboss123.

J'ai eu du mal à comprendre comment fonctionne les VLAN. Il faut raisonner sur l'interface dont le flux est entrant.

Qu'est-ce un VLAN ? Un VLAN est une trame qui est marquée par un identifiant.
Un flux venant de n'importe où, peut-être autorisé ou pas selon son marquage, c'est-à-dire son identifiant VLAN.
Si tu n'utilises pas les VLAN, la totalité du flux entre dans toutes les interfaces.
Tu ne peux pas isoler l'une d'entre elle vis-à-vis des autres.
Le VLAN sert à filtrer ce qui t'intéresse, de ce qui ne t'intéresse pas.
Cela améliore la fluidité du réseau puisque tu prends uniquement ce dont tu as besoin.

Voici le schéma du montage réseau que j'ai testé dans mon Debian :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
*========================+---------------------------+==========*
*                        | Interface:enp2s0 - Port:4 |          *
*                        +--+----+----------------+--+          *
*                           |    |                |             *
*                +----------+    |                |             *
*                |               |                |             *
*   +------------+-----------+   |                |             *
*   | Interface:br1 - Port:1 +   |                |             *
*   +------------+-----------+   |                |             *
*                |               |                |             *
*                |       +-------+                |             *
*                |       |                        |             *
*                |       |                        |             *
*   +------------+-------+----+   +------------- -+---------+   *
*   | Interface:slv0 - Port:2 |   | Interface:slv1 - Port:3 |   *
*===+-------------------------+===+-------------------------+===*

Le cadre extérieur (les * et les =) du schéma symbolise mon ordinateur Debian.
Symboliquement, j'ai trois ports RJ45 (les - du cadre extérieur font une ouverture vers un périphérique).
En fait, j'ai un seul port physique RJ45, le "enp2s0".
Les deux autres sont des prises USB où je branche sur chacun d'elle, un cordon USB/RJ45.
Seul l'interface "br1" n'a pas de port externe. Les | symbolisent le flux.

J'ai quatre flux à gérer, sachant que les trames à l'intérieur sont marqués 1, 2, 3 ou 4.
Comment faire la distinction des VLAN dans ces flux ?
Par la direction prise par le flux d'une interface vers une autre interface.
La trame est marquée par le port d'origine qui l'envoie.
Une trame venant de l'interface "br1" sera marqué "1" et va vers toutes les interfaces.
Pour autoriser un flux entrant marqué à "1", j'utilise le paramètre VLAN=1" dans l'interface.

J'ai encore un doute sur la compréhension du flux sortant.
Si je n'autorise pas la trame entrante à sortir par le "EgressUntagged", et bien, la trame marquée ne sort pas.
Je n'ai pas compris l'utilité de ne pas mettre "EgressUntagged" dans une interface.
Quand est-il des trames non marquée ?
Je dis ça, mais je ne sais pas si c'est la bonne interprétation.

@+

[boboss123]

Ta box SFR ne sort pas de VLAN, non ?... si c'est le cas, ça veut dire probablement que le port 4 ne sort qu'un seul VLAN et qu'il est untagged, non ?

Tous tes équipements sont dans le même sous réseau IP ?... pour passer d'un VLAN à un autre, normalement il faudrait une gateway inter-VLAN il me semble... et donc un sous-réseau IP par VLAN.

ça donnerait ce genre de routes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
slv0 <= VLAN 1 => gateway <= VLAN 4 => enp2s0
slv1 <= VLAN 3 => gateway <= VLAN 4 => enp2s0
br1  <= VLAN 2 => gateway <= VLAN 4 => enp2s0

=> donc un sous-réseau par VLAN. Est-ce le cas, tu vois 4 sous-réseaux dans les routes ?
.. sans ça, je ne vois pas trop comment le processus de routage peut fonctionner.


br1 doit pouvoir communiquer avec slv0 ?

[Artemus24]

Ta box SFR ne sort pas de VLAN, non ?

A ma conaissance, il n'y a pas de VLAN chez SFR. Chez Orange oui. Free et Bouygues, je ne sais pas.

si c'est le cas, ça veut dire probablement que le port 4 ne sort qu'un seul VLAN et qu'il est untagged, non ?

Si j'avais des VLAN entrant dans mon interface "enp2s0", seul ceux numérotés 1, 2 et 3 passeraient, comme c'est indiqué dans "06-ethernet.network".

Tous tes équipements sont dans le même sous réseau IP ?

Oui. Je ne traite dans cet exercice que les adresses IPv4, soit "192.168.1.0/24".

pour passer d'un VLAN à un autre, normalement il faudrait une gateway inter-VLAN il me semble... et donc un sous-réseau IP par VLAN.

Je ne maitrise pas trop encore les VLAN, mais à vrai dire, je ne sais pas répondre à ta question.

br1 doit pouvoir communiquer avec slv0 ?

Le but de l'exercice est d'accéder à la Raspberry Pi qui se trouve derrière l'interface "slv0", mais pas à celle derrière l'interface "slv1".

=> donc un sous-réseau par VLAN.

Il n'y a pas de sous-réseaux. Cela n'a rien à voir avec les tunnels.

Dans un câble éthernet, le flux contient toutes les trames qui sont autorisées à circuler.
A chaque interface (voit cela comme une barrière douanière), on indique les trames qui sont autorisées à passer ou pas.
Dans celles qui sont autorisé à passer, nous avons deux cas :

a) la trame passe au travers de l'interface et continue son chemin. C'est le cas "tagged".
La trame continue son chemin dans le cas d'une enfilade de commutateurs.
Mais dans mon exercice, la sortie de l'interface va vers la Raspberry Pi.

b) la trame doit être traité par la Raspberry Pi. C'est le cas du "untagged"
Pour cela, je dois supprimer le marquage.

C'est ce que je pense, sans avoir la certitude de ce que j'avance.

As tu pu reproduire cette exercice chez toi ?

@+

[boboss123]

systemd-networkd ne fait qu'émuler un switch/routeur.

Donc pour moi, pour passer d'un VLAN à l'autre proprement il faut définir une gateway avec un adressage IP par VLAN et mettre en place des règles de routage pour autoriser ou non le passage d'un sous-réseau à l'autre.



Je pense que la configuration suivante devrait faire ce que tu veux (c'est la même méthodologie que la tienne mais en version simplifiée).

[slv0] EgressUntagged=3 PVID=1 VLAN=1,3 => Fichier "06-slave0.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
[Match]
Name=slv0

[Network]
Bridge=br1

[BridgeVLAN]
EgressUntagged=3
PVID=1
VLAN=1,3

[slv1] EgressUntagged=3 PVID=2 VLAN=2,3 => Fichier "06-slave1.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
[Match]
Name=slv1

[Network]
Bridge=br1

[BridgeVLAN]
EgressUntagged=3
PVID=2
VLAN=2,3

[enp2s0] EgressUntagged=1-2 PVID=3 VLAN=1-3 => Fichier "06-ethernet.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[Match]
Name=enp2s0
Type=ether

[Link]
RequiredForOnline=yes

[Network]
Bridge=br1

[BridgeVLAN]
EgressUntagged=1-2
PVID=3
VLAN=1-3

... ça fonctionne ?... par contre, ce n'est pas propre : je pense que tous les paquets qui entrent sur enp2s0 sont broadcastés sur slv0 et slv1 (peu importe leurs adresses MAC et IP) car selon le sens de transmission les paquets ne transitent pas dans le même VLAN et donc, la table de switching ne peut pas être construite, d'où le broadcast des paquets (à confirmer). Vu que tu n'as que 3 ports ça doit pouvoir fonctionner sans trop de problème mais si tu avais plus de ports, avec le broadcast de paquets ça serait beaucoup plus gênant.
Pour éviter le broadcast, il faudrait fusionner les tables de switch des différents VLAN : certains équipements le font, peut-être que systemd-networkd permet de le faire... mais je pense que l'on sort du cadre d'utilisation normale des VLANs.

[Artemus24]

systemd-networkd ne fait qu'émuler un switch/routeur.

Ce n'est pas un émulateur mais il gère l'aspect réseau dans ton ordinateur. Dans l'exercice, j'ai fait en sorte de gérer un pont et des VLAN.

Donc pour moi, pour passer d'un VLAN à l'autre proprement il faut définir une gateway avec un adressage IP par VLAN et mettre en place des règles de routage pour autoriser ou non le passage d'un sous-réseau à l'autre.

Qu'est-ce que tu entends par : "passer d'un VLAN à un autre" ?
Parles-tu de changer l'identifiant de la trame par un autre identifiant ?
Si c'est de cela dont tu parles, cela n'a aucun intéret de le faire car la trame marqué va de l'émetteur vers le récepteur. Entre, ce n'est que du routage, définie par le paramètre "VLAN" qui va autorise la trame à poursuivre son chemin ou pas. Quand elle arrive dans l'interface de destination, on fait "EgressUntagged" afin de rendre exploitable la trame dans le périphérique où elle sera traitée.

Je pense que la configuration suivante devrait faire ce que tu veux (c'est la même méthodologie que la tienne mais en version simplifiée).

J'ai bien quatre ports (1:br1, 2:slv0, 3:slv1 et 4:enp2s0) que je ne peux pas réduire à trois, sinon mon exercice ne fonctionne pas.
La simplification que j'ai testée, est de n'avoir plus que trois VLAN. Le VLAN N°2 (en rouge) est remplacé par le VLAN N°1.

Je vais adopter cette écriture condensée afin de bien nous comprendre : (interface ; PVID ; VLAN ; EgressUntagged).

Mon exemple se résume à :
--> (br1 ; 1 ; 2,4 ; 1)
--> (slv0 ; 2 ; 1,4 ; 2)
--> (slv1 ; 3 ; 4 ; 3)
--> (enp2s0 ; 4 ; 1,2,3 ; 1,2,3)

Mon exemple simplifié :
--> (br1 ; 1 ; 4 ; 1)
--> (slv0 ; 1 ; 4 ; 1)
--> (slv1 ; 3 ; 4 ; 3)
--> (enps20 ; 4 ; 1,3 ; 1,3)

Ton exemple :
--> (slv0 ; 1 ; 1,3 ; 3)
--> (slv1 ; 2 ; 2,3 ; 3)
--> (enps20 ; 3 ; 1,2,3 ; 1,2)

Dans ton exemple, tu as ôté le port "br1", c'est-à-dire mon Debian. Mon Debian se retrouve sans connexion à internet.

Pour obtenir les adresses IP en provenance du serveur DHCP de ma Box SFR, je dois conserver le flux venant de l'interface "enp2s0". Je l'ai testé. Tu le fais aussi.

Par contre, le "VLAN=3" (en rouge) dans l'interface "enp2s0" ne sert à rien, puisque tu autorises les trames marquées "3" alors que tu es dans le port "3". Il n'existe aucune trame marquée à "3" que tu reçoives.

... ça fonctionne ?...

Ben non.

je pense que tous les paquets qui entrent sur enp2s0 sont broadcastés sur slv0 et slv1 (peu importe leurs adresses MAC et IP) car selon le sens de transmission les paquets ne transitent pas dans le même VLAN et donc, la table de switching ne peut pas être construite, d'où le broadcast des paquets (à confirmer). Vu que tu n'as que 3 ports ça doit pouvoir fonctionner sans trop de problème mais si tu avais plus de ports, avec le broadcast de paquets ça serait beaucoup plus gênant.

Tout dépend de ce que tu entends par brodcastés.
Je pense que le flux entrant est filtré en trois flux sortants, ayant chacun leur identifiant VLAN et à destination des trois interfaces "br1", "slv0" & "slv1." Maintenant, la bonne question est de savoir si un flux à destination de l'IP1 pour le VLAN=1 sera aussi présent vers la destination de l'IP2 pour le VLAN=2. Je pense que non car dans la trame, il y a l'adresse IP de destination qui permet de faire la distinction. Le but des VLAN est de désengorger le trafic en faisant en sorte que la trame ne soit pas diffusée partout, mais là où elle doit se trouver. Il n'y a aucun fitrage dans le LAN à l'inverse du VLAN. De ce fait, il y a bien moins de trames qui circulent dans le réseau.

Si dans "slv0" (ou "slv1"), je n'autorise pas le flux venant de "enp2s0", ma Raspberry PI ne récupère pas les adresses IP venant du serveur DHCP de la Box SFR. J'ai bien un flux venant de "enp2s0", marquée selon le VLAN et à destination vers l'interface "br1", "slv0 et "slv1". Je devrais vérifier en faisant une capture du flux entrant sur chaque Raspberry Pi pour voir si je reçois ce qui m'est destiné.

Je reconnais que c'est basique comme exercice, mais c'est un peu plus compliqué à mettre en oeuvre que le pont. La différence se fait dans l'ajout des sections "[Bridge]" et "[BridgeVLAN]".

Un lien fort utile pour comprendre comment fonctionne les VLAN.
J'utilise ici, les VLAN basés sur les ports.

Dans mon réseau local, je vais essayé de mettre en place les VLAN, sachant que je raisonne beaucoup sur ce triplé (adresse MAC ; adresse IP ; nom d'hôte).

Mon problème de compréhension est comment attribuer un identifiant VLAN à un flux en particulier.
Comment reconnaitre le flux Multicast pour l'IPTV ?
Comment reconnaitre le flux OLT, pour la télé sur ordinateur ?
Comment reconnaitre le flux VOIP/SIP pour le téléphone ?
Je ne veux pas que la domotique se retrouve sur le même réseau que l'internet, question de sécurité.
Je n'en ai aucune idée pour l'instant. Mais quand ta trame VLAN est bien identifiée, il est facile de la diriger là où tu veux.

As tu la possibilité de faire des tests ?

@+

[Artemus24]

Comme j'ai terminé mon exercice sur les VLAN, je passe maintenant au DHCP.

Mon Debian est branché derrière l'ONT-SFU-v3 de SFR. J'ai bypassé la Box SFR.
J'ai configuré deux interfaces dans mon Debian, l'une WAN (enp2s0). Voici le fichier "02-wab.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
[Address]
Address=2a02:84XX:XXXX:XXXX::1/64
Scope=link

[DHCPPrefixDelegation]
Announce=no
SubnetId=1
UplinkInterface=:self

[DHCPv4]
ClientIdentifier=mac
RouteMetric=10
UseHostname=no
VendorClassIdentifier=neufbox_bypass

[DHCPv6]
DUIDType=link-layer-time
PrefixDelegationHint=::/56
RapidCommit=no
RouteMetric=10
SendOption=16:string:\x00\x00\xa0\x0c\x00\x0e\x6e\x65\x75\x66\x62\x6f\x78\x5f\x62\x79\x70\x61\x73\x73
UseDelegatedPrefix=yes
UseHostname=no
WithoutRA=solicit

[Link]
MACAddress=CC:2D:1B:F0:27:78
Multicast=yes
RequiredForOnline=yes

[Match]
Name=enp2s0

[Network]
DHCP=yes
DHCPPrefixDelegation=yes
DNS=109.0.66.10
DNS=109.0.66.20
DNS=2a02:8400::0
DNS=2a02:8400::1
IPForward=yes
IPMasquerade=both
IPv6AcceptRA=yes
IPv6PrivacyExtensions=no
LinkLocalAddressing=ipv6
MulticastDNS=yes

et l'autre LAN (lan0). Voici le fichier "02-lan.link" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
[Match]
MACAddress=00:50:b6:b0:24:28

[Link]
Multicast=yes
Name=lan0

et voici le fichier "02-lan.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
[Address]
Address=192.168.1.1/24
Broadcast=192.168.1.255

[DHCPPrefixDelegation]
Announce=yes
SubnetId=1
UplinkInterface=enp2s0

[DHCPServer]
PoolOffset=2
PoolSize=100
EmitDNS=yes
DNS=8.8.4.4
DNS=8.8.8.8
DefaultLeaseTimeSec=600
MaxLeaseTimeSec=7200

[Match]
Name=lan0

[Network]
DHCP=yes
DHCPPrefixDelegation=yes
DHCPServer=yes
#IPForward=yes
IPMasquerade=both
IPv6AcceptRA=no
IPv6SendRA=yes
LLMNR=yes
MulticastDNS=yes

Voici les problèmes que je rencontre :

a) je n'arrive pas à supprimer l'adresse IPv6 SLAAC qui m'est attribué.
C'est l'adresse IPv6 formée du préfixe IPv6 suivie de l'adresse MAC de mon interface enp2s0.
Systématiquement elle réapparaît, même en mettant ce paramétrage dans le répertoire "/etc/sysctl.d" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
# activate routing
net.ipv6.conf.all.forwarding=1
# online ipv6: disable slaac but allow default route
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_ra=2

Voici ce que j'obtiens en testant "sysctl" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
root~> sysctl --system
* Applique /etc/sysctl.d/10-ipv6-networking.conf …
* Applique /usr/lib/sysctl.d/30-tracker.conf …
* Applique /usr/lib/sysctl.d/50-bubblewrap.conf …
* Applique /usr/lib/sysctl.d/50-pid-max.conf …
* Applique /usr/lib/sysctl.d/99-protect-links.conf …
* Applique /etc/sysctl.d/99-sysctl.conf …
* Applique /etc/sysctl.conf …
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 2
fs.inotify.max_user_watches = 65536
kernel.unprivileged_userns_clone = 1
kernel.pid_max = 4194304
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
root~>

b) je n'ai pas accès à l'IPv6 dans ma raspberry Pi. J'ai trois niveaux d'interfaces :

--> l'interface WAN (enp2s0) dans mon Debian.
Elle me permet d'avoir mes adresses IPv4 & IPv6 WAN. Si je teste par "ping -4 google.fr -I enp2s0" ainsi que par "ping -4 google.fr -I enp2s0", ça fonctionne donc tout va bien.

--> l'interface LAN (lan0) dans mon Debian.
Cette interface permet d'avoir le DHCP IPv4 sur la Raspberry PI qui est branchée derrière.
J'ai bien les adresses IPv4 & IPv6 qui m'ont été attribué sur cette interface.
Si je fais les ping pour tester l'internet de cette interface "lan0", ça ne fonctionne pas.
Si je fais les ping sur les adresses IPv4 & iPv6 de cette même interface, ça fonctionne.
A vrai dire, comme je suis sous Debian, j'ai déjà l'internet par l'interface WAN (enp2s0).
Mais je ne sais pas trop si mon problème vient de là.

--> je suis dans ma Raspberry Pi, et ma connexion se fait par l'interface filaire "end0".
Aucun problème avec "ping -4 google.fr -I end0" puisque j'ai pu entrer dans ma raspberry par la commande "ssh", donc l'IPv4 fonctionne.
Par contre, le "ping -6 google.fr -I end0" ne fonctionne pas en m'indiquant que l'adresse est injoignable.
Si je fais ping de l'adresse IPv6 de l'interface "end0", ça fonctionne.
Si je fais ping de l'adresse IPv6 de l'interface LAN "lan0", celle juste au dessus de ma Raspberry Pi, ça fonctionne aussi.
Mais si je fais le ping de l'adresse IPv6 de l'interface WAN "enp2s0", ça ne fonctionne plus.
Si je fais "traceroute -6 google.fr", la recherche s'arrête sur l'adresse IPv6 de l'interface "lan0" mais ne remonte pas à celle de l'interface WAN.
J'ai pourtant test le "IPForwarding" ainsi que le "IPMasquerade" dans mes interfaces, mais rien n'y fait.
Ce qui est bizarre, j'obtiens bien les adresses IPv6 dans ma Raspberry Pi en provenance du serveur DHCP.

c) j'ai un problème de compréhension sur des ralentissements dans l'exécution des commandes "ping" "route" voire aussi "traceroute".
Cela n'impacte pas le résultat de la commande qui dans le cas du ping IPv4 me donne bien 30ms.
Mon interface "lo" est bien activité. Si je débranche mon câble éthernet, celui qui va vers ma Raspberry Pi, j'ai ces ralentissements.
Si je rebranche mon câble, ces ralentissements disparaissent.
Je ne comprends pas l'impact que cela a sur la durée de l'exécution de la commande "ping -4 google.fr -I enp2s0".
Je précise que j'interroge le nom d'hôte "google.fr" depuis Debian sachant que j'ai bien l'internet Ipv4 fonctionnel.
Est-ce que le problème viendrait du routage ?

@+

[boboss123]

Qu'est-ce que tu entends par : "passer d'un VLAN à un autre" ?
Parles-tu de changer l'identifiant de la trame par un autre identifiant ?
Si c'est de cela dont tu parles, cela n'a aucun intéret de le faire car la trame marqué va de l'émetteur vers le récepteur. Entre, ce n'est que du routage, définie par le paramètre "VLAN" qui va autorise la trame à poursuivre son chemin ou pas. Quand elle arrive dans l'interface de destination, on fait "EgressUntagged" afin de rendre exploitable la trame dans le périphérique où elle sera traitée.

Lorsqu'un paquet non tagué entre sur une interface VLAN, il est affecté au VLAN défini par le PVID. Un paquet qui est affecté dans un VLAN n'est pas censé être diffusé dans un autre VLAN (sur certains équipements, on peut définir des règles mais ce sont des règles de routage spécifiques et je ne vois de telles règles dans tes fichiers de configuration) : dans ton lien, ça parle justement de routage layer-3 inter VLAN en créant une adresse de passerelle pour passer d'un VLAN à un autre.
Dans ta configuration les PVID de slv0, slv1 et enp2s0 sont tous différents : donc théoriquement, les paquets entrants devraient être dans des VLANs différents en fonction de l'interface sur laquelle ils entrent.
Mais vu que le VLAN du PVID de enp2s0 est déclaré sur slv0 et slv1, les paquets entrants sur enp2s0 sont autorisés à sortir sur slv0 et slv1 car le PVID de enps0 est déclaré dans la règle EgressUntagged de slv0 et slv1 (et ça fonctionne aussi dans l'autre sens car dans la règle EgressUntagged de enp2s0, tu as déclaré les PVID de slv0 et slv1)... donc pour moi ça fonctionne grâce à ça mais je ne pense pas que les tables de swithing (table MAC) de chaque VLAN soient automatiquement fusionnées... d'où mon pressenti de dire que tous les paquets qui entrent sur enps0 sont broadcastés sur slv0 et slv1... en tout cas, c'est comme ça que ça fonctionne sur un switch.

Fonctionnement d'une table de switching : https://reussirsonccna.fr/switch/
=> Un switch maintient une table par VLAN : donc si un paquet est affecté dans un VLAN et que l'adresse MAC de destination n'est pas enregistrée dans la table, le paquet est broadcasté... je pense que ça doit être le cas avec ta configuration.

... voilà mon raisonnement

[Artemus24]

Lorsqu'un paquet non tagué entre sur une interface VLAN, il est affecté au VLAN défini par le PVID.

Oui, c'est ce que j'ai cru comprendre.

Un paquet qui est affecté dans un VLAN n'est pas censé être diffusé dans un autre VLAN

Oui car le VLAN est le sous-réseau virtuel. Par contre, un port peut recevoir différents VLAN et les trames ne seront plus marqués (untagged) afin d'être traités par le périphérique rattaché au port.

(sur certains équipements, on peut définir des règles mais ce sont des règles de routage spécifiques et je ne vois de telles règles dans tes fichiers de configuration)

Je n'ai que trois règles pour gérer les VLAN dans un pont : "PVID", "VLAN" & "EgressUntagged". Cet exercice ne traite que les VLAN à destination d'un port. Il existe d'autres approches que je n'ai pas traité comme par MACAddress, ou par IPAddress.

Dans ta configuration les PVID de slv0, slv1 et enp2s0 sont tous différents

Tu as oublié "br1" qui est mon Debian.
C'est voulu de les mettre tous différents car mon astuce de mettre le même port pour "br1" et "slv0" puisqu'il gère le même flux ne me semble pas logique.
Je ne sais pas avec exactitude à quoi correspond l'option "PVID". A-t-on le droit dans un commutateur de définir plusieurs fois le même port ? Par simplification de mon exercice, je l'ai fait, mais je suppose qu'il faut mieux éviter de le faire.

donc théoriquement, les paquets entrants devraient être dans des VLANs différents en fonction de l'interface sur laquelle ils entrent.

Pas théoriquement, c'est ce que se passe dans mon exercice. Dans le port "2" qui correspond au "VLAN=2", il entre uniquement les "VLAN=1" & "VLAN=4".

Mais vu que le VLAN du PVID de enp2s0 est déclaré sur slv0 et slv1, les paquets entrants sur enp2s0 sont autorisés à sortir sur slv0 et slv1 car le PVID de enps0 est déclaré dans la règle EgressUntagged de slv0 et slv1

La règle VLAN indique ce qui est autorisé à entrer dans une interface. L'entrée est ce qui vient des autres interfaces.
La règle EgressUntagged indique ce qui doit être non marqué vers la sortie. La sortie est ce qui va vers le périphérique.
Oui, tu as bien compris ce que j'ai fait.

(et ça fonctionne aussi dans l'autre sens car dans la règle EgressUntagged de enp2s0, tu as déclaré les PVID de slv0 et slv1)...

Si je ne le fais pas, ça ne fonctionne pas. Je ne peux pas obtenir l'internet dans mes Raspberry Pi.

donc pour moi ça fonctionne grâce à ça mais je ne pense pas que les tables de switching (table MAC) de chaque VLAN soient automatiquement fusionnées... d'où mon pressenti de dire que tous les paquets qui entrent sur enps0 sont broadcastés sur slv0 et slv1... en tout cas, c'est comme ça que ça fonctionne sur un switch.

Mon exercice est basique, et j'aurai aimé avoir en entrée de ma Box SFR, un flux déjà marqué par un identifiant VLAN. Or SFR ne gère pas les VLAN alors que chez Orange, oui. D'où mon interrogation, à savoir si ce que j'ai fait est valide.

Admettons que mon interface "enp2s0" recoivent des trames venant de ma Box SFR (ou d'ailleurs), où il y a déjà des flux marqué avec des identifiants VLAN. L'interface "enp2s0" laisse passer le flux entrant, qui dans mon exercice sera les "VLAN=1", "VLAN=2" & "VLAN=3". Il n'y a aucune raison à ce que je modifie par "EgressUntagged" les flux, puisque l'interface "enp2s0" jour le rôle d'une barrière douanière.

Ensuite, chaque interface ("br1", "slv0" & "slv1") va autoriser son VLAN lui correspondant en mettant "VLAN=x". Ici, le rôle du port est secondaire. Oui, mais derrière, je n'ai pas un commutateur, mais une Raspberry Pi. De ce fait, le flux venant de ma RPi doit être marqué avec le même identifiant du VLAN reçu, et donc je dois mettre "PVID=x".
Ce qui donne dans ma notation :
--> (br1 ; 1 ; 1,2 ; 1,2)
--> (slv0 ; 2 ; 1,2 ; 1,2)
--> (slv1 ; 3 ; 3 ; 3)
--> (enp2s0 ; 4 ; 1,2,3

L'interface "enp2s0" ne modifie rien, mais laisse paser ce qui est autoriser à le faire. Son numéro de port n'a aucune importance. Je ne fais aucun "EgressUntagged" dans l'interface "enp2s0". Je ne peux plus utiliser mon astuce car j'ai deux VLAN "1" & "2" qui sont bien distincts. Comme je ne peux pas le testé, cela reste une hyppothèse sur ce que j'ai compris de cette mécanique des VLAN.

Une trame venant du périphérique 2, passe par l'interface du port 2 et sera à destination du périphérique 1, qui passe par le port 1. Cela se traduit par l'adresse IP de destination qui sera celle du périphérique 1. La gestion des adresses IP se fait au niveau 3 (réseau) du modèle OSI. Au niveau 2 (liaison) du modèle OSI, la gestion se fait par les adresses MAC, et dans notre cas, par les identifiants VLAN.

Les VLAN se gère par les commutateur "manageable". Dans le cas d'un commutateur non "manageable", seul l'adresse MAC sert comme identifiant de destination.

Si maintenant la gestion des VLAN se fait, la trame sera marqué "VLAN=2" puisqu'elle vient du périphérique 2. La trame sera uniquement adressée aux ports dont le VLAN est autorisé. Dans ma notation, aux ports 1 & 2. Mais comme l'adresse de destination est le périphérique 1, cette trame ne sera pas traité par le port 2, mais uniquement pas le port1. Il y a donc une double condition, celle de l'adresse IP (ou de l'adresse MAC) de destination et celle de l'identifiant du VLAN. Dans le réseau local, comme il y a un filtrage sur les identifiants des VLAN et aussi sur les adresses IP (ou les adresses MAC), il y aura moins de trafic, d'où une fluidité plus importante.

=> Un switch maintient une table par VLAN : donc si un paquet est affecté dans un VLAN et que l'adresse MAC de destination n'est pas enregistrée dans la table, le paquet est broadcasté... je pense que ça doit être le cas avec ta configuration.

Ce qu'il faut savoir, quand tu branches un périphérique sur un commutateur, il y a des questions/réponses qui vont s'échanger. Le commutateur va enregistrer dans sa ou ses table(s) le numéro de port où se trouve le périphérique et son adresse MAC. A priori, tous les périphériques sont connus par leur adresse MAC. Je rappelle qu'un commutateur gère les niveaux 1 (physique) & 2 (liaison) du modèle OSI.

Je connais le commutateur non "manageable" car j'en possède un. Donc pas de gestion des VLAN. Quand est-il d'un commutateur "manageable" ? Je ne sais pas, mais je vais émettre l'hypothèse qu'il y a une table par VLAN. Mais le principe reste le même entre un commutateur gérable de celui non gérable.

Reprenons l'exemple de ton lien en ajoutant deux VLAN. Chaque PC a son interface où la gestion des VLAN se fait. "VLAN=1" pour les PC1, PC4. "VLAN=2" pour les PC2, PC3.

PC1 désire communiquer avec PC4. Ca tombe bien, ils sont dans le même VLAN. Le chemin est connu à l'avance, puisque tous les PC sont branchés, donc pas de diffusion. La trame peut atteindre sa destination car les deux PC sont dans le même VLAN.

PC1 désire communiquer avec PC2. Ca tombe mal, ils ne sont pas dans le même VLAN. L'adresse MAC de destination de PC2 dans le commutateur pour "VLAN=1", n'est pas connu. Il n'y a pas de diffusion car le commutateur connait toutes les adresses MAC activées. La réponse est immédiate, le périphérique est injoignable.

PC1 désire communiquer avec PC5, un PC pas encore branché mais appartenant au même VLAN. L'adresse MAC de destination de PC5 dans le commutateur pour "VLAN=1" n'est pas connu. Même réponse que précédemment.

PC5 est maintenant branché. L'adresse MAC est connue. PC1 envoie une trame vers PC5 qui est joignable.

On débranche PC5. L'adresse MAC est encore connue. PC1 envoie une trame vers PC5. Il y a une mise en attente qui peut durer longtemps, avant d'obtenir une réponse de PC5. Aucune réponse. PC5 est non joignable. Je suppose que l'adresse MAC de PC5 n'est pas effacé du commutateur.

Le but d'un commutateur est justement de gérer les chemins entre un émetteur et un destinataire.
Dans le cas d'un concentrateur (hub), il y a systématiquement une diffusion car il n'y a aucune gestion des adresses MAC.

Pour répondre à ta question, il n'y a pas de diffusion puisque nous utilisons un commutateur.

@+

[boboss123]

Le PVID, tu ne peux en définir qu'un par port vu que c'est l'identifiant qui est affecté aux trames non tagués entrantes sur le port.

Pour moi, ta configuration VLAN correspond à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
        ++===================================================++
        ||                                                   ||
br1  ---|| <--- VLAN 2 -\                                    ||
        ||               \                                   ||
slv0 ---|| ---- VLAN 2 ---+--------- VLAN 2 ---------------> ||--- enp2s0 
        ||                                                   ||
slv1 ---||                                                   ||
        ||                                                   ||
        ++===================================================++

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
        ++===================================================++
        ||                                                   ||
br1  ---|| ---- VLAN 1 -\                                    ||
        ||               \                                   ||
slv0 ---|| <--- VLAN 1 ---+----------- VLAN 1 -------------> ||--- enp2s0 
        ||                                                   ||
slv1 ---||                                                   ||
        ||                                                   ||
        ++===================================================++

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
        ++===================================================++
        ||                                                   ||
br1  ---||                                                   ||
        ||                                                   ||
slv0 ---||                +---------------- VLAN 3---------> ||--- enp2s0 
        ||               /                                   ||
slv1 ---|| ---- VLAN 3 -/                                    ||
        ||                                                   ||
        ++===================================================++

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
        ++===================================================++
        ||                                                   ||
br1  ---|| <--- VLAN 4 -\                                    ||
        ||               \                                   ||
slv0 ---|| <--- VLAN 4 ---+--------- VLAN 4 ---------------- ||--- enp2s0 
        ||               /                                   ||
slv1 ---|| <--- VLAN 4 -/                                    ||
        ||                                                   ||
        ++===================================================++

Dans la table d'adresse MAC du VLAN 1, tu as uniquement les adresses provenant de br1.
Dans la table d'adresse MAC du VLAN 2, tu as uniquement les adresses provenant de slv0.
Dans la table d'adresse MAC du VLAN 3, tu as uniquement les adresses provenant de slv1.
Dans la table d'adresse MAC du VLAN 4, tu as uniquement les adresses provenant de enp2s0.

Donc les paquets entrant sur br1 sont broadcastés sur slv0 et enp2s0.
Donc les paquets entrant sur slv0 sont broadcastés sur br1 et enp2s0.
Donc les paquets entrant sur slv1 sont broadcastés sur enp2s0.
Donc les paquets entrant sur enp2s0 sont broadcastés sur br1, slv0 et slv1.

Exemple :
PC1 sur slv0 et PC2 sur enp2s0 veulent communiquer ensembles :
- PC1 envoie un paquet : le paquet est affecté au PVID (VLAN 2), l'adresse MAC de PC1 est enregistrée dans la table d'adresses MAC du VLAN 2, le switch ne connait pas le port de PC2 dans le VLAN 2 donc il broadcast le paquet sur les ports appartenant au VLAN 2 (br1 et enp2s0).
- PC2 reçoit le paquet car le VLAN 2 est déclaré untagged pour l'interface enp2s0.
- PC2 envoie une réponse : le paquet est affecté au PVID (VLAN 4), l'adresse MAC de PC2 est enregistrée dans la table d'adresses MAC du VLAN 4, le switch ne connait pas le port de PC1 dans le VLAN 4 donc il broadcast le paquet sur les ports appartenant au VLAN 4 (slv0 , slv1 et br1).
- PC1 reçoit bien le paquet de PC2 car le VLAN 4 est déclaré untagged pour l'interface slv0.
=> PC1 et PC2 peuvent bien communiquer ensemble mais il y a broadcast des paquets à la manière d'un hub, cependant le domaine de diffusion est limité au ports membres de chaque VLAN.

Voilà mon raisonnement.
ça fonctionne comme ça sur un switch Layer-2 qui gère les VLAN et donc je suppose que c'est pareil avec systemd-network.

[Artemus24]

Le PVID, tu ne peux en définir qu'un par port vu que c'est l'identifiant qui est affecté aux trames non tagués entrantes sur le port.

Je suis d'accord, mais plusieurs ports peuvent avoir le même identifiant. On va faire simple.
Dans un réseau local, tu as deux VLAN, le "1" et le "2".
Pour le "VLAN=1" (impair), tu as les PC1, PC3, PC5 ...
Pour le "VLAN=2" (pair), tu as les PC2, PC4, PC6 ...
Chaque PC est lié à un port physique sur les commutateurs.
Pas de communication ente différents VLAN, cela va de soi puisque c'est le but.
Sur chacune des interfaces des PC1, PC3, PC5, ..., je vais mettre "PVID=1".
Sur chacune des interfaces des PC2, PC4, PC6, ..., je vais mettre "PVID=2".
Au niveau des déclarations, cela va se résumer à :
--> {PC numéro impair ; Port=1; VLAN=1, EgressUntagged=1}
--> {PC numéro pair ; Port=2; VLAN=2, EgressUntagged=2}
Je ne sais pas pour toi, mais je trouve cette déclaration bien plus simple à gérer.

Si tu pars de l'hypothèse que tu dois créer disons x VLAN, c'est-à-dire x sous-réseau virtuel, le mieux pour identifier les PC appartenant au même VLAN, est d'utiliser le même identifiant x.
Ne pas confondre le port Physique qui est l'emplacement de la prise RJ45 dans le commutateur, et le port virtuel qui est "PVID".

J'ai quand même un doute sur la bonne façon de déclarer ces VLAN, mais mon exemple ci-dessus me semble logique.

C'est presque ça car la circulation se fait dans les deux sens.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
     ++=================================++
     ||                                 ||
br1  || <--> VLAN 2 <--+                ||
     ||                |                ||
slv0 || <--> VLAN 2 <--+--> VLAN 2 <--> || enp2s0 
     ||                                 ||
slv1 ||                                 ||
     ||                                 ||
     ++=================================++

J'ai mis en rouge le sens de circulation de tes paquets.

Je ne sais pas si je te l'ai dit, mais je peux dans mes câbles USB/RJ45 définir le VLAN qui est autorisé à y pénétrer.
Pour "slv0", j'ai mis "VLAN=2" et pour "slv1", j'ai mis "VLAN=3". Avec cette contrainte, mon exercice fonctionne.
Je ne peux donc pas recevoir d'autres trames ayant un VLAN différent de ce qui est autorisé.
Par contre, je reçois les trames non marquées.

Tu ne m'a pas répondu, peux tu reproduire l'exercice chez toi ?

[quote="Boboss133"]- PC1 envoie un paquet : le paquet est affecté au PVID (VLAN 2), l'adresse MAC de PC1 est enregistrée dans la table d'adresses MAC du VLAN 2, le switch ne connait pas le port de PC2 dans le VLAN 2 donc il broadcast le paquet sur les ports appartenant au VLAN 2 (br1 et enp2s0).
PC1 envoie un paquet. Il n'y a pas d'identifiant VLAN car tu es encore dans le PC.
Le paquet non marqué arrive dans l'interface "slv0". Il aura comme identifiant celui de "PVID", c'est-à-dire "2".
Ce paquet va être dirigé vers l'adresse MAC de destination, qui est nécessairement connu du commutateur puisque tous les PC sont branchés.
Le commutateur va donc dirigé le paquet de PC1 vers la bonne interface.
Quand le paquet arrive dans l'interface, il vérifie si c'est le bon VLAN et le laisse passer.
L'interface supprime l'identifiant du VLAN et l'envoie vers le PC où il sera traité.

Admettons que le PC de destination n'a pas été branché et donc l'adresse MAC n'est pas connu dans le commutateur.
Le commutateur connaît chaque PC branché puisqu'il a l'adresse MAC renseignée dans sa table.
Le paquet ne peux pas être envoyé puisque il ignore où se troiuve l'adresse MAC de destination.
Il est indiqué au PC1 que le destinataire est non joignable.

Je te l'ai dit, il ne peut pas y avoir de diffusion (broadcast) car ton commutateur connaît toutes les adresses MAC.
Si l'adresse MAC n'est pas connu, il ne peut pas l'envoyer puisqu'il ignore où elle se trouve.
Inversement, un concentrateur n'a pas de table et ignore où se trouve l'adresse MAC de destination.
Il fait une diffusion sur tous les PC, même si le PC en question n'existe pas.
Je crois que tu confonds commutateur (switch) et concentrateur (hub).

@+

[boboss123]

Je suis d'accord, mais plusieurs ports peuvent avoir le même identifiant. On va faire simple.

Autant pour moi, je croyais que tu voulais affecter plusieurs PVID par port: la solution d'utiliser le même PVID sur plusieurs ports fonctionne, si tu utilises le même PVID sur br1 et slv0, tu économise un VLAN.

Ce qui donnerait avec ta notation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
--> (br1 ; 1 ; 1,3 ; 1,3)
--> (slv0 ; 1 ; 1,3 ; 1,3)
--> (slv1 ; 2 ; 2,3 ; 3)
--> (enp2s0 ; 3 ; 1,2,3 ; 1,2)

D'ailleurs, je me demande si c'est vraiment utile de mettre dans le paramètre VLAN, le VLAN du PVID : peut-être que le port est automatiquement ajouté à la table de VLAN dès que tu déclares le PVID.
Pareil pour EgressUntagged, peut-être que tu n'as pas besoin de le déclarer le port dans EgressUntagged pour le PVID.

Ce qui donnerait la configuration suivante pour le même résultat que le précédent exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
--> (br1 ; 1 ; 3 ; 3)
--> (slv0 ; 1 ; 3 ; 3)
--> (slv1 ; 2 ; 3 ; 3)
--> (enp2s0 ; 3 ; 1,2 ; 1,2)

... à tester.

Tu ne m'a pas répondu, peux tu reproduire l'exercice chez toi ?

Je n'ai pas à ma disposition le matériel pour faire les tests (mon PC n'a qu'une interface réseau, par contre j'ai des switches manageables).

Je te l'ai dit, il ne peut pas y avoir de diffusion (broadcast) car ton commutateur connaît toutes les adresses MAC.
Si l'adresse MAC n'est pas connu, il ne peut pas l'envoyer puisqu'il ignore où elle se trouve.

Dans un switch, si l'adresse MAC n'est pas connue, elle est broadcastée sur tous les ports appartenant au VLAN dans lequel le paquet a été affecté... si ce n'était pas le cas, à l'allumage du switch, le remplissage de la table d'adresse MAC ne pourrait pas se faire correctement.
Si mon intuition est bonne (que ça fonctionne comme pour un switch), effectivement systemd-networkd connait toutes les adresses MAC... mais dans des réseaux (VLAN) différents... et donc lorsqu'un paquet entre dans un VLAN, systemd-networkd le broadcast sur tous les ports du VLAN. Dans un switch, tu as tout à fait le droit d'avoir la même adresse MAC sur des ports différents à condition que les paquets soient affectés dans des VLANs différents : ce cas est géré vu que tout est traité indépendamment par VLAN.

[Artemus24]

Autant pour moi, je croyais que tu voulais affecter plusieurs PVID par port: la solution d'utiliser le même PVID sur plusieurs ports fonctionne, si tu utilises le même PVID sur br1 et slv0, tu économise un VLAN.

Il y a bien un et un seul port par interface. Je sais que mettre le même identifiant de ports à plusieurs interfaces est possible, mais je me pose la question si c'est la bonne façon de faire. Ce qui voudrait dire que le même identifiant pour tous les ports désigne le même VLAN, qu'elle que soit le routeur ou les commutateur que tu utilises dans ton réseau local. Si c'est la bonne façon de faire, cela simplifie grandement la configuration.

Ce qui donnerait avec ta notation :

C'est bien cela, mais avec cette correction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

--> (slv1 ; 2 ; 2,3 ; 2,3)

D'ailleurs, je me demande si c'est vraiment utile de mettre dans le paramètre VLAN, le VLAN du PVID

Je l'ai testé et oui, c'est obligatoire sinon le VLAN n'est pas traité.

Pareil pour EgressUntagged,

Là aussi, je suis obligé de dire quel VLAN doit ne plus être balise (ou marqué), sinon ça ne fonctionne pas.

Je n'ai pas à ma disposition le matériel pour faire les tests (mon PC n'a qu'une interface réseau, par contre j'ai des switches manageables).

J'ai un Asus sous Debian, et j'ai deux adaptateurs StarTech USB/RJ45 allant à la vitesse de 100mb/s, et j'ai plusieurs Raspberry PI pour tester. J'ai commandé d'autres adaptateurs de la même marque, deux allant à 1gb/s et deux allant à 2,5gb/s. Je vais me servir de l'adaptateur à 2,5gb/s pour tester ma futur acquisition, un module optique ONU/SFP+ G-PON, quand j'aurai configuré mon Debian en routeur. Pour faire fonctionner ce module optique, soit je me procure un routeur comme le Banana BRP-R4 ou soit un Media Converter.

Dans un switch, si l'adresse MAC n'est pas connue, elle est broadcastée sur tous les ports appartenant au VLAN dans lequel le paquet a été affecté... si ce n'était pas le cas, à l'allumage du switch, le remplissage de la table d'adresse MAC ne pourrait pas se faire correctement.

Il est fort possible que je ne sois pas exactement à jour sur ma connaissance des commutateurs.

La différence entre un concentrateur (hub) et un commutateur (switch), est que le premier pour chaque envoie d'une trame, diffuse dans tout le réseau, car il ignore les adresses MAC des périphériques pour la simple raison, qu'il ne gère aucune table. Pour le second, la trame est envoyé uniquement vers le périphérique ayant la bonne adresse MAC. Il y a au démarrage du commutateur, une initialisation qui fait qu'il récupère toutes les adresses MAC des périphériques connectés. De même, quand un nouveau périphérique se connecte, il y a des échanges entre eux, afin de mettre à jour la table qui gère les adressses MAC. Régulièrement, le commutateur doit demandé à tous les périphériques s'ils sont encore bien présent, et des échanges, disons de réinitialisation, doivent être fait régulièrement. Dans le cas où un périphérique est débranché, la table conserve l'adresse MAC, d'où les délais d'attente de la réponse du périphérique qui ne viendra jamais. Je suppose que l'adresse MAC est conservé, mais le périphérique doit être mis en indisponibilité. D'où la constatation que la première réponse de ce périphérique indisponible est longue à attendre, tandis que les fois suivantes, elle sera très rapide car maintenant le commutateur sait que le périphérique est débranché (ou indisponible).

Si l'adresse MAC est renseignée mais n'est pas connu, pourquoi veux tu qu'il diffuse la trame sur toutes les sorties du commutateur, alors qu'il connait toutes les adresses MAC des périphériques branchés ? C'est contraire à son fonctionnement puisqu'il a une table où son stocké toutes les adresses MAC. Cela ne me semble pas logique du tout de procéder ainsi.

Juste une question afin de comprendre comment va se faire la diffusion. Nous sommes dans un commutateur qui gère les niveaux 1 (physique) er 2 (liaison). Une diffusion se fait sur l'adresse IP de broadcasting et c'est du ressort du niveau 3 (réseau), non ? Ou alors, et je reconnais que je ne sais pas, s'il existe plusieurs mode de diffusion dans un réseau local.

Si mon intuition est bonne (que ça fonctionne comme pour un switch), effectivement systemd-networkd connait toutes les adresses MAC... mais dans des réseaux (VLAN) différents... et donc lorsqu'un paquet entre dans un VLAN, systemd-networkd le broadcast sur tous les ports du VLAN.

Je pense qu'il y a combinaison de l'acheminement du paquet (ou trame) selon le fonctionnement d'un commutateur disons non manageable et du fonctionnement VLAN sur les interfaces. Il faut voir chaque réseau virtuel comme étant unique dans ton réseau local. Autrement dit, ce qui se passe dans le VLAN=1 est totalement ignoré par le VLAN=2 et vice-versa. Le cheminement du paquet est différent selon le VLAN utilisé. D'où un trafic moins important. Maintenant, tu soulèves la question de l'acheminement du paquet entrant. Voici ce que je pense :

a) Si le paquet venant d'internet est une réponse suite à une question posée, pour l'acheminer vers le bon périphérique, la question aupréalable aura stocké, par le routeur, l'adresse IP local ainsi que l'adresse MAC de l'émetteur. Comme la réponse est autorisée par le pare-feu, l'acheminement se fait directement, donc sans diffusion vers le périphérique de destination.

b) Si des paquets entrants, qui sont des questions venant d'internet, sont autorisés par le pare-feu, cela va dépendre du :
--> NAT qui pour un port donné, va remplacer l'adresse de destination IP WAN publique, par l'adresse IP local de destination.
--> DHCP où tu auras fait l'association (adresse IP local ; adresses MAC du périphérique).
Si cette association n'est pas faite, il y aura diffusion dans tout le réseau puisque l'adresse MAC n'est pas renseignée.

c) le paquet entrant provient d'un périphérique de ton réseau local. L'adresse MAC est nécessairement connue et l'acheminement se fait directement vers le périphérique de destination.

d) Je pense qu'il faut faire la distinction entre une adresse MAC renseignée mais inconnue et une adresse MAC non renseignée. Selon moi, et encore je ne suis pas du tout sûr de ce que j'avance, la diffusion dans tout le réseau local se fait que si l'adresse MAC n'est pas renseignée.

Franchement, je ne vois pas d'autres cas où la diffusion se ferait à tous les périphériques de ton réseau local.

Le VLAN ne change rien au fonctionnement des routeurs / commutateurs. Cela va même réduire le trafic, puisque les paquets sont acheminés que dans le réseau virtuel identifié par son VLAN. Je considère que le VLAN est une surcouche au fonctionnement des commutateurs.

Dans un switch, tu as tout à fait le droit d'avoir la même adresse MAC sur des ports différents à condition que les paquets soient affectés dans des VLANs différents : ce cas est géré vu que tout est traité indépendamment par VLAN.

Je suis d'accord.

Je préfère plutôt utiliser le terme de propagation pour différencier celle de diffusion (broadcasting) qui se fait par l'adresse IP broadcating. En effet, un paquet va se propager dans tout le réseau, mais quand il arrive dans un commutateur, il est acheminé vers le périphérique que si l'adresse MAC renseignée est la bonne. Quand deux commutateurs sont reliés, je suppose que la table de l'émetteur va dire si le paquet est autorisé à se rendre dans l'autre commutateur. Et cela se fait que si l'adresse MAC est présente dans le premier commutateur à destination du second.

La bonne question est celle où un paquet n'a pas d'adresse MAC de renseigné. Est-ce que ce cas existe réellement ?

J'ai fait le test du "KIND=BOND". J'ai rattaché mon interface éthernet "enp2s0" et mon interface WiFi "wlp4s0" à cette interface "bnd0" et je me suis retrouvé avec la même adresse MAC dans mes trois interfaces. J'ai autorisé dans ma Box SFR la nouvelle adresse MAC et j'ai pu constaté que le lien entre éthernet et WiFi fonctionnait bien. J'ai testé en débranchant l'un ou l'autre et j'avais encore de l'internet dans mon Debian.

J'ai fait une recherche sur le net pour remplacer les ports par des adresses MAC mais je n'ai rien trouvé. Je parle du cas où j'utilise le pont (bridge) comme dans cet exercice. A priori, ce n'est pas bien grave, mais j'aurai aimé avoir plus de souplesse en utilisant les adresses MAC.

As tu jeté un oeil à mon exercice sur les interfaces WAN & LAN ? Je rencontre un problème dans ma raspberry Pi branché sur l'interface "lan0". J'obtiens bien les adresses IPv6 du DHCP, mais quand je fais "ping -6 google.fr -I end0", le site en IPv6 est injoignable. Et pourtant, ça fonctionne en IPv4. Il me manque quelque chose comme le routage IPv6 entre l'interface WAN et l'interface LAN.

@+