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.
La solution se trouve dans le post de Mastah !! (https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/msg1079566/#msg1079566)
-
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
}
}