La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: basilix le 02 juillet 2024 à 22:09:51
-
Peut-on filtrer les « raw packets » avec nftables ?
C'est juste pour savoir si on peut le faire avec le nouveau hook « egress » de nftables.
L'ancienne solution se trouve dans le post de Mastah !! (https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/msg1079566/#msg1079566)
La nouvelle solution se trouve dans mon post !! (https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/msg1130223/#msg1130223)
-
C'est le Wiki Netfilter.org qui me fait penser cela.
Base chain hooks (https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_hooks)
ingress (only in netdev family since Linux kernel 4.2, and inet family since Linux kernel 5.10): sees packets immediately after they are passed up from the NIC driver, before even prerouting. So you have an alternative to tc.
Introduction (https://wiki.nftables.org/wiki-nftables/index.php/Classification_to_tc_structure_example)
nftables can replace not even iptables, but it can be used to replace very poorly documented tc filter rules and allow user to classify packets into tc class / qdisc infrastructure.
[...]
* action used to classify packets into tc structure is meta set priority "1:0x2" - 0x can be omitted, but says clearly it is hex number - double quotes are required
Ingress hook (https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks#Ingress_hook)
You can use nftables with the ingress hook to enforce very early filtering policies that take effect even before prerouting. Do note that at this very early stage, fragmented datagrams have not yet been reassembled. So, for example, matching ip saddr and daddr works for all ip packets, but matching L4 headers like udp dport works only for unfragmented packets, or the first fragment.
Personnellement, je préfère que le client DHCP soit modifié (https://lafibre.info/remplacer-livebox/patch-udhcpc6-soumis-sur-la-liste-de-diffusion-busybox/) si nécessaire afin de définir un PCP (priority code point) adéquat sur le paquet DHCP (trame) « Discovery ».
-
Bah d'après la doc il semble que oui, si ils parlent de remplacer TC
Je suis sur un kernel 6.1.0 et nft 1.0.6. Je dois donc pouvoir testé. Par contre j'ai la mega flemme de faire ça solo :D
-
Personnellement, je préfère que le client DHCP soit modifié (https://lafibre.info/remplacer-livebox/patch-udhcpc6-soumis-sur-la-liste-de-diffusion-busybox/) si nécessaire afin de définir un PCP (priority code point) adéquat sur le paquet DHCP (trame) « Discovery ».
De mon coté je préfère qu'un serveur DHCP n'ait pas à ce soucier de la prio des packets qu'il émet. Chaque couche devrait avoir sa responsabilité bien partagé.
Je préfère faire ça autrement. La solution via NFTable est pas mal du coup. A voir si fonctionnel cela dit.
Après j'ai un doute qu'avec NFTable tu puisses modifié un packet autre que l'accepter ou le refuser.
-
Peut-être que si en faite, mais j'ai un gros doute.
Since nftables v0.7 you can match the packet priority, the tc classid:
nft add rule filter forward meta priority abcd:1234cf. https://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation
nft add rule mangle postrouting tcp sport 80 meta priority set 1ou
tcp dport 25565 ip dscp set cs6
Potentiel recherche : nftables "802.1p" egress netdev
-
Mon objectif c'est de faire de l'auto-hébergement Web. Mais face à l'amplification des cyberattaques, je préfère me former. Il y a trop de choses que je ne connais pas
et ma technique d'apprentissage n'est pas forcément très efficace. Je pense que j'assimile les choses de manière trop séquentielle, cela me freine car je n'expérimente
pas de la bonne façon. Je lis le Wiki Netfilter.org alors que j'aurais pu essayer de réaliser des tests avec des machines virtuelles sur mon PC. Je ne sais pas pourquoi
mais cela ne me dit rien, ou je n'en ai pas vraiment envie. Je pense que c'est faire face à la complexité qui me fait peur. Bref !
J'ai également fait des recherches mais je n'ai pas trouvé tellement d'informations sur le sujet.
Après j'ai un doute qu'avec NFTable tu puisses modifier un packet autre que l'accepter ou le refuser.
Rules take action on network packets (e.g. accepting or dropping them) based on whether they match specified criteria.
Each rule consists of zero or more expressions followed by one or more statements. Each expression tests whether a packet matches a specific payload field or packet/flow metadata. Multiple expressions are linearly evaluated from left to right: if the first expression matches, then the next expression is evaluated and so on. If we reach the final expression, then the packet matches all of the expressions in the rule, and the rule's statements are executed. Each statement takes an action, such as setting the netfilter mark, counting the packet, logging the packet, or rendering a verdict such as accepting or dropping the packet or jumping to another chain. As with expressions, multiple statements are linearly evaluated from left to right: a single rule can take multiple actions by using multiple statements. Do note that a verdict statement by its nature ends the rule.
Source : Nftables Wiki: Simple rule management (https://wiki.nftables.org/wiki-nftables/index.php/Simple_rule_management)
Les systèmes d'exploitation ont intégré des fonctionnalités au cours de leur histoire. Et donc cela peut être difficile de s'y retrouver.
The netfilter project enables packet filtering, network address [and port] translation (NA[P]T), packet logging, userspace packet queueing and other packet mangling.
Source : Netfilter.org (https://netfilter.org/)
Netfilter enables filtering at multiple networking levels. With iptables there is a separate tool for each level: iptables, ip6tables, arptables, ebtables. With nftables the multiple networking levels are abstracted into families, all of which are served by the single tool nft.
Source : Nftables families (https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families)
Le projet Netfilter qualifie nftables (netfilter tables) de « système de classification de paquets » et pas seulement comme un pare-feu logiciel.
iptables is a generic firewalling software that allows you to define rulesets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target).
nftables is the successor of iptables, it allows for much more flexible, scalable and performance packet classification. [...]
Source : Netfilter.org (https://netfilter.org/)
-
J'ai du mal à percevoir comment les familles dans nftables sont appliquées avec netfilter. C'est ennuyant pour saisir le principe !
[19:13] Je croyais que les paquets étaient désencapsulé par le pilote et que le crochet « ingress » était un processus géré par le pilote, lequel aurait été contrôlé par la carte réseau.
Mais le noyau peut implémenter une partie de la couche liaison (L2) ainsi que la couche réseau (L3). D'ailleurs, le pilote fait parti du système d'exploitation et les paquets sont sûrement
désencapsulé lorsqu'ils traversent le crochet « input ». Du coup, je saisi nettement mieux d’où venait mon problème de compréhension.
% nft add rule filter input ether daddr ff:ff:ff:ff:ff:ff counter
Do not forget that the layer 2 header information is only available in the input path. (https://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_headers#Matching_ethernet_headers)
On Sun, Mar 15, 2020 at 2:29 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>
> Hello Daniel,
>
> On Sat, Mar 14, 2020 at 01:12:02AM +0100, Daniel Borkmann wrote:
> > On 3/13/20 3:55 PM, Pablo Neira Ayuso wrote:
> [...]
> > > We have plans to support for NAT64 and NAT46, this is the right spot
> > > to do this mangling. There is already support for the tunneling
> >
> > But why is existing local-out or post-routing hook _not_ sufficient for
> > NAT64 given it being IP based?
>
> Those hooks are not coming at the end of the IP processing. There is
> very relevant IP code after those hooks that cannot be bypassed such
> as fragmentation, tunneling and neighbour output. Such transformation
> needs to happen after the IP processing, exactly from where Lukas is
> proposing.
>
> [...]
> > > infrastructure in netfilter from ingress, this spot from egress will
> > > allow us to perform the tunneling from here. There is also no way to
> > > drop traffic generated by dhclient, this also allow for filtering such
> > > locally generated traffic. And many more.
Hi,
Any chance to continue with this approach? I'm afraid outbound
af_packets also could not be filtered without this hook.
Thanks.
Source : [nf-next,3/3] netfilter: Introduce egress hook (http://patchwork.ozlabs.org/comment/2414768/)
AF_PACKET désigne les « packet sockets » (man 7 packet).
-
J'essayerais de modifier la CoS avec nftables dans la configuration de mon routeur. Mais avant, je préfère me former sur le pare-feu.
Nicolas Massé mentionne qu'on devrait pouvoir faire cela avec nftables (https://www.itix.fr/fr/blog/fibre-orange-remplacer-livebox-routeur-centos-stream-8/).
Il est à noter qu’à partir du noyau 5.7, le filtre “egress” de netfilter devrait permettre la capture des paquets DHCPv4 et l’étiquetage de leur priorité. Le client DHCP patché ne serait alors plus nécessaire.
-
Oui mais si il n'y a aucune resource en set sur l'egress, ça ne sera pas possible. Hors de ce que j'ai vu les objet qui permettent d'interagir avec la prio ne sont qu'en get/filter.
-
@Mastah : Je ne sais pas mais il me semble qu'on peut le faire.
table netdev filter {
chain egress {
type filter hook egress devices = { eth0, eth1 } priority 0;
meta priority set ip saddr map { 192.168.10.2 : abcd:2, 192.168.10.3 : abcd:3 }
}
}
Source : https://lore.kernel.org/all/YZZV42ERgpDbk%2FzL@salvia/
-
Je ne connais pas vraiment DHCPv4.
En DHCPv6, il me semble que les transactions se font généralement avec l'adresse multicast (tous les serveurs et relais DHCP) ff02::1:2.
[21:09] Il me semble que le client DHCPv6 utilise son adresse locale au lien (link-local address: LLA), celle de l'interface connectée au réseau FAI (c.f. RFC 8415, page 16).
If the client has a source address of sufficient scope that can be used by the server as a return address and the client has received a Server Unicast option (see Section 21.12) from the server, the client
SHOULD unicast any Request, Renew, Release, and Decline messages to the server.
When the server receives a message via unicast from a client to which the server has not sent a Server Unicast option (or is not currently configured to do so), the server discards that message
and responds with an Advertise (when responding to a Solicit message) or Reply message (when responding to any other messages) containing a Status Code option (see Section 21.13) with
the value UseMulticast, a Server Identifier option (see Section 21.3) containing the server’s DUID, the Client Identifier option (see Section 21.2) from the client message (if any), and no other options.
All_DHCP_Relay_Agents_and_Servers (ff02::1:2) A link-scoped multicast address used by a client to communicate with neighboring (i.e., on-link) relay agents and servers.
All servers and relay agents are members of this multicast group.
Je précise cela car il serait facile de filtrer les paquets grâce à l'adresse multicast locale au lien.
[20:58] Il semblerait qu'en DHCPv4 le client communique avec le serveur en « broadcast limité » avec l'IP destination 255.255.255.255.
[21:05] Le paquet DHCP DISCOVER a pour adresse IP source 0.0.0.0 et IP destination 255.255.255.255.
Hyperlien : (IT-CONNECT.FR) : DHCP : Mode de fonctionnement (https://www.it-connect.fr/chapitres/dhcp-mode-de-fonctionnement/).
-
Je pense que la configuration ci-dessous pourrait fonctionner (à tester).
table netdev filter {
chain egress {
type filter hook egress device eth1 priority 0;
ip daddr 255.255.255.255 meta priority set 0:6 comment "Set CoS value to 6 for DHCPv4 packets"
ip6 daddr ff02::1:2 meta priority set 0:6 comment "Set CoS value to 6 for DHCPv6 packets"
}
}
-
Je pense que la configuration ci-dessous pourrait fonctionner (à tester).
table netdev filter {
chain egress {
type filter hook egress device eth1 priority 0;
ip daddr 255.255.255.255 meta priority set 0:6 comment "Set CoS value to 6 for DHCPv4 packets"
ip6 daddr ff02::1:2 meta priority set 0:6 comment "Set CoS value to 6 for DHCPv6 packets"
}
}
J'ai testé ça à l'air OK.
04:17:37.253275 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 444: vlan 832, p 6, ethertype IPv4 (0x0800), (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 426)
La partie importante p 6 (sans ça c'est en p 0).
Je vais comparé avec un export des packets sous wireshark (meilleurs visualisation)
-
Wep c'est bon. Par contre il y a un petit souci. L'interface n'étant pas encore existante au démarrage mais aussi au start du service NFT, il n'est donc pas possible de directement placer la config nftable dans /etc/nftables.conf
Il faut l'injecter dans la phase up du vlan832, juste avant de faire les req DHCP. Il faut aussi delete les rules sur le down de l'interface.
-
Voila le code pour l'injection
nft add "table netdev filter"
nft add "chain netdev filter egress { type filter hook egress device vlan832 priority 0; }"
nft insert "rule netdev filter egress ip daddr 255.255.255.255 meta priority set 0:6 comment \"Set CoS value to 6 for DHCPv4 packets\""
nft insert "rule netdev filter egress ip6 daddr ff02::1:2 meta priority set 0:6 comment \"Set CoS value to 6 for DHCPv6 packets\""
Changez vlan832 par l'interface correspondant au vlan 832.
EDIT:
Encore mieux avec
table netdev filter {
chain egress {
type filter hook egress device eth1 priority 0;
udp dport { 67, 547 } meta priority set 0:6 comment "Set CoS value to 6 for DHCPv4/v6 packets"
}
}
nft insert "rule netdev filter egress udp dport { 67, 547 } meta priority set 0:6 comment \"Set CoS value to 6 for DHCPv4/v6 packets\""
-
Bonjour,
pour moi c'est pas bon entièrement. ça marchera pour la première demande de bail, mais pour le renouvellement, c'est mort, à moins de rajouter l'ip de notre BNG orange en plus
-
Bonjour,
pour moi c'est pas bon entièrement. ça marchera pour la première demande de bail, mais pour le renouvellement, c'est mort, à moins de rajouter l'ip de notre BNG orange en plus
Comment ça, de rajouter l'ip de "notre BNG" ?
Les rules nftable reste tant qu'elles ne sont pas delete. Je vois pas comment un renew ne fonctionnerait pas. Sauf si un packet DHCP renew n'utilise pas le port udp 67/547
-
re,
Au temps pour moi, j'étais rester sur l'adresse 255.255.255.255 dans la rule. j'avais pas fait attention qu'il y a juste les ports dests dans le dernier exemple.
du coup, désolé pour le bruit :)
-
Du coup je maj mon wiki / github bypass orange sur debian pour virer tout les référence a cgroup/cgexec.
Plus besoin de TC, cgroup ou de patch DHCP client. Amen.
-
@Mastah : Merci ! :D
-
Petite remarque. Il est tjrs nécessaire de set un egress 6:6.
up ip l s $IFACE type vlan egress 6:6
-
@basilix, si tu mets en place, peux-tu me confirmer que c'est aussi OK pour toi ?
Ca me permettra d'être sur de pouvoir update mon repo git pour le bypass debian.
-
@Mastah :
Je pense que je ne pourrais pas confirmer avant le week-end prochain. Mon routeur peut fonctionner avec Debian. Par facilité, j'ai choisi d'utiliser OpenWrt.
Normalement, le résultat devrait rester valide puisque le pare-feu intégré à OpenWrt est également basé sur nftables. En rapportant ma configuration sur le
fil de discussion de OpenWrt (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/) il y aurait d'autant plus de personnes qui pourraient signaler, en cas de problème. J'aurais bien aimé aller plus vite mais il ne
faut pas confondre vitesse et précipitation. Vu que je suis encore débutant...
Je rapporterais également le résultat dans ce fil discussion.
-
Salut,
on pourrait faire ca pour prendre en compte le DSCP non ?
chain egress {
type filter hook egress devices = $iface_wan priority 0;
udp dport { 67, 547 } meta priority set 0:6 ip dscp set cs6 comment "egress_prio_orange_DHCP"
}
Si j'ai bien compris, plus besoin d'autre chose que nftables pour que le DHCP client fonctionne correctement avec orange ?
Finalement, la version complète donnerait cela :
# ipv4 (for renew)
table ip mangle {
chain prio_orange {
udp sport 68 udp dport 67 meta priority set 0:6 ip dscp set cs6 counter comment "mangle-prio_orange_DHCP"
}
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
oifname $iface counter jump prio_orange comment "mangle-postrouting_orange"
}
}
# ipv6
table ip6 mangle {
chain prio_orange {
icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 counter comment "mangle6-prio_orange_ICMP"
udp sport 546 udp dport 547 meta priority set 0:6 ip6 dscp set cs6 counter comment "mangle6-prio_orange_DHCP"
}
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
oifname $iface ip6 daddr { fe80::/10, ff02::/16 } counter jump prio_orange comment "mangle6-postrouting_orange"
}
}
# netdev (for requests ipv4/ipv6)
# note : not tested, need to tryout (tc script could NOT be required anymore)...
table netdev filter {
chain egress {
type filter hook egress devices = $iface_wan priority 0;
udp dport { 67, 547 } meta priority set 0:6 ip dscp set cs6 comment "egress_prio_orange_DHCP"
#udp dport { 67, 547 } meta priority set 0:6 comment "egress_prio_orange_DHCP"
}
}
-
@cyayon : Il semblerait bien.
Avec un peu de chance, je pourrais lancer mon test ce week-end.
-
Il faut aussi pouvoir modifier le PCP des paquets ARP.
Je me demande si le code ci-dessous permet cela ?
table arp filter {
chain output {
type filter hook output priority 0;
oifname vlan832 meta priority set 0:6 comment "Set CoS value to 6 for ARP packets"
}
}
-
@cyayon : Par contre, j'ai un doute sur le fait qu'il faille ajouter la déclaration notrack pour les paquets modifiés. (https://wiki.nftables.org/wiki-nftables/index.php/Mangling_packet_headers#Interactions_with_conntrack)
-
je n'en ai jamais eu besoin. Mais c'est peut etre mieux de l'ajouter.
Cela me semblerait logique et ca allégerait le système.
Je suis actuellement sur mikrotik (plus pour tres longtemps je pense), mais je ne peux pas tester rapidement.
-
Il faut avoir une version récente du noyau Linux (au moins >= 5.16) pour le support du crochet egress.
-
Je suis sous Archlinux (rolling), actuellement 6.9.8…
-
table netdev filter {
chain egress {
type filter hook egress device eth1 priority 0;
udp dport { 67, 547 } meta priority set 0:6 comment "Set CoS value to 6 for DHCPv4/v6 packets"
}
}
Suffit il me semble. Les trames DHCP capturé sont bien en prio 6.
Ou alors c'est pour autre chose que les trames DHCP, si oui, quoi ?
-
Salut,
il me semble qu'il faut que les packets qui doivent être targués COS6 et DSCP 6 :
- DHCP requests/renew (clients ipv4 et ipv6)
- ICMP ipv6 (nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert)
- ARP
Donc, si egress fonctionne (et suffit), il faudrait ça :
define iface_wan1 = <orange_interface_vlan_832>
table netdev filter {
chain egress {
type filter hook egress devices = $iface_wan1 priority 0;
udp dport { 67, 547 } meta priority set 0:6 ip dscp set cs6 counter comment "egress_orange_DHCP"
icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 counter comment "egress_orange_ICMP"
ip6 daddr { fe80::/10, ff02::/16 } meta priority set 0:6 ip6 dscp set cs6 counter comment "egress_orange_LL"
}
}
Questions :
- donc plus besoin de règles mangle ?
- Comment fait-on pour ARP ?
- Est-ce que egress suffit pour les DHCP clients request ET renew ?
-
J'ai envie de dire que seul la règle
table netdev filter {
chain egress {
type filter hook egress device eth1 priority 0;
udp dport { 67, 547 } meta priority set 0:6 comment "Set CoS value to 6 for DHCPv4/v6 packets"
}
}
est importante.
CF l'image. Les résultats sont les mêmes pour les req DHCP ipv6.
Après levieux expliquait effectivement la chose suivante :La COS6 sert à prioriser les pkts DHCP(4/6), ARP et ICMP NS/NA entre la boxe et la BNG (premier routeur qui gère les IPs) qui gère le contexte client.
-
@cyayon :
Les chaînes nftables sont plus ou moins équivalentes aux tables iptables. Néanmoins, nftables est un socle d'application étant plus abstrait que iptables. On modifie l'en-tête des paquets
via une déclaration de la charge utile (payload statement).
payload_expression set value
[18:10] Je me suis trompé ce n'est pas une déclaration de charge utile (payload statement) mais une déclaration meta (meta statement).
meta {mark | priority | pkttype | nftrace | broute} set value
L'expression de la charge utile est le champ de l'en-tête d'un paquet (c.f. man 8 nft).
Pour l'ARP, je me suis aussi posé la question.
Il faut aussi pouvoir modifier le PCP des paquets ARP.
Je me demande si le code ci-dessous permet cela ?
table arp filter {
chain output {
type filter hook output priority 0;
oifname vlan832 meta priority set 0:6 comment "Set CoS value to 6 for ARP packets"
}
}
Cela me paraîtrait logique de changer la priorité d'un paquet ARP dans une table de la famille ARP.
Remarque : On peut écrire meta oifname ou tout simplement oifname dans une expression meta (le mot meta est optionnel).
-
C'est bon j'ai l'ensemble (sauf ARP).
-
DHCPV4/V6 => image 1
RA/RS => image 2
-
J'ai bien Prio 6 sur les req DHCP V et V6, mais aussi prio 6 sur les demandes de router solicitation.
table netdev filter {
chain egress {
type filter hook egress device IFACE_NAME_HERE priority filter; policy accept;
icmpv6 type { nd-router-solicit, nd-neighbor-solicit } meta priority set 0:6 comment "Set CoS value to 6 for RS/RA packets"
udp dport { 67, 547 } meta priority set 0:6 comment "Set CoS value to 6 for DHCPv4/v6 packets"
}
}
J'ai juste a trouver la bonne règle pour les packet arp et c'est good.
Je precise que les packet n'ont pas été capturer sur l'interface vlan 832 mais bien sur la WAN.
La partie "ip6 dscp set cs6" ne change absolument rien sur les packets capturer (avec ou sans les packets sont identique)
De plus les règles sur nd-router-advert et nd-neighbor-advert servent à rien, étant donné que c'est du traffic in et non out (edit: je confirme ça sert a rien, seul nd-router-solicit et nd-neighbor-solicit est utile)
-
tcpdump -vvvvv -ttt -i wan 'icmp6 and (ip6[40] = 134 or ip6[40] = 133 or ip6[40] = 135 or ip6[40] = 136 or ip6[40] = 129 or ip6[40] = 128 or ip6[40] = 3 or ip6[40] = 2 or ip6[40] = 1)' -w /tmp/capture.pcap
unreachable: 1
too-big: 2
time-exceeded: 3
echo-request: 128
echo-reply: 129
router-solicitation: 133
router-advertisement: 134
neighbor-solicitation: 135
neighbor-advertisement: 136
-
Avec les modif. Il manque probablement quelque tram encore.
table netdev filter {
chain egress {
type filter hook egress device "vlan832" priority filter; policy accept;
icmpv6 type { nd-router-solicit, nd-neighbor-solicit } meta priority set 0:6 ip6 dscp set cs6 comment "Set CoS value to 6 for RS/RA packets"
udp dport 547 meta priority set 0:6 ip6 dscp set cs6 comment "Set CoS value to 6 for DHCPv6 packets"
udp dport 67 meta priority set 0:6 ip dscp set cs6 comment "Set CoS value to 6 for DHCPv4 packets"
}
}
-
Du coup ça passe ou ça suffit pas ?
As tu essayé avec ARP ? Je ne me souviens plus si c’est indispensable d’ailleurs…
-
Voici la règle qui est normalement final (sauf oublie)
table netdev filter {
chain egress {
type filter hook egress device "vlan832" priority filter; policy accept;
icmpv6 type { nd-router-solicit, nd-neighbor-solicit } meta priority set 0:6 ip6 dscp set cs6 comment "Set CoS value to 6 for RS/RA packets"
udp dport 547 meta priority set 0:6 ip6 dscp set cs6 comment "Set CoS value to 6 for DHCPv6 packets"
ether type arp meta priority set 0:6 comment "Set CoS value to 6 for arp packets"
udp dport 67 meta priority set 0:6 ip dscp set cs6 comment "Set CoS value to 6 for DHCPv4 packets"
}
}
# Add PCP 6 (802.1Q prio 6)
nft add "table netdev filter"
nft add "chain netdev filter egress { type filter hook egress device IFACE_NAME priority 0; }"
# IPV4
nft insert "rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6 comment \"Set CoS value to 6 for DHCPv4 packets\""
nft insert "rule netdev filter egress ether type arp meta priority set 0:6 comment \"Set CoS value to 6 for arp packets\""
# IPV6
nft insert "rule netdev filter egress udp dport 547 meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 for DHCPv6 packets\""
nft insert "rule netdev filter egress icmpv6 type { nd-router-solicit, nd-neighbor-solicit } meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 for RS/RA packets\""
-
Et les dump montrant les bonnes prio/dscp
Cela respect donc bien les règles Orange:
- DHCPv4v6 issu de la boxe
- ARP issu de la boxe
- ICMPv6 code NS/NA issu de la boxe et à destination de l'ipv6 fe80::ba0:bab
- ICMPv6 code RS issu de la boxe et à destination de l'ipv6 multicast idoine (c'est ba0bab qui répond)
Edit: la trame en prio 0 est a destination de mon LAN donc rien a voir avec orange
-
Salut,
Je ne comprends pas pourquoi on n'a pas besoin de préciser nd-neighbor-advert dans les types ICMPv6 ?
-
@cyayon :
De plus les règles sur nd-router-advert et nd-neighbor-advert servent à rien, étant donné que c'est du traffic in et non out (edit: je confirme ça sert a rien, seul nd-router-solicit et nd-neighbor-solicit est utile)
A l'ICMPv6 code NS/NA (neighbor advertisement) issu de la boxe et à destination de l'ipv6 fe80::ba0:bab.
Bien vu ! Personnellement, je vais l'ajouter dans le (rare ?) cas où notre routeur de prédilection émette un message d'annonce de voisin.
-
@cyayon :
Bien vu ! Personnellement, je vais l'ajouter dans le (rare ?) cas où notre routeur de prédilection émette un message d'annonce de voisin.
Pareil, merci pour le retour
-
Salut,
Je ne comprends pas pourquoi on n'a pas besoin de préciser nd-neighbor-advert dans les types ICMPv6 ?
Ca ne sert a rien, tu n'es pas un router mais un client. En aucun cas tu vas émettre des packets de type RA/NA. Les seules packet qui vont être émis en tant que client c'est RS/NS.
RA: Router Advertisment
NA: Neighbor Advertisment
RS: Router solicitation
NS: Neighbor solicitation
RS — Router Solicitation (ICMPv6 type 133)
When an interface becomes enabled, hosts may send out RSes that request that routers generate Router Advertisements (RAs) immediately rather than at their next scheduled time.
RA — Router Advertisement (ICMPv6 type 134)
Routers advertise their presence together with various link and Internet parameters either periodically, or in response to an RS message. RAs contain prefixes that are used for determining whether another address shares the same link (on-link determination) and/or address configuration, a suggested hop limit value, and so forth.
NS — Neighbor Solicitation (ICMPv6 type 135)
A Neighbor Solicitation (NS) message is sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. NSes are also used for Duplicate Address Detection (DAD).
NA — Neighbor Advertisement (ICMPv6 type 136)
A Neighbour Advertisement (NA) message is sent in response to an NS message. A node may also send unsolicited NAs to announce a link-layer address change.
-
Au cas ou je vais quand même faire une capture sur une longue durée et vérifier que des NA partent pas du wan vers orange.
-
A node sends Neighbor Advertisements in response to Neighbor Solicitations and sends unsolicited Neighbor Advertisements in order to (unreliably) propagate new information quickly.
As the main purpose of sending unsolicited NAs upon configuring a new address is to proactively create a Neighbor Cache entry on the first-hop routers, the gratuitous NAs are sent to the all-routers multicast address (ff02::2).
On peut supposer que cela a son importance sinon @levieuxatorange n'aurait pas indiqué que c'était nécessaire.
-
Je viens de verif il faut effectivement aussi tag les NA en cos6 / dscp cs6
Solution pour modifier les trames
- COS6: DHCP v4&v6 / ARP / ICMP 6 (RS/NS/NA)
- DSCP cs6: DHCP v4&v6 / ICMP 6 (RS/NS/NA)
table netdev filter {
chain egress {
type filter hook egress device "IFACE_NAME" priority filter; policy accept;
icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 comment "Set CoS value to 6 for RS/RA packets"
udp dport 547 meta priority set 0:6 ip6 dscp set cs6 comment "Set CoS value to 6 for DHCPv6 packets"
ether type arp meta priority set 0:6 comment "Set CoS value to 6 for arp packets"
udp dport 67 meta priority set 0:6 ip dscp set cs6 comment "Set CoS value to 6 for DHCPv4 packets"
}
}
# Add PCP 6 (802.1Q prio 6)
nft add "table netdev filter"
nft add "chain netdev filter egress { type filter hook egress device IFACE_NAME priority 0; }"
# IPV4
nft insert "rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6 comment \"Set CoS value to 6 for DHCPv4 packets\""
nft insert "rule netdev filter egress ether type arp meta priority set 0:6 comment \"Set CoS value to 6 for arp packets\""
# IPV6
nft insert "rule netdev filter egress udp dport 547 meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 for DHCPv6 packets\""
nft insert "rule netdev filter egress icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 for RS/RA packets\""
(https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/?action=dlattach;attach=146586;image)
(https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/?action=dlattach;attach=146588;image)
(https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/?action=dlattach;attach=146590;image)
(https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/?action=dlattach;attach=146592;image)
Plus d'excuses possible pour ne pas bypass proprement.
-
Chaque nœud actualise aussi périodiquement son cache des voisins en émettant des messages de sollicitation de voisin (Neighbor Unreachability Detection: NUD).
-
pourquoi ne pas appliquer tout ICMPv6 vers fe00::/7 (fe80::/10 + ff02::/16) ? sur Mikrotik, on fait comme ca.
avec netdev/egress peut-on appliquer sur la destination ?
EDIT : je ne sais pas si cela produit le bon résultat, mais cette syntaxe est correcte
nft insert "rule netdev filter egress icmpv6 daddr { fe00::/7 } meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress_prio_orange_ICMP6\""
-
SLAAC et DHCPv6 reposent sur le protocole NDP (NS, NA, RS, RA...) pour obtenir une adresse IP. Le protocole NDP impose la création d'une adresse locale au lien sur chaque interface du nœud.
C'est la première étape pour attribuer une adresse IP. En l'occurence, NDP est un sous-ensemble de messages ICMPv6. Les messages DHCPv6 sont également émis avec une adresse multicast.
Le préfixe fe00::/7 inclut les préfixes s'étendant de la plage fe00::/8 jusqu'à ff00::/8 donc il inclut le préfixe fe80::/10 (toutes les adresses locales au lien (LLA)) et ff00::/8
(c'est-à-dire toutes les adresses multicast).
[12:43] Les messages NA NS sont envoyés avec une adresse de destination multicast fabriquée à partir de chaque interface.
-
Donc, en principe, cela ne donne pas un grand sens de préciser le préfixe. Les messages ICMPv6 sont renvoyés à un nœud du réseau ayant émis un message pour spécifier une
erreur ou une fournir une indication.
-
Donc, en principe, cela ne donne pas un grand sens de préciser le préfixe. Les messages ICMPv6 sont renvoyés à un nœud du réseau ayant émis un message pour spécifier une
erreur ou une fournir une indication.
Merci pour ta réponse complète.
Sur mikrotik, on utilise des "switch rules", on ne peut pas préciser le type d'icmpv6. Le workaround est alors d'utiliser la destination, d'où l'utilisation du prefix.
D'après ma compréhension, ca doit aussi fonctionner non (même si peu d'interêt vis à vis de l'autre méthode en précisant le type icmpv6) ? En tout cas sur Mikrotik ca fonctionne...
-
@cyayon :
On peut prendre les choses sous divers angles. Mais pour obtenir les informations d'auto-configuration permettant d'établir une connexion IPv6 sur le réseau Orange, ce n'est pas nécessaire.
Les adresses incluses dans le préfixe fe00::/7 correspondent à une multitude d'adresses qui ne seront jamais utilisées par le routeur. En définitif, le sélecteur par IP ne permet pas de
sélectionner les paquets de façon mieux définie que sans. En d'autres termes, on aura exactement les mêmes paquets qui correspondront à ces deux règles.
[15:34] Je me suis mélangé les pinceaux. C'est le message NS qui est envoyé à l'adresse multicast sollicitée.
-
Merci.
-
Je recommande le MOOC « Objectif IPv6 » pour les gens qui veulent découvrir IPv6. La nouvelle date d'ouverture du MOOC est en septembre.
Il faut quand même avoir des connaissances en réseaux pour suivre ce MOOC mais il est vraiment bien conçu.
-
Levieux étant aussi assez explicite dans les type de packet devant ou non être en cos6 / dscp cs6 autant se servir de ces règles là, et pas autre chose. C'est ce que je fais sur les règles nftable.
@basilix peux-tu mettre a jour ton premier message en indiquant que la solution est ce lien : https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/msg1079566/#msg1079566
Ça évitera à la terre entière de lire 50 pages avant d'avoir une réponse. Comme c'est le cas partout sur ce forum, où il faut lire 200pages :D
-
@Mastah :
J'ai engrangé beaucoup de retard à vouloir automatiser et comprendre ma configuration. Je fais mon expérimentation ce week-end.
Mais je constate qu'il y a déjà plusieurs choses qui ne fonctionnent pas avec mon routeur.
-
Salut,
Qu’est ce qui ne fonctionne pas et avec quelle config ?
-
@cyayon :
C'est ma configuration OpenWrt qui ne fonctionne pas.
Mon ONU FS semble parvenir à créer le lien optique avec l'OLT. Mais il y a un avertissement qui apparaît dans le journal système.
sfp sfp-1: please wait, module slow to respond
J'ai un message d'erreur par rapport à ma table netdev. Il faudrait que je vérifie si il apparaît lorsque la fibre optique est branchée au module optique.
Je crois qu'il pourrait y avoir des effets de bords à cause d'une mauvaise configuration de mon client DHCPv6. Je vais corriger si je peux et vérifier à nouveau.
Ces erreurs sont sûrement entrelacées. J'avais une erreur de configuration de mon client DHCPv4 qui empêchait d'émettre le paquet DHCP Discover. Ensuite,
le tag VLAN n'apparaît pas dans la trame encapsulant ce paquet DHCP.
-
Alors il s'avère que le client DHCPv6 avait une option mal formée et cela remplissait tout l'espace dans le journal.
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 11.731222] Backport generated by backports.git v6.1.97-1-29-gf1d24a3683b2
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 11.742630] sfp sfp-1: Host maximum power 3.0W
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 11.747690] sfp sfp-2: Host maximum power 3.0W
Tue Jul 23 22:03:08 2024 user.info kernel: [ 11.840893] urngd: v1.0.2 started.
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 12.212478] mt798x-wmac 18000000.wifi: HW/SW Version: 0x8a108a10, Build Time: 20221012174743a
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 12.212478]
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 12.345696] mt798x-wmac 18000000.wifi: WM Firmware Version: ____000000, Build Time: 20221012174805
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 12.450033] mt798x-wmac 18000000.wifi: WA Firmware Version: DEV_000000, Build Time: 20221012174937
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 12.555482] mt798x-wmac 18000000.wifi: registering led 'mt76-phy0'
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 12.563186] mt798x-wmac 18000000.wifi: registering led 'mt76-phy1'
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 15.220534] PPP generic driver version 2.4.2
Tue Jul 23 22:03:08 2024 kern.info kernel: [ 15.225518] NET: Registered PF_PPPOX protocol family
Tue Jul 23 22:03:08 2024 user.info kernel: [ 15.232371] kmodloader: done loading kernel modules from /etc/modules.d/*
Tue Jul 23 22:03:08 2024 kern.warn kernel: [ 15.653380] sfp sfp-1: please wait, module slow to respond
Tue Jul 23 22:03:13 2024 authpriv.info dropbear[1735]: Not backgrounding
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: In file included from /dev/stdin:260:1-39:
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: /etc/custom-netdev-table.nft:6:41-57: Error: No such file or directory; did you mean chain ‘egress’ in table netdev ‘filter’?
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: type filter hook egress device "eth1.832" priority filter; policy accept;
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: ^^^^^^^^^^^^^^^^^
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: In file included from /dev/stdin:260:1-39:
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: /etc/custom-netdev-table.nft:5:15-20: Error: Could not process rule: No such file or directory
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: chain egress {
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: ^^^^^^
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: In file included from /dev/stdin:260:1-39:
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: /etc/custom-netdev-table.nft:5:15-20: Error: Could not process rule: No such file or directory
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: chain egress {
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: ^^^^^^
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: In file included from /dev/stdin:260:1-39:
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: /etc/custom-netdev-table.nft:5:15-20: Error: Could not process rule: No such file or directory
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: chain egress {
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: ^^^^^^
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: In file included from /dev/stdin:260:1-39:
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: /etc/custom-netdev-table.nft:5:15-20: Error: Could not process rule: No such file or directory
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: chain egress {
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: ^^^^^^
Tue Jul 23 22:03:14 2024 user.notice : Added device handler type: bonding
Tue Jul 23 22:03:14 2024 user.notice : Added device handler type: 8021ad
Tue Jul 23 22:03:14 2024 user.notice : Added device handler type: 8021q
Tue Jul 23 22:03:14 2024 user.notice : Added device handler type: macvlan
Tue Jul 23 22:03:14 2024 user.notice : Added device handler type: veth
Tue Jul 23 22:03:14 2024 user.notice : Added device handler type: bridge
Tue Jul 23 22:03:14 2024 user.notice : Added device handler type: Network device
Tue Jul 23 22:03:14 2024 user.notice : Added device handler type: tunnel
Tue Jul 23 22:03:14 2024 daemon.notice procd: /etc/rc.d/S25packet_steering: pid 340's current affinity list: 0-3
Tue Jul 23 22:03:14 2024 daemon.notice procd: /etc/rc.d/S25packet_steering: pid 340's new affinity list: 0
Wep c'est bon. Par contre il y a un petit souci. L'interface n'étant pas encore existante au démarrage mais aussi au start du service NFT, il n'est donc pas possible de directement placer la config nftable dans /etc/nftables.conf
Il faut l'injecter dans la phase up du vlan832, juste avant de faire les req DHCP. Il faut aussi delete les rules sur le down de l'interface.
Dans mon cas, je croyais que OpenWrt aurait pu résoudre ce problème de façon automatique.
-
Peut-être qu'il suffirait de remplacer eth1.832 par eth1 ? À voir.
-
Ton problème c'est surtout que nftable se lance avant la couche iface et donc ton iface n'existe pas encore lorsqu'il démarre. D'où l'erreur.
Et c'est bien sur l'iface vlan qu'il faut placer la règle.
C'est pour ça que j'ai aussi ajouter le script d'inject rules, car dans les fait c'est la seule manière de config nftable une fois que l'iface vlan à été créé.
Je voulais t'expliquer ça sur discord, mais tu sembles vouloir tout compliquer :p
# WAN
auto wan
allow-hotplug wan
iface wan inet manual
# VLAN832
auto vlan832
allow-hotplug vlan832
iface vlan832 inet manual
# Bind vlan
vlan-raw-device wan
# LiveBox mac address
hw-mac-address XX:XX:XX:XX:XX:XX
# Wait for ONU to be UP
up /etc/network/wait_for_wan_v2 wan
# Reload NFTable
up nft -f /etc/nftables.conf
# Add nftable PCP 6 / 802.1Q prio 6 on egress DHCPv4/v6 packet
up /etc/network/inject_pcp_6
# Add nftable fastpath rules
up /etc/network/inject_flowtable_fastpath
# Generate Orange Options (user-class, vendor-class, option 90)
up /etc/dhcp/dhclient-orange-generator
# Egress prio 6:6 (aka VLAN-PCP)
up ip l s $IFACE type vlan egress 6:6
up sleep 2
# DHCP Up
up dhclient -4 -i $IFACE -cf /etc/dhcp/dhclient-orange-v4.conf -df /var/lib/dhcp/dhclient-orange-v4.duid -lf /var/lib/dhcp/dhclient-orange-v4.lease -v
up sleep 2
up dhclient -6 -P -D LL -i $IFACE -cf /etc/dhcp/dhclient-orange-v6.conf -df /var/lib/dhcp/dhclient-orange-v6.duid -lf /var/lib/dhcp/dhclient-orange-v6.lease -e interface_internal="$IFACE:01 lan:02" -v
# DHCP Down
down dhclient -6 -P -D LL -i $IFACE -cf /etc/dhcp/dhclient-orange-v6.conf -df /var/lib/dhcp/dhclient-orange-v6.duid -lf /var/lib/dhcp/dhclient-orange-v6.lease -e interface_internal="$IFACE:01 lan:02" -v -r
down sleep 2
down dhclient -4 -i $IFACE -cf /etc/dhcp/dhclient-orange-v4.conf -df /var/lib/dhcp/dhclient-orange-v4.duid -lf /var/lib/dhcp/dhclient-orange-v4.lease -v -r
=> # Add nftable PCP 6 / 802.1Q prio 6 on egress DHCPv4/v6 packet
-
@Mastah :
C'est l'informatique qui est complexe.
Il y a des choses incohérentes que je n'arrive pas à expliquer.
1. On peut changer la priorité interne des paquets dans une table de la famille netdev.
Car c'est un développeur Netfilter ayant intégré cette fonctionnalité egress dans le
noyau Linux qui le fait.
2. Les règles dans ma table « netdev filter » parviennent à modifier le DSCP des paquets
de type 802.1Q mais pas leur PCP (plusieurs déclarations nftables dans la même règle).
table netdev filter {
chain egress {
type filter hook egress device eth1 priority 0;
udp dport 547 meta priority set 0:6 ip6 dscp set cs6
}
}
3. La règle DHCPv6 définie dans une chaîne au crochet postrouting (hook) parvient à modifier le
DSCP et le PCP des paquets DHCPv6 Discover.
Donc, la correspondance priorité interne des paquets --> VLAN PCP est appliquée.
4. Pourquoi définir un filtrage sur l'interface 802.1Q alors qu'on peut filtrer avec l'interface eth1 ?
NETDEV ADDRESS FAMILY
The Netdev address family handles packets from the device ingress and egress path. This family allows you to filter packets of any ethertype
such as ARP, VLAN 802.1q, VLAN 802.1ad (Q-in-Q) as well as IPv4 and IPv6 packets.
-
Ton problème c'est surtout que nftable se lance avant la couche iface
Il y a ce genre de limitation dans nftables ?
Si c’est le cas c’est clairement une régression comparé à iptables où il est tout à fait possible de faire référence à une interface qui n’existe pas encore…
-
@Mastah :
Le problème que j'ai mentionné a disparu lorsque j'ai spécifié l'interface eth1 à la place de eth1.832. (https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/msg1080897/#msg1080897)
Tue Jul 23 22:03:13 2024 daemon.notice procd: /etc/rc.d/S19firewall: /etc/custom-netdev-table.nft:6:41-57: Error: No such file or directory; did you mean chain ‘egress’ in table netdev ‘filter’?
-
Pour moi, il s'agirait d'un bogue. Je tente un dernier test sans trop d'espoir...
-
Non c'est pas un bug.
nftable est stateless lorsque tu écris des règles avec le nom d'une interface dans la règles, mais lorsque tu crées une règle SUR l'interface il faut que celle-ci existe. C'est exactement la même chose avec iptable.
-
@Mastah :
Mais dans mon cas, je te confirme que mes règles dans la table « netdev » sont appliquées.
Donc, cela n'explique toujours pas pourquoi le DSCP est modifié par ces règles mais pas le PCP (tel qu'indiqué par
tcpdump). En outre, je trouve bizarre de filtrer sur l'interface eth1.802 alors que la page de manuel de nft
indique qu'on peut filtrer des paquets de type VLAN 802.1Q.
-
Probablement parce que le kernel de openwrt est soit pas complément config, ne support pas encore les nouveau ajout etc ...
Je ne me rappel plus à partir de quel version du kernel c'est dispo.
Et c'est bien sur le vlan qu'il faut faire les modif, pas phy wan
-
@Mastah :
C'est disponible à partir de la version 16.
Oui, mais les incohérences persistent.
De plus, la documentation me fait penser que des paquets différents peuvent être filtrés au sein de la même table.
NETDEV ADDRESS FAMILY
The Netdev address family handles packets from the device ingress and egress path. This family allows you to filter packets of any ethertype
such as ARP, VLAN 802.1q, VLAN 802.1ad (Q-in-Q) as well as IPv4 and IPv6 packets.
Les tables dans nftables ne sont que des conteneurs de chaînes. Il est vrai que ce sont les chaînes qui définissent le « paramètre » device. On pourrait donc
penser qu'il faille définir plusieurs chaînes avec des interfaces différentes : e.g. eth1 et eth1.832.
Mais pourquoi mes règles relatives à l'interface eth1 parviennent à modifier le DSCP des paquets encapsulés dans les trames de type 802.1Q ?
Pourquoi le PCP des paquets DHCPv6 Discover est modifiable par une règle similaire mais située dans le crochet (hook) postrouting lequel
est appliqué avant le crochet egress ?
-
De mon coté, et comme montrer sur les captures tcpdump au niveau de l'interface physique wan, c'est fonctionnel.
Peut-être une limitation wrt, un bug wrt, autre chose qui pose souci... Aucune idée.
Pourrais-tu aussi ajouter les url des doc, au lieu de simplement mettre une quote ? Plus simple pour chercher.
-
@Mastah :
https://www.mankier.com/8/nft#Address_Families-Netdev_Address_Family
J'aurais peut-être une explication dans le courant de la semaine.
-
De mon coté, et comme montrer sur les captures tcpdump au niveau de l'interface physique wan, c'est fonctionnel.
Peut-être une limitation wrt, un bug wrt, autre chose qui pose souci... Aucune idée.
Pourrais-tu aussi ajouter les url des doc, au lieu de simplement mettre une quote ? Plus simple pour chercher.
Salut,
Tu appliques netdev / egress sur l'interface physique (eth1 par exemple) ?
Je pensais qu'il fallait appliquer sur l'interface vlan (832) ...
-
Salut,
Tu appliques netdev / egress sur l'interface physique (eth1 par exemple) ?
Je pensais qu'il fallait appliquer sur l'interface vlan (832) ...
Pour être propre il faut le faire sur l'interface vlan et non physique.
Mais pour faire ça il faut que le "device" vlan existe avant d'appliquer la règle nftable. C'est pour ça qu'il faut que ça soit des règles nftable injecté et non chargé au boot.
-
Ok, c'est bien ce que j'avais compris.
Si ca peut aider, j'ai créé un service systemd (je suis sous archlinux, mais ca doit le faire sur les autres distribs utilisant systemd-network).
C'est juste pour injecter les bonnes rules à la création de l'interface et que le DHCP Client (systemd-network aussi), passe.
Je n'ai pas encore tester mais ca devrait fonctionner. Attention, il faut bien sûr conserver les rules netdev dans les règles firewall...
/etc/systemd/system/netdev-egress@.service
[Unit]
Description=netdev-egress pre-requisite for %i
After=network.target network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStartPre=/usr/lib/systemd/systemd-networkd-wait-online --interface=%i --operational-state=off --timeout=8
ExecStart=/etc/systemd/scripts/netdev-egress %i
RemainAfterExit=yes
TimeoutSec=10
/etc/systemd/scripts/netdev-egress :
#!/bin/sh
# apply netdev/egress priority for orange dhcp client requests
# Version 20240717
SleepRetry=3
# set orange interface
if [ -z "$1" ] ; then
iface="orange1"
else
iface="$1"
fi
echo "executing nft chain netdev filter egress device $iface"
ip link show dev $iface
if [ $? -ne 0 ] ; then
echo "ERROR : interface $iface not exist, retrying in ${SleepRetry}s..."
sleep $SleepRetry
ip link show dev $iface ; [ $? -ne 0 ] && echo "ERROR : interface $iface definitely not exist !" && exit 9
fi
echo "executing nft chain netdev filter egress device $iface"
echo ; echo "existing table netdev filter"
nft list table netdev filter
echo ; echo "applying nft chain netdev filter egress $iface"
nft add "table netdev filter"
nft add "chain netdev filter egress { type filter hook egress devices = { ${iface} } priority 0; }"
nft insert "rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6 counter comment \"egress_prio_${iface}_DHCP4\""
nft insert "rule netdev filter egress ether type arp meta priority set 0:6 counter comment \"egress_prio_${iface}_ARP\""
nft insert "rule netdev filter egress udp dport 547 meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress_prio_${iface}_DHCP6\""
nft insert "rule netdev filter egress icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress_prio_${iface}_ICMP6\""
#nft insert "rule netdev filter egress icmpv6 daddr { fe00::/7 } meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress_prio_${iface}_ICMP6\""
echo ; echo "final nft table netdev filter"
nft list table netdev filter
echo ; echo "networkctl renew $iface"
networkctl renew $iface
echo ; echo "networkctl status $iface"
networkctl -s status $iface
-
Question annexe, certes il faudrait faire ça sur lninterface vlan, mais est-ce que cela fonctionne si on fait ça sur l’interface physique (juste pour le boot) ?
-
Question annexe, certes il faudrait faire ça sur lninterface vlan, mais est-ce que cela fonctionne si on fait ça sur l’interface physique (juste pour le boot) ?
Possible, à tester. Le souci c'est que tu tags en prio 6 autre que juste le trafique sur 832.
Si les autres services (téléphone, tv, ...) utilise aussi de la prio mais pas 6, bah tu tags quand même en 6.
De mon côté ne me souciant pas du tout du reste, je ne peux répondre. Peut-être que c'est le cas, peut-être pas.
-
Merci
-
Merci
Cependant il y a peut-être moyen de modifier la règle, pour la placer sur WAN et check si la trame est taggué VLAN832 en plus du reste.
-
La page de manuel de nft exposerait potentiellement des fonctionnalités qui n'ont pas encore été implémenté.
- Le crochet egress dans la famille netdev a été ajouté récemment par rapport au crochet ingress.
- L'implémentation du crochet egress avait été annoncé pour la v. 5.7 et finalement ajouté à la v. 5.16 (https://unix.stackexchange.com/a/712930).
- « L'information dans l'en-tête des trames n'est disponible que dans le chemin en entrée (https://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_headers#Matching_ethernet_headers). » (src : wiki)
Ce qui n'est plus tout à fait juste, avec une « propagation des expressions » dans plusieurs crochets. - La nouvelle version de nftables (v. 1.1.0 : 16 juillet 2024) intègre du support pour les VLAN (https://lwn.net/Articles/982283/).
- Il y a vraisemblablement de multiples incohérences au niveau des fonctionnalités.
Cela peut amener à penser que l'on se trouve éventuellement dans une phase de transition.
Cela me laisse plutôt songeur.
# payload statement
ip saddr 10.1.1.1 icmp type echo-request vlan id set 321
-
Intéressant tout ça…
Ça signifie qu’on pourrait appliquer la COS sans avoir à préciser l’interface mais uniquement le VLAN.
ether type 8021ad vlan id 832 …
-
@cyayon :
La documentation sur le sujet manque terriblement. Il faut chercher dans les sources et faire des hypothèses.
The Netfilter project proudly presents:
nftables 1.1.0
... after a release cycles of 8 months.
Je suppose que l'auteur fait référence à l'extrait de code du fichier tests/shell/testcases/packetpath/vlan_mangling (http://git.netfilter.org/nftables/commit/?id=3f3c70948f451127d06afb23e2221ed7e17eb977).
#!/bin/bash
rnd=$(mktemp -u XXXXXXXX)
ns1="nft1ifname-$rnd"
ns2="nft2ifname-$rnd"
cleanup()
{
ip netns del "$ns1"
ip netns del "$ns2"
}
trap cleanup EXIT
set -e
ip netns add "$ns1"
ip netns add "$ns2"
ip -net "$ns1" link set lo up
ip -net "$ns2" link set lo up
ip link add veth0 netns $ns1 type veth peer name veth0 netns $ns2
ip -net "$ns1" link set veth0 addr da:d3:00:01:02:03
ip -net "$ns1" link add vlan123 link veth0 type vlan id 123
ip -net "$ns2" link add vlan321 link veth0 type vlan id 321
for dev in veth0 ; do
ip -net "$ns1" link set $dev up
ip -net "$ns2" link set $dev up
done
ip -net "$ns1" link set vlan123 up
ip -net "$ns2" link set vlan321 up
ip -net "$ns1" addr add 10.1.1.1/24 dev vlan123
ip -net "$ns2" addr add 10.1.1.2/24 dev vlan321
ip netns exec "$ns2" $NFT -f /dev/stdin <<"EOF"
table netdev t {
chain in_update_vlan {
vlan type arp vlan id set 321 counter
ip saddr 10.1.1.1 icmp type echo-request vlan id set 321 counter
}
chain in {
type filter hook ingress device veth0 priority filter;
ether saddr da:d3:00:01:02:03 vlan id 123 jump in_update_vlan
}
chain out_update_vlan {
vlan type arp vlan id set 123 counter
ip daddr 10.1.1.1 icmp type echo-reply vlan id set 123 counter
}
chain out {
type filter hook egress device veth0 priority filter;
ether daddr da:d3:00:01:02:03 vlan id 321 jump out_update_vlan
}
}
EOF
ip netns exec "$ns1" ping -c 1 10.1.1.2
set +e
ip netns exec "$ns2" $NFT list ruleset
ip netns exec "$ns2" $NFT list table netdev t | grep 'counter packets' | grep 'counter packets 0 bytes 0'
if [ $? -eq 1 ]
then
exit 0
fi
exit 1
[12:30] C'est très probable effectivement.
Attachment: changes-nftables-1.1.0.txt (type=text/plain)
[...]
Pablo Neira Ayuso (101):
[...]
tests: shell: add vlan mangling test case
-
ip -net "$ns1" link add vlan123 link veth0 type vlan id 123
ip link add - add virtual link
link DEVICE
specifies the physical device to act operate on.
NAME specifies the name of the new virtual device.
Source : man ip-link (https://www.mankier.com/8/ip-link#Description-ip_link_add_-_add_virtual_link)
-
Bon après, faut pas non plus en faire une usine à gaz….
Perso, j’ai mon ONU dans un petit switch CRS310 Mikrotik, il fait la COS sur les paquets qui vont bien, et je gère le DHCP client sur mon routeur.
Le switch Mikrotik fait la COS au niveau hardware. De tout manière, il faut bien un slot pour accueillir l’ONU…
-
@cyayon :
Mon message précédent n'est pas très clair. Je n'ai pas eu le temps d'ajouter une explication.
Dans le test, on crée deux espaces de noms réseaux avec des périphériques virtuels. On cherche à simuler un échange entre deux interfaces.
On réalise un test de connectivité avec des requêtes ICMP echo. On modifie les identifiants VLAN des paquets de façon à ce que les interfaces
puissent communiquer. Car les interfaces 802.1Q vlan123 et vlan321 ont respectivement les identifiants 123 et 321.
Or on remarque que le device spécifié dans la chaîne egress est veth0. En lisant le code attentivement, on s'aperçoit que cela correspond à
l'interface physique. Malheureusement, je n'ai pas réussi à modifier le PCP des paquets via le test vlan_mangling avec la déclaration VLAN
pcp set 6.
-
#!/bin/bash
NFT=/usr/bin/nft
rnd=$(mktemp -u XXXXXXXX)
ns1="nft1ifname-$rnd"
ns2="nft2ifname-$rnd"
cleanup()
{
ip netns del "$ns1"
ip netns del "$ns2"
}
trap cleanup EXIT
set -e
ip netns add "$ns1"
ip netns add "$ns2"
ip -net "$ns1" link set lo up
ip -net "$ns2" link set lo up
ip link add veth0 netns $ns1 type veth peer name veth0 netns $ns2
ip -net "$ns1" link set veth0 addr da:d3:00:01:02:03
ip -net "$ns1" link add vlan1 link veth0 type vlan id 123
ip -net "$ns2" link add vlan2 link veth0 type vlan id 123
for dev in veth0 ; do
ip -net "$ns1" link set $dev up
ip -net "$ns2" link set $dev up
done
ip -net "$ns1" link set vlan1 up
ip -net "$ns2" link set vlan2 up
ip -net "$ns1" addr add 10.1.1.1/24 dev vlan1
ip -net "$ns2" addr add 10.1.1.2/24 dev vlan2
ip netns exec "$ns2" $NFT -f /dev/stdin <<"EOF"
table netdev t {
chain in_update_vlan {
vlan type arp vlan pcp set 6 counter
ip saddr 10.1.1.1 icmp type echo-request vlan pcp set 6 counter
}
chain in {
type filter hook ingress device veth0 priority filter;
ether saddr da:d3:00:01:02:03 vlan id 123 jump in_update_vlan
}
chain out_update_vlan {
vlan type arp vlan pcp set 123 counter
ip daddr 10.1.1.1 icmp type echo-reply vlan pcp set 6 counter
}
chain out {
type filter hook egress device veth0 priority filter;
ether daddr da:d3:00:01:02:03 vlan id 123 jump out_update_vlan
}
}
EOF
ip netns exec "$ns1" ping -c 1 10.1.1.2
set +e
ip netns exec "$ns2" $NFT list ruleset
ip netns exec "$ns2" $NFT list table netdev t | grep 'counter packets' | grep 'counter packets 0 bytes 0'
if [ $? -eq 1 ]
then
exit 0
fi
exit 1
En modifiant le code, j'ai commis une erreur.
chain out_update_vlan {
vlan type arp vlan pcp set 123 counter
ip daddr 10.1.1.1 icmp type echo-reply vlan pcp set 6 counter
}
/dev/stdin:13:30-32: Error: Value 123 exceeds valid range 0-7
vlan type arp vlan pcp set 123 counter
^^^
Cela semblerait indiquer que l'on puisse modifier le PCP.
Mais on voit bien que le résultat est négatif.
PING 10.1.1.2 (10.1.1.2) 56(84) octets de données.
64 octets de 10.1.1.2 : icmp_seq=1 ttl=64 temps=0.033 ms
--- statistiques ping 10.1.1.2 ---
1 paquets transmis, 1 reçus, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.033/0.033/0.033/0.000 ms
table netdev t {
chain in_update_vlan {
vlan type arp vlan pcp set 6 counter packets 0 bytes 0
ip saddr 10.1.1.1 icmp type echo-request vlan pcp set 6 counter packets 0 bytes 0
}
chain in {
type filter hook ingress device "veth0" priority filter; policy accept;
ether saddr da:d3:00:01:02:03 vlan id 123 jump in_update_vlan
}
chain out_update_vlan {
vlan type arp vlan pcp set 6 counter packets 0 bytes 0
ip daddr 10.1.1.1 icmp type echo-reply vlan pcp set 6 counter packets 0 bytes 0
}
chain out {
type filter hook egress device "veth0" priority filter; policy accept;
ether daddr da:d3:00:01:02:03 vlan id 123 jump out_update_vlan
}
}
vlan type arp vlan pcp set 6 counter packets 0 bytes 0
ip saddr 10.1.1.1 icmp type echo-request vlan pcp set 6 counter packets 0 bytes 0
vlan type arp vlan pcp set 6 counter packets 0 bytes 0
ip daddr 10.1.1.1 icmp type echo-reply vlan pcp set 6 counter packets 0 bytes 0
-
Mais je pense que le plus vraisemblable est que la fonctionnalité ne soit pas implémentée.
-
De toute manière nftable 1.1.x ne sera pas dispo avant plusieurs mois/années. C'est même pas une solution à envisager pour le moment, en tout cas pas de cette manière.
Celle que j'utilise fonctionne parfaitement, via une injection de règles et ça colle parfaitement dans un cycle de up/down d'une interface. Il suffit simplement d'ajouter une étape, simple de surcroit, juste avant de lancer les daemons DHCP (v4/v6).
C'est aussi pour cette raison que j'ai arrêter d'utiliser des distrib de routeur (pfsense, opnsense, wrt, ...) sur des "vrai" router que je veux stable et facilement configurable.
opnsense et pfsense passent leur temps à péter les config existantes, surtout lorsque la config devient un peu exotique. Et wrt pas bcp mieux ...
Je suis sur debian depuis plus de 6mois maintenant. Aucun update, maj, reboot, crash n'a encore tué la config. Niveau confort de config c'est aussi bcp plus simple.
J'utilisais cgroup, on a vu qu'il était possible d'utiliser nftable. Ça été mi en place en moins de 15mins, sans erreurs.
-
Oui, de mon coté j'utilise un archlinux avec systemd-networkd, il faut jouer avec les dépendances mais ça se fait bien aussi. Et le seul truc un peu tricky, c'est au boot. Une fois que l'interface est créé, les renew/release passent sans problème (les rules nftables définitives étant chargées).
-
Oui, de mon coté j'utilise un archlinux avec systemd-networkd, il faut jouer avec les dépendances mais ça se fait bien aussi. Et le seul truc un peu tricky, c'est au boot. Une fois que l'interface est créé, les renew/release passent sans problème (les rules nftables définitives étant chargées).
Le truc que je trouve chiant avec systemd c'est la complexité de mise en place d'un arbre de dépendance de service et vérifier qu'il fonctionne vraiment correctement. C'est un enfer a debug.
Et pourtant j'aime systemd, c'est un foutu bon gestionnaire de service.
D'ailleurs dans networkd, les pre-script sont aussi dispo ?
-
D'ailleurs dans networkd, les pre-script sont aussi dispo ?
Malheureusement non...
D'où la nécessité de jouer avec les dépendances (voir mon précédent post).
Perso, je déteste systemd, je regrette la bonne vieille époque de rc.conf héritée de *BSD (sous archlinux).
-
Malheureusement non...
D'où la nécessité de jouer avec les dépendances (voir mon précédent post).
Perso, je déteste systemd, je regrette la bonne vieille époque de rc.conf héritée de *BSD (sous archlinux).
Wé non ... l'ordre naturel séquentiel pour démarrer des services ... l'enfer. Sans moi :D
-
J'abandonne l'idée sur OpenWrt. Une personne sans nuance du forum OpenWrt a colmaté ensemble mes questionnements, réduisant ainsi la chance (*) de parvenir à une solution.
Visiblement on ne peut compter que sur soi-même. Car c'est pareil du côté Netfilter : interrogations laissées sans réponse. Vive l'open source ! C'est très décevant et inégalitaire.
* Je n'ai pas la science infuse.
-
J'ai relu la doc et je suis parvenu à avancer.
table netdev filter
flush table netdev filter
table netdev filter {
chain egress {
type filter hook egress device eth1 priority filter; policy accept;
vlan id 832 udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter comment "Set QoS values for DHCPv6 packets"
vlan id 832 udp dport 67 vlan pcp set 6 ip dscp set cs6 counter comment "Set QoS values for DHCPv4 packets"
}
}
Le code ci-dessus est fonctionnel sur mon routeur. Plus besoin de spécifier egress-qos-mapping.
[14/04]
C'est un faux positif. Une capture réseau montre que le PCP et DSCP des paquets correspondants restent inchangés. Obtenir des adresses IPv4/v6 m'a induit en erreur.
-
Qu'est-ce que tu entend par egress-qos-mapping ?
-
C'est un faux positif.
Je viens de contrôler en réalisant une capture réseau : les PCP et DSCP ne sont pas modifiés. Obtenir des adresses IPv4 et IPv6 m'a induit en erreur.
@Mastah : Si cela avait fonctionné alors le paramètre egress-qos-map (voir le manuel man ip-link) n'aurait plus été nécessaire. On aurait pu
changer directement le PCP sans spécifier la priorité interne des paquets adéquats.
-
Nouvelle recherche : il existe un rapport de bogue résolu.
Bug 1744 — Packet corruption occurs when using the nftables vlan pcp set command (https://bugzilla.netfilter.org/show_bug.cgi?id=1744)
J'avais déjà mentionné précédemment le test « tests: shell: add vlan mangling test case (https://git.netfilter.org/nftables/commit/?id=3f3c70948f451127d06afb23e2221ed7e17eb977) » sans savoir qu'il avait été créé en lien avec ce bogue.
Le rapporteur du bogue parvient finalement à utiliser la commande suivante pour changer la valeur du champ PCP.
nft add rule bridge br_filter Postrouting vlan pcp 2 vlan pcp set 7 counter
Cela ne fonctionne toujours pas dans mon cas. C'est quasiment la même configuration que dans celle du script Shell de test.
ip netns exec "$ns2" $NFT -f /dev/stdin
table netdev t {
chain in_update_vlan {
vlan type arp vlan id set 321 counter
ip saddr 10.1.1.1 icmp type echo-request vlan id set 321 counter
}
chain in {
type filter hook ingress device veth0 priority filter;
ether saddr da:d3:00:01:02:03 vlan id 123 jump in_update_vlan
}
chain out_update_vlan {
vlan type arp vlan id set 123 counter
ip daddr 10.1.1.1 icmp type echo-reply vlan id set 123 counter
}
chain out {
type filter hook egress device veth0 priority filter;
ether daddr da:d3:00:01:02:03 vlan id 321 jump out_update_vlan
}
}
-
Le problème a été résolu dans la version 1.1.3 de nftables (https://nftables.org/projects/nftables/files/changes-nftables-1.1.3.txt). C'est désormais la façon la plus simple de modifier la CoS.
Il faudrait que je l'intègre ce week-end. Je propose de mettre cette solution en avant.
-
Pourrais-tu faire un exemple complet dans une balise code en indiquant chaque variable et leur signifcation ?
Du genre veth0 c'est quoi, l'adresse mac correspond a quoi, etc.. En gros une explication complète de chaque champs / valeurs.
Je testerais ça de mon coté, une fois que j'aurais les détails et je l'ajouterais probablement à mon tuto Debian.
Edit: Ah si aussi, ce qui est encore nécessaire de faire pour que ça fonctionne et ce que l'on peut enlever en utilisant cette méthode.
Tu connais probablement déjà l'adresse mais vois ici ce qui est fait et dit moi ce qui est à changer => https://akhamar.github.io/orange-bypass-debian/30_interfaces/33_configuration_wan.html
-
@Mastah :
Ce sont des règles nftables classiques.
chain_in
C'est une chaîne de base.
chain_in_vlan_update
C'est une chaîne régulière.
Une chaîne permet de regrouper plusieurs règles pour des raisons de clarté et de concision.
vlan type arp vlan id set 321 counter
Une règle est formée par une séquence d'expressions et se termine par des déclarations.
Le manuel indique que vlan type arp est une expression « En-tête Ethernet ». La règle désigne toutes les trames 802.1q qui encapsulent des paquets ARP.
Le manuel indique aussi que vlan id set est une déclaration de charge utile.
payload_expression set value
vlan id est une expression d'en-tête Ethernet.
counter
Un compteur qui indique le nombre de paquets auxquels s'est appliquée la (ou les) déclaration(s) dans la règle (selon sa position).
Concrètement :
ether daddr da:d3:00:01:02:03 vlan id 321 jump out_update_vlan ➡
⤷ vlan pcp set 6 counter
On change la valeur du champ PCP à 6 de certaines trames 802.1q. Celles ayant l'identifiant VLAN 321 et dont l'adresse destination est da:d3:00:01:02:03.
En résumé :
vlan pcp set 6 est une déclaration et se place donc en fin de règle. Elle définie la valeur du champ PCP d'une trame 802.1q à la priorité 6.
table netdev t {
chain in_update_vlan {
vlan type arp vlan id set 321 counter
ip saddr 10.1.1.1 icmp type echo-request vlan id set 321 counter
}
chain in {
type filter hook ingress device veth0 priority filter;
vlan pcp 0 counter
ether saddr da:d3:00:01:02:03 vlan id 123 jump in_update_vlan
}
chain out_update_vlan {
vlan type arp vlan id set 123 counter
ip daddr 10.1.1.1 icmp type echo-reply vlan id set 123 counter
vlan pcp set 6 counter
}
chain out {
type filter hook egress device veth0 priority filter;
ether daddr da:d3:00:01:02:03 vlan id 321 jump out_update_vlan
}
}
Source: vlan_mangling (https://git.netfilter.org/nftables/tree/tests/shell/testcases/packetpath/vlan_mangling)
-
@Mastah :
On peut définir explicitement le PCP pour l'interface réseau physique.
#!/bin/bash
# Add PCP 6 (802.1Q prio 6)
nft add "table netdev filter"
nft add "chain netdev filter egress { type filter hook egress device $IFACE priority 0; }"
# IPV4
nft insert "rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6 comment \"Set CoS value to 6 for DHCPv4 packets\""
nft insert "rule netdev filter egress ether type arp meta priority set 0:6 comment \"Set CoS value to 6 for arp packets\""
# IPV6
nft insert "rule netdev filter egress udp dport 547 meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 for DHCPv6 packets\""
nft insert "rule netdev filter egress icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 for RS/NS/NA packets\""
echo "Injecting PCP 6 / 802.1Q prio 6 on egress DHCP packet [iface: $IFACE]"
table netdev filter
flush table netdev filter
table netdev filter {
chain egress {
type filter hook egress device enp3s0 priority filter; policy accept;
vlan id 832 udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter
vlan id 832 udp dport 67 vlan pcp set 6 ip dscp set cs6 counter
vlan id 832 icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } vlan pcp set 6 ip6 dscp set cs6 counter
vlan id 832 vlan type arp vlan pcp set 6 counter
}
}
table netdev filter
flush table netdev filter
table netdev filter {
chain set_isp_qos {
udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter
udp dport 67 vlan pcp set 6 ip dscp set cs6 counter
icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } vlan pcp set 6 ip6 dscp set cs6 counter
vlan type arp vlan pcp set 6 counter
}
chain egress {
type filter hook egress device enp3s0 priority filter; policy accept;
vlan id 832 jump set_isp_qos
}
}
-
D'autres personnes ont-elles testé cette méthode avec nftables 1.1.3 et le support netdev ?
Cela fonctionne sur mon routeur. Et c'est la façon canonique de procéder.
-
Moi j'ai préparé cela (avec $iface_wan1 étant mon interface dans le vlan832 - nommée orange1 ) :
chain egress {
type filter hook egress devices = $iface_wan1 priority filter; policy accept;
icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 counter comment "egress6_prio_orange_ICMP6"
udp dport 547 meta priority set 0:6 ip6 dscp set cs6 counter comment "egress6_prio_orange_DHCP6"
udp dport 67 meta priority set 0:6 ip dscp set cs6 counter comment "egress4_prio_orange_DHCP4"
ether type arp meta priority set 0:6 counter comment "egress_prio_orange_ARP"
}
est-ce que vlan id 832 .... vlan pcp ... est vraiment nécessaire ?
J'ai aussi un script au boot (avant application des rules firewall :
/etc/systemd/scripts/netdev-egress
#!/bin/sh
# apply netdev/egress priority for orange dhcp client requests
# Version 20240717
SleepRetry=3
# set orange interface
if [ -z "$1" ] ; then
iface="orange1"
else
iface="$1"
fi
echo "executing nft chain netdev filter egress device $iface"
ip link show dev $iface
if [ $? -ne 0 ] ; then
echo "ERROR : interface $iface not exist, retrying in ${SleepRetry}s..."
sleep $SleepRetry
ip link show dev $iface ; [ $? -ne 0 ] && echo "ERROR : interface $iface definitely not exist !" && exit 9
fi
echo "executing nft chain netdev filter egress device $iface"
echo ; echo "existing table netdev filter (if exist)"
nft list table netdev filter 2>/dev/null # redirect error messages
echo ; echo "applying nft chain netdev filter egress $iface"
nft add "table netdev filter"
nft add "chain netdev filter egress { type filter hook egress devices = { ${iface} } priority 0; }"
nft insert "rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6 counter comment \"egress4_prio_${iface}_DHCP4\""
nft insert "rule netdev filter egress ether type arp meta priority set 0:6 counter comment \"egress_prio_${iface}_ARP\""
nft insert "rule netdev filter egress ip6 daddr { fe00::/7 } udp dport 547 meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress6_prio_${iface}_DHCP6\""
nft insert "rule netdev filter egress ip6 daddr { fe00::/7 } icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress6_prio_${iface}_ICMP6\""
#nft insert "rule netdev filter egress icmpv6 daddr { fe00::/7 } meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress6_prio_${iface}_ICMP6\""
echo ; echo "final nft table netdev filter"
nft list table netdev filter
echo ; echo "networkctl renew $iface"
networkctl renew $iface
echo ; echo "networkctl status $iface"
networkctl -s status $iface
/etc/systemd/system/netdev-egress@.service
# WARNING : not fully tested
[Unit]
Description=netdev-egress pre-requisite for %i
BindTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=oneshot
ExecStart=/etc/systemd/scripts/netdev-egress %i
RemainAfterExit=true
TimeoutSec=10
[Install]
WantedBy=sys-subsystem-net-devices-%i.device
je fais bien sur un systemctl enable /etc/systemd/system/netdev-egress@orange1.service
-
@cyayon:
Je ne connais pas systemd. Avant, j'utilisais Gentoo (OpenRC). Maintenant, Guix (Shepherd). Et OpenWrt utilise procd.
Il y a des couches d'abstraction. OpenWrt lance le service « pare-feu » via firewall4 (fw) et permet d'inclure des fichiers
au format nftables.
On peut définir clairement les champs PCP dans les règles du pare-feu, de façon atomique (https://wiki.nftables.org/wiki-nftables/index.php/Scripting), sans avoir à créer une interface.
Wep c'est bon. Par contre il y a un petit souci. L'interface n'étant pas encore existante au démarrage mais aussi au start du service NFT, il n'est donc pas possible de directement placer la config nftable dans /etc/nftables.conf
Il faut l'injecter dans la phase up du vlan832, juste avant de faire les req DHCP. Il faut aussi delete les rules sur le down de l'interface.
Cela ne fonctionnait pas auparavant à cause d'un bogue.
Attachment: changes-nftables-1.1.3.txt (type=text/plain)
Florian Westphal (1):
evalute: make vlan pcp updates work
Pablo Neira Ayuso (3):
Revert "intervals: do not merge intervals with different timeout"
netlink: bogus concatenated set ranges with netlink message overrun
build: Bump version to 1.1.3
-
est-ce que vlan id 832 .... vlan pcp ... est vraiment nécessaire ?
Cela permet de sélectionner uniquement les paquets envoyés sur le VLAN 832.
-
Salut,
En fait ma question était surtout pour la partie nftables uniquement.
Faut-il :
- les trois paramètres : pcp, dscp et priority ? Ou bien priority et dscp uniquement ? Sachant que j’applique sur l’interface vlan (832) et non sur l’interface physique.
- peut on appliquer pcp directement sur une interface vlan (je pense que oui) ?
- vaut-il mieux appliquer sur l’interface vlan ou physique, et donc sans ou avec ^vlan id 832 ?
Merci.
-
@cyayon:
- les trois paramètres : pcp, dscp et priority ? Ou bien priority et dscp uniquement ? Sachant que j’applique sur l’interface vlan (832) et non sur l’interface physique.
Deux paramètres : PCP et DSCP (c.f. Simple rule management (https://wiki.nftables.org/wiki-nftables/index.php/Simple_rule_management)).
- peut on appliquer pcp directement sur une interface vlan (je pense que oui) ?
Ce n'est pas une bonne idée.
- vaut-il mieux appliquer sur l’interface vlan ou physique, et donc sans ou avec ^vlan id 832 ?
Il vaut mieux appliquer sur l'interface physique.
Explication
On devrait appliquer les règles uniquement sur l'interface physique. On peut faire totalement abstraction de l'interface virtuelle, cela complexifie la configuration et
n'apporte rien il me semble.
On définit les champs PCP (L2 « classes de service », CoS) et DSCP (L3 « services différenciés », DiffServ) des paquets comme cela est spécifié par Orange.
On peut modifier la métadonnée priority pour changer le PCP mais cela est également employé dans des configurations plus complexes (c.f. TC (https://wiki.nftables.org/wiki-nftables/index.php/Classification_to_tc_structure_example)). Moins abstrait.
L'expression vlan id 832 permet de sélectionner des paquets. Je ne suis pas certain qu'elle soit obligatoire (à tester). Sinon, cela peut aider à clarifier des règles.
L'identifiant VLAN est associé de facto au champ PCP à cause du standard 802.1Q et un même périphérique peut supporter plusieurs VLANs. C'est aussi caractérisé
par rapport au domaine d'application de la table netdev.
-
ok merci bcp pour ces précisions.
est-ce genant de faire 'vlan pcp set 6 meta priority set 0:6 ip6 dscp set cs6' sur l'interface physique ?
meme si 'vlan pcp set 6 ip6 dscp set cs6' devrait etre suffisant si j'ai bien compris.
-
@cyayon :
Ce serait superflu et gênant sémantiquement car les deux expressions servent à changer la valeur du champ PCP. Je ferais un nouveau test demain sans l'expression vlan id... pour être sûr.
Mes règles sont actuellement segmentées dans plusieurs tables (inet (ICMPs), arp (ARP) et netdev (DHCPs)) pour réduire les risques d'erreur.
-
Super! Merci pour ton retour.
Actuellement c’est mon Mikrotik CCR 2116 qui tiens le dhclient en front de mon nftables.
Je compte revendre mon Mikrotik prochainement, et donc revenir avec mon nftables en front et qui tiendra le dhclient.
-
J'ai testé avec les règles suivantes et cela fonctionne à priori. sfp1 est le nom de l'interface physique côté WAN.
Je n'ai pas appliqué de DSCP pour les paquets IGMP (il aurait fallu que je refasse une nouvelle capture réseau).
table netdev filter {
chain egress {
type filter hook egress device "sfp1" priority filter; policy accept;
udp dport 547 vlan pcp set 6 ip6 dscp set cs6 comment "QoS for DHCPv6 packets"
udp dport 67 vlan pcp set 6 ip dscp set cs6 comment "QoS for DHCPv4 packets"
ip protocol igmp vlan pcp set 5 comment "QoS for IGMP packets"
vlan type arp vlan pcp set 6 comment "QoS for ARP packets"
icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } vlan pcp set 6 ip6 dscp set cs6 comment "QoS for ICMP packets"
}
}
-
Donc sans préciser ^vlan id 832 ?
-
Oui, sans vlan id ....
-
La je ne comprends pas …
Il vaut mieux conserver vlan id … ou appliquer sur l’interface vlan directement
-
@cyayon :
Le vlan id ... est une juste expression. On peut juxtaposer des expressions pour affiner « un filtre ». Il n'y a pas d'interface virtuelle dans le "device".
-
@cyayon :
Le trafic DHCP & Co. passe de toute façon par l'interface VLAN 832 ou VLAN 840 (IGMP).
-
Ok c’ est plus clair, donc pour reformuler : du fait qu’on applique en netdev, pas besoin de préciser vlan id …. mais ça fonctionne dans les 2 cas (avec ou sans vlan id …)
-
@cyayon :
Tout à fait.
Tous ces paquets transitent par le périphérique physique même si c'est sur un VLAN différent.
Exemple d'expressions vlan id mais aussi vlan type.
-
Autre format :
table netdev filter
flush table netdev filter
table netdev filter {
chain set_isp_vlan_832 {
udp dport 547 vlan pcp set 6 ip6 dscp set cs6 comment "QoS for DHCPv6 packets"
udp dport 67 vlan pcp set 6 ip dscp set cs6 comment "QoS for DHCPv4 packets"
icmpv6 type { 133, 135, 136 } vlan pcp set 6 ip6 dscp set cs6 comment "Set Qos for ICMPv6 packets"
}
chain set_isp_vlan_840 {
ip protocol igmp vlan pcp set 5 comment "QoS for IGMP packets"
}
chain egress {
type filter hook egress device $wan_iface priority filter; policy accept;
vlan type arp vlan pcp set 6 comment "QoS for ARP packets"
vlan id 832 jump set_isp_vlan_832
vlan id 840 jump set_isp_vlan_840
}
}
14:05
J'avais oublié d'ajouter une règle : vlan type arp vlan pcp set 6 comment "QoS for ARP packets" dans la chaîne egress.
-
Merci bcp pour tes retours très instructifs !
-
Par contre, le script initial qui fait des nft insert… opère sur l’interface vlan 832 (je pense) ou aussi l’interface physique ?
Cela dit avec ce qu’on vient de voir, finalement peu importe (vu que netdev intervient au niveau plus bas avec ou sans préciser le vlan).
-
Moi j'ai préparé cela (avec $iface_wan1 étant mon interface dans le vlan832 - nommée orange1 ) :
chain egress {
type filter hook egress devices = $iface_wan1 priority filter; policy accept;
icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 counter comment "egress6_prio_orange_ICMP6"
udp dport 547 meta priority set 0:6 ip6 dscp set cs6 counter comment "egress6_prio_orange_DHCP6"
udp dport 67 meta priority set 0:6 ip dscp set cs6 counter comment "egress4_prio_orange_DHCP4"
ether type arp meta priority set 0:6 counter comment "egress_prio_orange_ARP"
}
est-ce que vlan id 832 .... vlan pcp ... est vraiment nécessaire ?
J'ai aussi un script au boot (avant application des rules firewall :
/etc/systemd/scripts/netdev-egress
#!/bin/sh
# apply netdev/egress priority for orange dhcp client requests
# Version 20240717
SleepRetry=3
# set orange interface
if [ -z "$1" ] ; then
iface="orange1"
else
iface="$1"
fi
echo "executing nft chain netdev filter egress device $iface"
ip link show dev $iface
if [ $? -ne 0 ] ; then
echo "ERROR : interface $iface not exist, retrying in ${SleepRetry}s..."
sleep $SleepRetry
ip link show dev $iface ; [ $? -ne 0 ] && echo "ERROR : interface $iface definitely not exist !" && exit 9
fi
echo "executing nft chain netdev filter egress device $iface"
echo ; echo "existing table netdev filter (if exist)"
nft list table netdev filter 2>/dev/null # redirect error messages
echo ; echo "applying nft chain netdev filter egress $iface"
nft add "table netdev filter"
nft add "chain netdev filter egress { type filter hook egress devices = { ${iface} } priority 0; }"
nft insert "rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6 counter comment \"egress4_prio_${iface}_DHCP4\""
nft insert "rule netdev filter egress ether type arp meta priority set 0:6 counter comment \"egress_prio_${iface}_ARP\""
nft insert "rule netdev filter egress ip6 daddr { fe00::/7 } udp dport 547 meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress6_prio_${iface}_DHCP6\""
nft insert "rule netdev filter egress ip6 daddr { fe00::/7 } icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress6_prio_${iface}_ICMP6\""
#nft insert "rule netdev filter egress icmpv6 daddr { fe00::/7 } meta priority set 0:6 ip6 dscp set cs6 counter comment \"egress6_prio_${iface}_ICMP6\""
echo ; echo "final nft table netdev filter"
nft list table netdev filter
echo ; echo "networkctl renew $iface"
networkctl renew $iface
echo ; echo "networkctl status $iface"
networkctl -s status $iface
/etc/systemd/system/netdev-egress@.service
# WARNING : not fully tested
[Unit]
Description=netdev-egress pre-requisite for %i
BindTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=oneshot
ExecStart=/etc/systemd/scripts/netdev-egress %i
RemainAfterExit=true
TimeoutSec=10
[Install]
WantedBy=sys-subsystem-net-devices-%i.device
je fais bien sur un systemctl enable /etc/systemd/system/netdev-egress@orange1.service
En fait, il suffit d'intégrer la table netdev avec ses règles dans le fichier par défaut /etc/nftables.conf. nftables embarque également son propre langage de script (https://wiki.nftables.org/wiki-nftables/index.php/Scripting).
Voir aussi Arch Wiki: Simple firewall (https://wiki.archlinux.org/title/Nftables#Simple_firewall).
-
De mon point de vue, ce script (nft insert …) sert uniquement à charger des rules nft minimales pour que le client dhcp (systemd-networkd) passe la phase d’authentification orange.
Ce script se charge juste après la création de l’interface et avant les dhcp client requests.
Dans la plupart des cas les firewall rules (nftables) sont chargées plus tard.
C’est un peu l’histoire de la poule et l’œuf…
-
@cyayon:
Normalement, les règles de pare-feu sont appliquées avant le lancement des services réseaux afin d'être protégé.
Tu peux créer une configuration de pare-feu minimale en ligne de commande pour réaliser des tests. Tu peux également enregistrer les règles dans un script nftables.
Sur Arch Linux, par exemple, tu actives le service systemd nftables.service.
-
C’est un peu l’histoire de la poule et l’œuf…
Cela fonctionne ainsi sur OpenWrt sans problème. Le pare-feu (service fw4) est activé avant la configuration des interfaces (service netifd).
C'est aussi la raison pour laquelle il ne faut pas spécifier l'interface VLAN comme device dans la règle egress.
Edit:
Voici un exemple de fichier nftables.service généré par ChatGPT.
[Unit]
Description=nftables firewall
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/nft -f /etc/nftables.conf
ExecReload=/usr/sbin/nft -f /etc/nftables.conf
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
-
Dans mon cas, sur mon routeur / fw Archlinux, je ne charge mes rules firewalls (et autres configs multiwan / vpn) via un script custom.
Je ne le charge qu’après que toutes les config réseaux soient passées.
Du coup, il me faut un script dédié pour charger des rules netdev minimale juste après la création de l’interface vlan 832 et avant les premières requests dhcp client.
Globalement, le pb avec nft c’est qu’il faut que les interfaces existent avant d’appliquer des rules sur ces dernières.
-
@cyayon :
Dans la nouvelle configuration, on a plus à se préoccuper de la création de l'interface virtuelle.
Dans un routeur OpenWrt, ce sont généralement le noyau Linux et les pilotes de périphériques qui créent et gèrent les interfaces physiques telles que `sfp1` ou `eth0`.
Plus précisément :
- Le noyau Linux : Il détecte le matériel physique connecté au système (par exemple, un port SFP ou Ethernet) lors du démarrage ou de la détection de nouveau matériel. Il crée alors une interface correspondante dans le système, comme `eth0`, `eth1`, ou des interfaces spécifiques comme `sfp1`.
- Les pilotes de périphériques : Ils sont intégrés dans le noyau ou chargés en tant que modules. Ces pilotes permettent au noyau d'interpréter et de gérer le matériel spécifique, et ils créent les interfaces réseau correspondantes une fois que le matériel est reconnu. Par exemple, un pilote pour un port SFP ou Ethernet peut créer une interface nommée `sfp1` ou `eth0`.
- Udev ou autres systèmes de gestion : Sur OpenWrt, c’est principalement le noyau et ses pilotes qui créent ces interfaces lors du processus de détection du matériel. Udev peut également intervenir pour gérer la nomination ou la configuration dynamique des interfaces, mais la création initiale est une tâche du noyau et des pilotes.
En résumé : Ce sont le noyau Linux et ses pilotes correspondant au matériel physique (SFP, Ethernet, etc.) qui créent les interfaces physiques telles que `sfp1` ou `eth0` dans OpenWrt.
-
@cyayon :
De plus :
En général, il est possible de définir des règles de pare-feu avec nftables avant que les interfaces réseau physiques comme eth1 ou sfp1 soient créées ou configurées, mais leur application effective dépend du moment où ces interfaces sont présentes et opérationnelles.
Voici quelques points importants à considérer :
1. Définition des règles nftables :
Vous pouvez écrire et charger une configuration nftables à tout moment, indépendamment de la présence des interfaces réseau physiques. Les règles seront stockées dans la table et prêtes à être appliquées lorsque les interfaces seront disponibles.
2. Application des règles :
Les règles nftables associées à des interfaces spécifiques ne seront réellement appliquées que lorsque ces interfaces existent et sont actives. Si une règle fait référence à une interface qui n’existe pas encore, cette règle sera simplement en attente ou ne sera pas appliquée tant que l’interface n’est pas créée.
3. Création et chargement des règles :
- Si vous chargez une configuration nftables qui inclut des règles pour une interface non encore créée, ces règles seront enregistrées mais ne prendront effet que lorsque l’interface sera disponible.
- Il est courant de préparer la configuration nftables à l’avance, puis de la charger une fois que toutes les interfaces sont en place.
4. Automatisation et scripts :
Pour une gestion dynamique, il est pratique d’utiliser des scripts ou des systèmes de gestion de configuration (comme systemd, udev, ou des scripts init) pour charger ou recharger nftables lorsque les interfaces réseau sont créées ou configurées.
En résumé :
Vous pouvez créer et charger des règles nftables avant que les interfaces physiques soient créées, mais celles-ci ne seront appliquées que lorsque ces interfaces seront disponibles et actives. Il est donc courant de préparer la configuration à l’avance et de l’appliquer une fois que le matériel ou la configuration logicielle des interfaces est en place.
-
Je ne connais pas bien openwrt, faudrait voir dans les dernières version de nftables si on peut appliquer des rules sur des interfaces inexistantes.
En tout cas, la dernière fois que j’ai essayer de charger des rules sur des interfaces WireGuard / Openvpn (tun) qui n’existaient pas encore (boot order), j’ai une belle erreur nftables. Du coup j’ai créer un petit script qui créer des interaces tun fake pour que les rules se chargent.
-
Non, cela ne fonctionnera avec des interfaces virtuelles.
Toutefois, rien n'empêche de les charger dynamiquement avec des nft add...
Edit : substitution de nft add ip netdev_filter par nft add netdev filter. (code généré par ChatGPT).
Edit : substitution de nft add chain ip netdev_filter set_isp_vlan_832 { type filter hook false priority 0; } par nft add chain ip netdev_filter set_isp_vlan_832...
# Voici comment convertir votre configuration nft en commandes nft add :
# Vider la table existante
nft flush table netdev filter
# Créer la table
nft add table netdev filter
# Créer la chaîne set_isp_vlan_832
nft add chain netdev filter set_isp_vlan_832
# Ajouter les règles à set_isp_vlan_832
nft add rule netdev filter set_isp_vlan_832 udp dport 547 vlan pcp set 6 comment "QoS for DHCPv6 packets"
nft add rule netdev filter set_isp_vlan_832 udp dport 67 vlan pcp set 6 comment "QoS for DHCPv4 packets"
nft add rule netdev filter set_isp_vlan_832 ip6 type icmpv6 { 133, 135, 136 } vlan pcp set 6 comment "Set Qos for ICMPv6 packets"
# Créer la chaîne set_isp_vlan_840
nft add chain netdev filter set_isp_vlan_840
# Ajouter la règle à set_isp_vlan_840
nft add rule netdev filter set_isp_vlan_840 ip protocol igmp vlan pcp set 5 comment "QoS for IGMP packets"
# Créer la chaîne egress
nft add chain netdev filter egress { type filter hook egress device $wan_iface priority filter; policy accept; }
# Ajouter les règles à egress
nft add rule netdev filter egress vlan id 832 jump set_isp_vlan_832
nft add rule netdev filter egress vlan id 840 jump set_isp_vlan_840
# Remplacez `$wan_iface` par le nom de votre interface réseau si nécessaire.
# N'oubliez pas de tester chaque étape pour vous assurer que la configuration est correcte.
-
J'ai oublié d'ajouter la règle pour définir le PCP des paquets ARP.
nft add rule netdev filter egress vlan type arp vlan pcp set 6 comment "Set QoS for ARP packets"
À voir si cela fonctionne dans la règle générale ou s'il faut réduire au VLAN 832.
-
Je suis pas certain d’avoir compris tes derniers commentaires et la possibilité de loader des rules nftables avant la création des interfaces (et l’utilisation de ifname).
-
@cyayon
Le $wan_ifname c'est la conversion automatique de mes règles en CLI par ChatGPT. Dans les faits, cela correspond à l'interface physique sfp1 côté WAN de mon routeur.
Je pense que c'est une erreur de spécifier une interface virtuelle dans le crochet (hook) egress de la table netdev après le mot-clé device.
Finalement, la seule chose qui importe est de spécifier le nom de l'interface physique après le mot-clé device.
-
Oui je suis d’accord.
Mais si tu charges des rules nftables d’autres tables/chains avec ^iifname (ou ^oifname) en spécifiant une interface virtuelle ou physique qui n’existe pas encore (au moment du boot par exemple), nftables refuse.
Du moins c’est ce que j’ai constaté la dernière fois (et j’ai été contrait de les pré-créer via un script).
Et systemd-networkd n’a pas la capacité à trigger des scripts a la manière de ifup ou ifdown, pour justement charger des scripts de rules nftables juste après leur création.
Faudra que je re-teste en rentrant de vacances…
-
Bonjour,
Pour OpenWrt, juste une idee que je n'ai pas encore eu le temps de tester
En se basant sur https://openwrt.org/docs/guide-user/base-system/hotplug (https://openwrt.org/docs/guide-user/base-system/hotplug), en theorie il devrait etre possible d'ajouter les regles nftables lorsque le device VLAN passe a l'état up, et donc pouvoir preciser comme le device VLAN lors de l'ajout de la chaine netdev.
Par exemple creer dans /etc/hotplug.d/iface, un fichier 30-orange qui contient ce code
[ "$ACTION" = "ifup" ] && [ "$INTERFACE" = "wan4" ] && {
logger "Interface $INTERFACE is up (device $DEVICE)"
# Remove the table if it exists
nft destroy "table netdev orange_filter"
# Create table and chain
nft add "table netdev orange_filter"
nft add "chain netdev orange_filter egress { type filter hook egress device $DEVICE priority 0; }"
# Insert IPV4 rules
nft insert "rule netdev orange_filter egress udp dport 67 counter meta priority set 0:6 ip dscp set cs6 comment \"Set CoS value to 6 and DSCP value to 48 (cs6) for DHCPv4 packets\""
nft insert "rule netdev orange_filter egress ether type arp counter meta priority set 0:6 comment \"Set CoS value to 6 for arp packets\""
# Insert IPV6 rules
nft insert "rule netdev orange_filter egress udp dport 547 counter meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 and DSCP value to 48 (cs6) for DHCPv6 packets\""
nft insert "rule netdev orange_filter egress icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } counter meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 and DSCP value to 48 (cs6) for RS/NS/NA packets\""
}
[ "$ACTION" = "ifdown" ] && [ "$INTERFACE" = "wan4" ] && {
logger "Interface $INTERFACE is down (device $DEVICE)"
# Remove the table if it exists
nft destroy "table netdev orange_filter"
}
J'ai deja verifie avec OpenWrt 24.10.2 que la commande fw4 start/reload/restart/stop ne touche pas a la table (par contre fw4 flush lui vide toutes les tables nftables)
Chez moi l'interface (au sens OpenWrt) est associé au device (au sens OpenWrt) eth0.832.
Voila c'etait juste une idee, PAS ENCORE TESTEE, je le reprécise
-
Et systemd-networkd n’a pas la capacité à trigger des scripts a la manière de ifup ou ifdown, pour justement charger des scripts de rules nftables juste après leur création.
Je ne sais pas comment cela fonctionne au niveau des services (les dépendances). Sur OpenWrt, cela simplifie la configuration.
J'espérais qu'il aurait suffi d'ajouter ces règles dans le fichier /etc/nftables.conf ou quelque chose comme ça. À voir, si on
peut procéder différemment en fonction des cas.
-
@pgid69 :
C'est tout l'intérêt d'inclure ces règles avec fw4. On reprend la simplissime écriture de script nftables. Attention à ne pas faire de faute sinon le pare-feu casse.
uci -q batch <<-EOF
add firewall include
set firewall.@include[-1].enabled='1'
set firewall.@include[-1].type='nftables'
set firewall.@include[-1].path='/etc/custom-netdev-table.nft'
set firewall.@include[-1].position='ruleset-post'
EOF
# uci commit firewall
# service firewall restart
wan_iface=$(jsonfilter -i /etc/board.json -e '$.network.wan.ports[0]')
cat >/etc/custom-netdev-table.nft <<EOF
table netdev filter
flush table netdev filter
table netdev filter {
chain set_isp_vlan_832 {
udp dport 547 vlan pcp set 6 ip6 dscp set cs6 comment "Set QoS for DHCPv6 packets"
udp dport 67 vlan pcp set 6 ip dscp set cs6 comment "Set QoS for DHCPv4 packets"
icmpv6 type { 133, 135, 136 } vlan pcp set 6 ip6 dscp set cs6 comment "Set QoS for ICMPv6 packets"
}
chain set_isp_vlan_840 {
ip protocol igmp vlan pcp set 5 comment "Set QoS for IGMP packets"
}
chain egress {
type filter hook egress device $wan_iface priority filter; policy accept;
vlan type arp vlan pcp set 6 comment "Set QoS for ARP packets"
vlan id 832 jump set_isp_vlan_832
vlan id 840 jump set_isp_vlan_840
}
}
EOF
À noter que cela ne fonctionnera pas avec la version stable actuelle de OpenWrt. Il faut compiler les sources « snapshot » avec OpenWrt Buildroot pour activer le support noyau netdev.
-
Après recherche, il semblerait que l’on puisse charger des rules nftables sans que l’interface existe. SAUF pour ingress, et je suis dans ce cas là pour bloquer les scan/brute au plus tôt et avant le conntrack.
N’ayant pas openwrt, je dois procéder moi-même à un contournement en créant des fake interfaces pour que nftables se charge.
-
À noter que cela ne fonctionnera pas avec la version stable actuelle de OpenWrt. Il faut compiler les sources « snapshot » avec OpenWrt Buildroot pour activer le support noyau netdev.
Avec la version 24.10.2, j'ai la possibilite d'installer le package kmod-nf-netdev. A priori cela devrait suffire non ? (d'ailleurs le package kmod-nf-arp est peut etre egalement necessaire)
-
@pgid69 :
C'est vrai que je ne maîtrise pas tellement le gestionnaire de paquets. Cela pourrait fonctionner en installant le paquet kmod-nft-netdev.
Toutefois, la version 24.10.2 ne dispose pas encore de la version nftables 1.1.3.
-
@pgid69 :
Toutefois, la version 24.10.2 ne dispose pas encore de la version nftables 1.1.3.
D'ou donc l'interet d'utiliser le script hotplug (ce que tu avais d'ailleurs evoque dans ce sujet que je viens de trouver https://lafibre.info/remplacer-livebox/openwrt-rechercher-comment-changer-la-qos-avec-nftables/ (https://lafibre.info/remplacer-livebox/openwrt-rechercher-comment-changer-la-qos-avec-nftables/)) pour appliquer les regles netdev sur l'interface VLAN et non pas sur l'interface utilisee par le VLAN.
Comme ca dans les regles nftables, on change le PCP indirectement en changeant la priorite du paquet par 'meta priority set' plutot que 'vlan pcp set' qui est buggé (j'imagine qu'en sortant du hook egress, le paquet passe par le driver VLAN qui va inserer l'entete VLAN dans lequel le PCP est deduit de la priorite).
Je vais essayer de tester tout ca pour verifier que la theorie fonctionne : deja verifier que j'ai bien l'evenement hotplug pour l'interface VLAN, puis si c'est le cas que les requetes DHCP partent pas avant que les regles nftables sont en place, et enfin qu'il y les bonnes priorites
-
Les nouvelles règles sont plus claires. C'est plus abstrait avec moins de facteurs (egress qos map, virtual interface, meta priority).
Je mettrais la solution à jour dès la fin du mois si personne n'y voit d'objection. Je ne suis pas certain que cela fonctionne toujours.
-
D'ou donc l'interet d'utiliser le script hotplug (ce que tu avais d'ailleurs evoque dans ce sujet que je viens de trouver https://lafibre.info/remplacer-livebox/openwrt-rechercher-comment-changer-la-qos-avec-nftables/ (https://lafibre.info/remplacer-livebox/openwrt-rechercher-comment-changer-la-qos-avec-nftables/)) pour appliquer les regles netdev sur l'interface VLAN et non pas sur l'interface utilisee par le VLAN.
Comme ca dans les regles nftables, on change le PCP indirectement en changeant la priorite du paquet par 'meta priority set' plutot que 'vlan pcp set' qui est buggé (j'imagine qu'en sortant du hook egress, le paquet passe par le driver VLAN qui va inserer l'entete VLAN dans lequel le PCP est deduit de la priorite).
Je vais essayer de tester tout ça pour vérifier que la théorie fonctionne : déjà verifier que j'ai bien l'événement hotplug pour l'interface VLAN, puis si c'est le cas que les requêtes DHCP partent pas avant que les règles nftables sont en place, et enfin qu'il y a les bonnes priorités
J'ai enfin pu faire mes essais et ça fonctionne : j'ai pu vérifier avec wireshark que les trames sont correctement modifiées pour répondre aux exigences d'Orange et lorsque je remplace la Livebox par mon routeur je peux naviguer sur Internet : le routeur récupère bien une adresse IPv4, le préfixe IPv6, les serveurs DNS IPv4 et IPv6
Je suis en version 24.10.2 d'OpenWrt. nftables est en version 1.1.1
J'ai du installer les packages complémentaires kmod-nft-netdev (kmod-nft-arp n'est pas nécéssaire car on n'utilise pas de table de la famille arp)
Par contre il ne faut pas mettre le script hotplug dans /etc/hotplug.d/iface, mais dans /etc/hotplug.d/net : d’après ce que je comprends dans /etc/hotplug.d/net les scripts sont exécutés lorsqu'une interface est rajoutée, tandis que dans /etc/hotplug.d/iface les scripts sont exécutés lorsque l'interface est prête c'est a dire completement configurée (donc pour une interface configurée en DHCP, après que l'interface ait recupéré son adresse IP...)
Voici mon script /etc/hotplug.d/net/10-wan.832
#logger -t hotplug-net $(env)
[ "$ACTION" = "add" ] && [ "$DEVICENAME" = "wan.832" ] && {
# Remove the table if it exists
nft destroy "table netdev orange_filter"
# Create table and chain
nft add "table netdev orange_filter"
nft add "chain netdev orange_filter egress { type filter hook egress device $DEVICENAME priority 0; }"
# Insert IPV4 rules
nft insert "rule netdev orange_filter egress udp dport 67 counter meta priority set 0:6 ip dscp set cs6 comment \"Set CoS value to 6 and DSCP value to 48 (cs6) for DHCPv4 packets\""
nft insert "rule netdev orange_filter egress ether type arp counter meta priority set 0:6 comment \"Set CoS value to 6 for arp packets\""
# Insert IPV6 rules
nft insert "rule netdev orange_filter egress udp dport 547 counter meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 and DSCP value to 48 (cs6) for DHCPv6 packets\""
nft insert "rule netdev orange_filter egress icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } counter meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 and DSCP value to 48 (cs6) for RS/NS/NA packets\""
}
[ "$ACTION" = "remove" ] && [ "$DEVICENAME" = "wan.832" ] && {
# Remove the table if it exists
nft destroy "table netdev orange_filter"
}
Remarque : ce script doit être explicitement rajouté dans la liste de fichiers à sauvegarder (fichier /etc/sysupgrade.conf)
Les règles nftables fixe la priorité du paquet Linux a 6, et fixe le champ DSCP a CS6, mais il faut dans la définition du device vlan, ajouter l'option egress_qos_mapping pour que les paquets en priorité 6 soient encapsulés dans des trames VLAN
avec le champ PCP a 6
Voici la définition de mon device VLAN, dans le fichier /etc/config/network
config device
option name 'wan.832'
option type '8021q'
option ifname 'wan'
option vid '832'
list egress_qos_mapping '6:6'
option macaddr 'XX:XX:XX:XX:XX:XX'
Voila avec cette méthode, je reste avec la version standard d'OpenWrt, et je ne suis pas bloqué par le bug de nftables (qui empeche vlan pcp set de fonctionner)
Si quelqu'un a une idée pour faire plus simple je suis preneur. Ou peut être plus efficace dans le sens ou avec la table netdev, absolument tout le trafic qui sort sur Internet est filtré, même le trafic forwardé depuis le réseau local...
-
Pour être sûr à 100% de respecter les recommandations énoncées par @levieuxatorange ici (https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg984140/#msg984140), à savoir de mettre une priorité que sur les paquets provenant du routeur, j'ai rajouté la règle suivante dans /etc/config/firewall
config rule
option name 'Mark forwarded packets to skip nftable netdev egress rules applied on wan.832 device'
option src 'lan'
option dest 'wan'
option family 'any'
option proto 'all'
option set_mark '0x40000000/0x40000000'
option target 'MARK'
Et j'ai modifié mon script hotplug.d pour rajouter une sous chaîne nftables utilisée que pour les paquets non marqués
#logger -t hotplug-net $(env)
[ "$ACTION" = "add" ] && [ "$DEVICENAME" = "wan.832" ] && {
# Remove the table if it exists
nft destroy "table netdev orange_filter"
# Create table and chains
nft add "table netdev orange_filter"
# Create a sub chain to set packet priority and DCSP value
nft add "chain netdev orange_filter set_isp_qos"
# Set priority of ARP traffic
nft insert "rule netdev orange_filter set_isp_qos ether type arp counter meta priority set 0:6 comment \"Set CoS value to 6 for arp packets\""
# Set priority of DHCPv4 traffic
nft insert "rule netdev orange_filter set_isp_qos udp dport 67 counter meta priority set 0:6 ip dscp set cs6 comment \"Set CoS value to 6 and DSCP value to 48 (cs6) for DHCPv4 packets\""
# Set priority of DHCPv6 traffic
nft insert "rule netdev orange_filter set_isp_qos udp dport 547 counter meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 and DSCP value to 48 (cs6) for DHCPv6 packets\""
# Set priority of specific ICMPv6 traffic (RS / NS and NA)
nft insert "rule netdev orange_filter set_isp_qos icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } counter meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 and DSCP value to 48 (cs6) for RS/NS/NA packets\""
# Create main chain, hooked to egress
nft add "chain netdev orange_filter egress { type filter hook egress device $DEVICENAME priority 0; }"
# Apply rules only to traffic not having mark 0x40000000
nft insert "rule netdev orange_filter egress meta mark and 0x40000000 eq 0 jump set_isp_qos"
}
[ "$ACTION" = "remove" ] && [ "$DEVICENAME" = "wan.832" ] && {
# Remove the table if it exists
nft destroy "table netdev orange_filter"
}
C'est peut être aussi plus efficace pour le traffic forwardé du lan vers Internet, traffic majoritaire dans mon cas
-
@pgid69 :
J'avais ouvert un fil de discussion (https://lafibre.info/remplacer-livebox/openwrt-rechercher-comment-changer-la-qos-avec-nftables/) sur ce sujet, mais spécifique à OpenWrt. Procéder ainsi n'est pas réalisable avec OpenWrt en version stable, sans contournements.
C'est dommage de mélanger les choses en connaissance de cause (https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/msg1127702/#msg1127702). De plus, dans le procédé utilisé, il me semble que ces règles ne sont pas persistantes. En effet,
fw4 ne recharge que sa propre table (pas la table netdev ajoutée dynamiquement) à chaque reconfiguration d'interface lors de l'amorçage. Pour finir, tu complexifies
encore un peu plus la configuration du pare-feu en « marquant les paquets ».
Le bogue est corrigé dans la version 1.1.3 de nftables (https://www.netfilter.org/projects/nftables/files/changes-nftables-1.1.3.txt). On peut spécifier différemment et surtout, de façon plus évidente, la QoS.
-
@basilix
Je suis bien en version stable, en version 24.10.2 avec un firmware directement téléchargé sur le site d'OpenWrt.
Sauf erreur de ma part le bug auquel tu fais référence concerne 'vlan pcp set 6', mais ce n'est pas ce qui est utilisé dans les règles que j'ai données, puisque j'utilise 'meta priority set 0:6' et je te confirme que ça fonctionne en version stable d'OpenWrt avec nftable 1.1.1.
Mais bien sûr en contrepartie, il faut ajouter les règles au device vlan (wan.832) et non pas au device sous jacent (wan), ce qui a pour conséquence de devoir ajouter les règles nftables dans le script hotplug, lorsque l'on est sûr que le device wan.832 existe.
Donc oui il faut ajouter la table dynamiquement à chaque démarrage (les commandes reload, restart de fw4 ne touche pas à la table netdev. La seule commande qui supprime absolument toutes les tables nftables (y compris la table fw4) c'est 'fw4 flush').
Je n'ai pas trouvé comment faire plus simple en version stable.
Et pour le marquage des paquets, oui c'est vrai, c'est du pinaillage, pour être sur qu'aucun paquet qui vient du lan ne sera priorisé en PCP 6.
-
[...] Mais bien sûr en contrepartie, il faut ajouter les règles au device vlan (wan.832) et non pas au device sous jacent (wan) [...]
Cela ne fonctionnait pas sur l'interface physique lors de tests. Mais cela n'indique pas que filtrer sur l'interface virtuelle est une bonne pratique.
[...] les commandes reload, restart de fw4 ne touche pas à la table netdev. [...]
Je me suis sûrement embrouillé lors de mes tests. Si c'est le cas alors ma solution restait la plus simple. On ne modifiait que la priorité interne des paquets DHCP dans la table netdev.
Les priorités internes des autres paquets sélectionnés étaient modifié ailleurs (tables inet et arp).
-
Cela ne fonctionnait pas sur l'interface physique lors de tests.
Si tu entends par là, modifier la priorité du paquet (meta set priority 0:6) en filtrant sur l'interface physique, ca me parait logique que ca ne fonctionne pas car à priori le paquet a déjà été traité par le driver VLAN. Or c'est ce dernier qui mappe la priorité d'un paquet en valeur du champ PCP (list egress_qos_mapping 6:6 dans la config du device wan.832 dans /etc/config/network)
Donc si on veut rester en version stable d'OpenWrt, la version 24.10.2 avec nftables 1.1.1, puisque cette version de nftables est buggée, on est obligé de filtrer sur l'interface virtuelle (d'ailleurs je ne comprends pas pourquoi tu dis que c'est une mauvaise pratique).
Lorsque la version stable d'OpenWrt integrera nftables en version 1.1.3, alors oui la configuration pourra simplifiée : plus besoin de l'option egress_qos_mapping, on fixe la valeur du PCP directement, en filtrant sur l'interface physique...
...Les priorités internes des autres paquets sélectionnés étaient modifié ailleurs (tables inet et arp)...
C'est une remarque que je me suis faite, effectivement, mais j'ai voulu avoir toutes les règles qui modifient la priorité au même endroit. C'est un choix perso.
-
@pgid69 :
Non, ce n'est pas logique. L'utilisateur n'a pas à savoir comment sont implémentées les fonctionnalités.
Ce ne sont que d'ailleurs que des suppositions. En effet, rien n'indique qu'il faut filtrer sur l'interface virtuelle
(ni sur le Wiki ni dans la page de manuel nft). Et ce n'est pas faute d'avoir cherché à comprendre à un niveau
utilisateur en recoupant les informations. Il s'agit peut-être d'un autre bogue.
Il faut bien différencier la priorité interne (meta priority), le crochet egress (table netdev) et egress-qos-map.
-
@pgid69 :
Non, ce n'est pas logique. L'utilisateur n'a pas à savoir comment sont implémentées les fonctionnalités.
Ce ne sont que d'ailleurs que des suppositions. En effet, rien n'indique qu'il faut filtrer sur l'interface virtuelle
(ni sur le Wiki ni dans la page de manuel nft). Et ce n'est pas faute d'avoir cherché à comprendre à un niveau
utilisateur en recoupant les informations. Il s'agit peut-être d'un autre bogue.
Il faut bien différencier la priorité interne (meta priority), le crochet egress (table netdev) et egress-qos-map.
Tu trouves ca illogique, ok. Mais je te cite Cela ne fonctionnait pas sur l'interface physique lors de tests
alors qu'en filtrant sur l'interface virtuelle ca fonctionne. Il faut en tirer les conclusions qui s'imposent !!!
Je vais arreter d'essayer de prouver que la solution que j'ai proposée respecte ta logique, respecte ou pas tes bonnes pratiques... Ca me fatique !!!
Moi j'ai juste proposé une solution qui marche avec la derniere version stable d'OpenWrt, la 24.10.2 en récupérant juste le firmware sur le site, sans avoir a recompiler nftables...
J'ai appris plein de choses.
Je l'ai posté sur ce forum, pour éventuellement aider d'autres personnes, ayant moi même utilisé les informations trouvées sur ce forum.
Si d'autres ont une solution plus élégante qui fonctionne en restant en version stable stable d'OpenWrt, je serai très intéréssé de la connaitre, car ca me permettra sans aucun doute d'apprendre d'autres choses.
-
Nouvelle façon de modifier la QoS.
Ancienne façon de modifier la QoS. (https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/msg1079566/#msg1079566)
Remplacer IFACE_NAME dans le script nftables par le nom de l'interface physique WAN (e.g. eth0). Ajouter la table ci-dessous.
Cela nécessite nftables >= 1.1.3 et l'activation du support netdev dans le noyau Linux >= 5.16. Cela peut potentiellement ne pas
fonctionner pour tous les matériels. Donc, il faut tester. Vérifier que cela ne casse pas le pare-feu ou la configuration existante.
table netdev filter
flush table netdev filter
table netdev filter {
chain set_isp_vlan_832 {
udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter comment "Set QoS for DHCPv6 packets"
udp dport 67 vlan pcp set 6 ip dscp set cs6 counter comment "Set QoS for DHCPv4 packets"
icmpv6 type { 133, 135, 136 } vlan pcp set 6 ip6 dscp set cs6 counter comment "Set QoS for ICMPv6 packets"
vlan type arp vlan pcp set 6 counter comment "Set QoS for ARP packets"
}
chain egress {
type filter hook egress device IFACE_NAME priority filter; policy accept;
vlan id 832 jump set_isp_vlan_832
}
}
-
Pourquoi faire une chain egress qui redirige vers la chaine set_isp_vlan_832 ? Ca évite d'avoir le vlan de déjà créer / monté avant de pouvoir insérer les règles ? (sinon erreur indiquant missing iface ?)
Sinon tu peux remplacer (plus propre et lisible) 133, 135, 136 par nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert
Edit: dans ton exemple, tu ne tag pas l'ensemble des msg ARP en cos6 sur TOUS les vlans ?
-
@Mastah :
Merci pour ton retour !
Ma solution n'est pas forcément la seule référence possible. L'idée c'est aussi d'exposer le principe avec un exemple.
On sélectionne des paquets avec des expressions puis on modifie certains champs avec des déclarations adéquates.
vlan pcp set 6 c'est plus simple que meta priority set 0:6 + egress-qos-map.
Pourquoi faire une chain egress qui redirige vers la chaine set_isp_vlan_832 ? Ca évite d'avoir le vlan de déjà créer / monté avant de pouvoir insérer les règles ? (sinon erreur indiquant missing iface ?)
Non, c'est seulement une façon d'organiser les règles (chaîne régulière (https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Adding_regular_chains)). On pourrait tout placer dans la chaine egress. En outre, on fait
abstraction du concept d'interface virtuelle : IFACE_NAME est le nom de l'interface physique.
table netdev filter
flush table netdev filter
table netdev filter {
chain egress {
type filter hook egress device IFACE_NAME priority filter; policy accept;
vlan id 832 udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter comment "Set QoS for DHCPv6 packets"
vlan id 832 udp dport 67 vlan pcp set 6 ip dscp set cs6 counter comment "Set QoS for DHCPv4 packets"
vlan id 832 icmpv6 type { 133, 135, 136 } vlan pcp set 6 ip6 dscp set cs6 counter comment "Set QoS for ICMPv6 packets"
vlan id 832 vlan type arp vlan pcp set 6 counter comment "Set QoS for ARP packets"
}
}
-
Non, c'est seulement une façon d'organiser les règles (chaîne régulière (https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Adding_regular_chains)). On pourrait tout placer dans la chaine egress. En outre, on fait
abstraction du concept d'interface virtuelle : IFACE_NAME est le nom de l'interface physique.
Oui donc c'est ce que je dis, ça permet de mettre la règle nftable sans que l'interface vlan832 ne soit deja créé. Ca évite de faire de l'injection après la création de l'interface.
Tu confirmes ? Dans ton cas IFACE_NAME = wan et pas vlan832 ?
Autre question, dans ta solution tu n'as plus besoin de faire un
up ip l s $IFACE type vlan egress 6:6
?
-
@Mastah :
J'ai déjà répondu à ces questions. Dans le doute, essayes par toi-même.
Par définition, IFACE_NAME est une interface physique et vlan832 est une interface virtuelle.
Non, en appliquant ces règles, il n'est pas nécessaire de définir le paramètre egress-qos-map.
-
@Mastah :
J'ai déjà répondu à ces questions. Dans le doute, essayes par toi-même.
Par définition, IFACE_NAME est une interface physique et vlan832 est une interface virtuelle.
Non, en appliquant ces règles, il n'est pas nécessaire de définir le paramètre egress-qos-map.
C'est parce que ce n'était pas forcement claire que j'ai redemandé :)
J'en ai profité pour inclure ta solution sur mon wiki Debian 13.