Auteur Sujet: Remplacement de la Livebox par un routeur Openwrt (Lu 248128 fois)

renaud07 · « **Réponse #948 le:** 27 avril 2024 à 23:22:20 »

Ah oui, j'y pensais justement aux relay. Faudrait que je retrouve le message de Levieux.

renaud07 · « **Réponse #949 le:** 29 avril 2024 à 20:48:56 »

J'ai légèrement modifié mes règles de renew : depuis le début j'avais décalé de 1min entre chaque, là j'ai mis en même temps (toujours à 24h) et ça fait 3 jours que c'est up.

Je continue à surveiller, mais pour le moment ça semble bon.

basilix · « **Réponse #950 le:** 04 mai 2024 à 12:02:38 »

Bonjour !

Je ne suis toujours pas parvenu à remplacer la Livebox. À vrai dire, je n'ai pas réalisé le paramétrage. :'(

Citation de: ubune

Ici on ne fait pas de dhcpv6, uniquement du RA, on annonce le premier /64 du /56 au lan (pour l'autoconfiguration des machines) + serveur dhcpv4.

J'ai recherché sur le blogue de M. Bortzmeyer son analyse du RFC 8415 en vue d'accomplir ma quête.

Je n'avais pas réalisé que le préfixe assigné à un lien, lors d'une auto-configuration (sans délégation de préfixe), a une taille /64. Parce que SLAAC fonctionne avec
un préfixe /64 même si le routeur de l'abonné dispose d'un préfixe supérieur à /64. Bien que cela ne change rien pour l'abonné ayant une topologie de réseau à plat,
de par le nombre d'IP disponibles. Que fait le routeur pour répartir des préfixes ? Comment les préfixes sont-ils attribués aux interfaces ? (via le client ?) Mystère...

Cela pourrait peut-être expliquer la raison pour laquelle odhcpd est multi-services ?

Citer

odhcpd provides server services for DHCP, RA, stateless SLAAC and stateful DHCPv6, prefix delegation and can be used to relay RA, DHCPv6 and NDP between routed (non-bridged) interfaces in case no delegated prefixes are available.

basilix · « **Réponse #951 le:** 04 mai 2024 à 12:46:57 »

Je crois que j'ai trouvé une réponse en recherchant dans la documentation (solution simple).

# Protocol "static", IPv6 (/etc/config/network).

Code: [Sélectionner]

Name        Type              Required        Default    Description
ip6assign   prefix length     no              (none)     Delegate a prefix of given length to this interface (see Downstream configuration below)

[14:10] Je crois avoir compris comment cela est opéré. ~~Le client DHCP du routeur CPE attribue des préfixes aux diverses interfaces via la configuration de /etc/config/network.~~

Citation de: RFC 8415, p. 20

The model of operation for prefix delegation is as follows. A server is provisioned with prefixes to be delegated to clients. A client requests prefix(es) from the server, as described in Section 18.
The server chooses prefix(es) for delegation and responds with prefix(es) to the client. The client is then responsible for the delegated prefix(es). For example, the client might assign a
subnet from a delegated prefix to one of its interfaces and begin sending Router Advertisements for the prefix on that link.

Le serveur DHCP peut ensuite déléguer à son tour des préfixes (définis par le client DHCP) ou assigner des adresses.

renaud07 · « **Réponse #952 le:** 04 mai 2024 à 16:58:15 »

Dans ce cas, c'est de l'adressage statique. odhcpd ne s'en occupe pas lorsque c'est sur le routeur même. Par contre oui, c'est lui qui annonce le préfixe sur le LAN une fois configuré.

basilix · « **Réponse #953 le:** 04 mai 2024 à 19:01:54 »

@renaud07 : Merci pour la réponse !

Je me suis embrouillé l'esprit en me persuadant que le sous-réseautage était accompli par le client DHCP ; du fait que les préfixes délégués soient automatiquement détectés par le serveur DHCP
du routeur CPE. En fait, je ne sais pas comment le préfixe est attribué à une interface. On ne précise que sa taille (ip6assign) et le préfixe de sous-réseau (ip6hint).

On a deux processus potentiellement disjoints : un client DHCP négociant avec le serveur DHCP du FAI et le serveur DHCP du routeur CPE qui exploite le(s) préfixe(s) disponible(s).
D'un autre côté, l'allocation d'un préfixe peut être dynamique car pour une durée temporaire. Mais il me semble que, dans ce cas, c'est le serveur DHCP du FAI ou bien le client DHCP du
routeur CPE qui impose la durée d'allocation du préfixe au serveur DHCP du routeur CPE. Bref, il faut vraiment que j'arrête de faire des spéculations.

fatpat · « **Réponse #954 le:** 07 mai 2024 à 07:50:31 »

Salut

et merci bcp pour toutes les informations. j'ai modifié un peu le contenu du fichier /etc/nftables.d/nft-prio6-rules.include afin de coller aux recos faite le thread durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire

Citation de: levieuxatorange

La COS6 (et idéalement le pendant dscp) doit être appliqué :

Au DHCPv4v6 issu de la boxe
Au ARP issu de la boxe
A l'ICMPv6 code NS/NA issu de la boxe et à destination de l'ipv6 fe80::ba0:bab
A l'ICMPv6 code RS issu de la boxe et à destination de l'ipv6 multicast idoine (c'est ba0bab qui répond)
Rien d'autre ...

En gros:

j'ai viré les parties icmp et igmp qui n'étaient pas utiles pour internet v4/v6 (pas sur que ça le soit pour la TV je n'ai pas creusé)
j'ai limité les paquets icmpv6 aux types NS, NA vers fe80::ba0::bab et RS
j'ai rajouté le DSCP CS6 en plus de la SKP priority 6

Code: [Sélectionner]

oifname "eth0.832" counter meta priority set 0:1
oifname "eth0.832" udp dport 67 counter meta priority set 0:6 ip dscp set cs6
oifname "eth0.832" udp dport 547 counter meta priority set 0:6 ip dscp set cs6
oifname "eth0.832" icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert } ip6 daddr fe80::ba0:bab/128 counter meta priority set 0:6 ip6 dscp set cs6
oifname "eth0.832" icmpv6 type nd-router-solicit counter meta priority set 0:6 ip6 dscp set cs6

je suis en version 23.05.03

on peut check avec tcmpdump.

Avant, on voit bien une vlan priorité à 6 (p 6) mais un DSP CS0 (tos 0x00)

Code: [Sélectionner]

root@router:~# tcpdump -i eth0 -vv -n -s0 -e 'vlan 832 and ether src xx:xx:xx:xx:xx:xx and ether[14] >> 5 = 6'
06:13:35.154539 xx:xx:xx:xx:xx:xx > a4:7b:2c:30:c7:e2, ethertype 802.1Q (0x8100), length 444: vlan 832, p 6, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 46380, offset 0, flags [DF], proto UDP (17), length 426)

Après, on voit bien une vlan priorité à 6 (p 6) et un DSCP CS6 (tos 0xc0)

Code: [Sélectionner]

root@router:~# tcpdump -i eth0 -vv -n -s0 -e 'vlan 832 and ether src xx:xx:xx:xx:xx:xx and ether[14] >> 5 = 6'
06:14:23.571699 xx:xx:xx:xx:xx:xx > a4:7b:2c:30:c7:e2, ethertype 802.1Q (0x8100), length 444: vlan 832, p 6, ethertype IPv4 (0x0800), (tos 0xc0, ttl 64, id 62412, offset 0, flags [DF], proto UDP (17), length 426)

Enfin pour la compréhension générale, j'aurai rajouté le commentaire suivant pour expliquer les lignes egress_qos_mapping dans /etc/config/network:

Code: [Sélectionner]

config device
	option name 'eth0.832'
	option type '8021q'
	option ifname 'eth0'
	option vid '832'
	list egress_qos_mapping '1:0' # dans nft-prio6-rules.include on set la skp priority par défaut à 1 qu'on map en vlan priority 0 (COS 0). ca va matcher tous les paquets IPv4 et IPv6 (inet)
	list egress_qos_mapping '6:6' # dans nft-prio6-rules.include on set la skp priority à 6 pour les pacquets DHCP et ICMPv6 spécifiques, qu'on map en prio vlan 6 (COS 6)
	list egress_qos_mapping '0:6' # tout le reste (donc ce qui n'est pas inet (aka ipv4 or ipv6)) sera mappé en vlan prio 6 (COS 6), ce qui inclue ARP (exclusivement dans le cas présent).
	option macaddr 'xx:x:xx:x:x:xx'

j'ai galéré à comprendre comment les paquets ARP étaient taggé en vlan priority 6.

basilix · « **Réponse #955 le:** 07 mai 2024 à 08:46:52 »

Bonjour @fatpat !

Je pense que ce serait plus clair de simplement énoncer le procédé utilisé. Chercher à entrecroiser des indications à titre d'explication ne va qu'accroître la confusion.
~~Il faut d'abord exposer de quoi on parle : Pour le noyau, changer la priorité interne de paquets particuliers ; puis définir la CoS des trames encapsulant ces paquets.~~

Le problème du procédé employé est qu'il va changer aveuglement les correspondances entre les priorités internes des paquets ayant une priorité égale à 0 et les
CoS des trames sortantes en les repositionnant convenablement par la suite par réaffectation.

oifname "eth0.832" counter meta priority set 0:1

Citation de: ip-link(8)

egress-qos-map QOS-MAP

defines a mapping of Linux internal packet priority to VLAN header prio field but for outgoing frames. The format is the same as for ingress-qos-map.

~~[09:09] En fait, je ne comprends pas ! La règle du-dessus, c'est pour les dénombrer ?~~

fatpat · « **Réponse #956 le:** 07 mai 2024 à 10:01:07 »

merci pour ton retour, en te lisant, ça m'a fait creuser un peu plus et j'ai opté pour l'utilisation de tc à la place de nftables pour set les priorités.

de la sorte, je set en prio6 uniquement ce qu'il faut et dans la conf egress-qa-map de l'interface on a qqc de logique. Ca supprime la règle nftables par defaut en priorité 1 qui est ensuite remappé en COS0. De plus ça permet d'être explicite sur la règle ARP.

mon fichier /etc/config/tc-cos6.sh

Code: [Sélectionner]

#!/bin/sh

DEVICE="${1}"

# Configure a PRIO qdisc on a VLAN interface.
tc qdisc replace dev "${DEVICE}" root handle 1: prio
tc filter del dev "${DEVICE}"

# ARP
tc filter add dev "${DEVICE}" parent 1: prio 1 protocol 0x806 u32 \
  match u32 0 0 \
  action skbedit priority 0:6

# DHCPv4
tc filter add dev "${DEVICE}" parent 1: prio 2 u32 \
  match ip ihl 5 0xf \
  match u16 0x0000 0x1fff at 6 \
  match ip protocol 17 0xff \
  match ip sport 68 0xffff \
  match ip dport 67 0xffff \
  action skbedit priority 0:6 pipe \
  action pedit munge ip tos set 0xc0 retain 0xfc pipe \
  action csum ip4h
 
# DHCPv6
tc filter add dev "${DEVICE}" parent 1: prio 3 protocol ipv6 u32 \
  match ip6 dst fe00::/7 \
  match ip6 protocol 17 0xff \
  match ip6 sport 546 0xffff \
  match ip6 dport 547 0xffff \
  action skbedit priority 0:6 pipe \
  action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc

# ICMPv6 Router Solicitation (133) to multicast (ff02::/16)
tc filter add dev "${DEVICE}" parent 1: prio 4 protocol ipv6 u32 \
  match ip6 dst ff02::/16 \
  match ip6 protocol 58 0xff \
  match ip6 icmp_type 133 0xff \
  action skbedit priority 0:6 pipe \
  action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc

# ICMPv6 Neighbor Solicitation (135) to orange dhcp server (fe80::ba0:bab/128)
tc filter add dev "${DEVICE}" parent 1: prio 5 protocol ipv6 u32 \
  match ip6 dst fe80::ba0:bab/128 \
  match ip6 protocol 58 0xff \
  match ip6 icmp_type 135 0xff \
  action skbedit priority 0:6 pipe \
  action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc

# ICMPv6 Neighbor Advertisement (136) to orange dhcp server (fe80::ba0:bab/128)
tc filter add dev "${DEVICE}" parent 1: prio 6 protocol ipv6 u32 \
  match ip6 dst fe80::ba0:bab/128 \
  match ip6 protocol 58 0xff \
  match ip6 icmp_type 136 0xff \
  action skbedit priority 0:6 pipe \
  action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc

comme ça plus de règle nftables spécifiques et on simplifie la conf de l'interface:

Code: [Sélectionner]

config device
	option name 'eth0.832'
	option type '8021q'
	option ifname 'eth0'
	option vid '832'
	list egress_qos_mapping '0:0'
	list egress_qos_mapping '6:6'
	option macaddr 'xx:xx:xx:xx:xx:xx'

basilix · « **Réponse #957 le:** 07 mai 2024 à 10:25:50 »

@fatpat : J'ai retrouvé le propos de Fuli10 qui m'avait aidé à y voir plus clair. Je commençais à m’embrouiller les idées.

Citation de: Fuli10 le 03 décembre 2022 à 22:18:59

Le problème c'est pour le dhcp. Comme pour envoyer les requêtes dhcp sans IP sur l'interface, le client passe par une socket RAW. Ces paquets ne passent pas par les nftables. Du coup il n'est pas possible de changer la priorité, du coup c'est envoyé avec la priorité 0.
C'est pour ça qu'il y a la règle nftable pour tout passer en priorité autre, sauf les paquets DHCP qui ne passent pas par socket RAW. Ensuite c'est (de ce que j'ai compris) le HW de la carte reseau qui applique la règle priorité 0 (raw socket et dhcp) vers 6 et de priorité 1 (tout le reste via nftable) vers 0.
C'est pour ça que je voulais tester si c'est HW ou SW, en utilisant les filtres avec tc et d'intégrer ça proprement dans openwrt, mais je n'ai pas eu le temps.

basilix · « **Réponse #958 le:** 07 mai 2024 à 13:19:49 »

@fatpat :

Je ne connais pas bien la réseautique. Mais à mon avis, ARP n'a rien avoir avec le sujet.

Car ARP est un protocole qui permet de trouver l'adresse MAC associée à une adresse IPv4.

fatpat · « **Réponse #959 le:** 07 mai 2024 à 14:27:04 »

Citation de: basilix le 07 mai 2024 à 13:19:49

@fatpat :

Je ne connais pas bien la réseautique. Mais à mon avis, ARP n'a rien avoir avec le sujet.

Car ARP est un protocole qui permet de trouver l'adresse MAC associée à une adresse IPv4.

un peu de lecture pour la référence: durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire

et la partie importante:

Citation de: levieuxatorange

La COS6 (et idéalement le pendant dscp) doit être appliqué :

Au DHCPv4v6 issu de la boxe
Au ARP issu de la boxe
A l'ICMPv6 code NS/NA issu de la boxe et à destination de l'ipv6 fe80::ba0:bab
A l'ICMPv6 code RS issu de la boxe et à destination de l'ipv6 multicast idoine (c'est ba0bab qui répond)
Rien d'autre ...

tous les paquets ARP qui sortent du routeur sur le vlan 832 doivent être taggé avec COS6. Seul le DSCP (ou TOS) n'est pas applicable aux paquets ARP car le TOS se trouve dans l'entête IP. Couche 3 vs couche 2, modèle OSI tout ça tout ça