Auteur Sujet: Filtrer les raw socket avec nftables ? (Lu 5628 fois)

Mastah · « **Réponse #72 le:** 28 juillet 2024 à 23:02:40 »

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.

basilix · « **Réponse #73 le:** 29 juillet 2024 à 07:37:15 »

@Mastah :

https://www.mankier.com/8/nft#Address_Families-Netdev_Address_Family

J'aurais peut-être une explication dans le courant de la semaine.

cyayon · « **Réponse #74 le:** 29 juillet 2024 à 10:26:17 »

Citation de: Mastah le 28 juillet 2024 à 23:02:40

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

Mastah · « **Réponse #75 le:** 29 juillet 2024 à 14:29:59 »

Citation de: cyayon le 29 juillet 2024 à 10:26:17

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.

cyayon · « **Réponse #76 le:** 29 juillet 2024 à 15:42:23 »

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

Code: [Sélectionner]

[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 :

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"
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

cyayon · « **Réponse #77 le:** 29 juillet 2024 à 19:08:00 »

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) ?

Mastah · « **Réponse #78 le:** 29 juillet 2024 à 22:28:47 »

Citation de: cyayon le 29 juillet 2024 à 19:08:00

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.

cyayon · « **Réponse #79 le:** 29 juillet 2024 à 22:30:41 »

Merci

Mastah · « **Réponse #80 le:** 29 juillet 2024 à 22:37:06 »

Citation de: cyayon le 29 juillet 2024 à 22:30:41

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.

basilix · « **Réponse #81 le:** 03 août 2024 à 09:03:02 »

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.
« L'information dans l'en-tête des trames n'est disponible que dans le chemin en entrée. » (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.
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.

Code: [Sélectionner]

   # payload statement
   ip saddr 10.1.1.1 icmp type echo-request vlan id set 321

cyayon · « **Réponse #82 le:** 03 août 2024 à 10:29:33 »

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 …

basilix · « **Réponse #83 le:** 03 août 2024 à 12:26:16 »

@cyayon :

La documentation sur le sujet manque terriblement. Il faut chercher dans les sources et faire des hypothèses.

Citation de: lwn.net

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.

Code: (vlan_mangling) [Sélectionner]

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

Citer

Attachment: changes-nftables-1.1.0.txt (type=text/plain)
[...]
Pablo Neira Ayuso (101):
[...]
tests: shell: add vlan mangling test case