Merci bcp pour tes retours très instructifs !

Moi j'ai préparé cela (avec $iface_wan1 étant mon interface dans le vlan832 - nommée orange1 ) :

Code: [Sélectionner]

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

Code: [Sélectionner]

#!/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

Code: [Sélectionner]

# 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.

Voir aussi Arch Wiki: Simple firewall.

@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.

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 :

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.

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.