soit il y a une erreur dans la définition de la chaine input ou sa table mangle,</div><div>soit encore autre chose.</div><div><br></div><div>Qui pourrait me mettre sur la bonne voie ?</div><div><br></div><div>Slts<br></div><div><br></div><div><br></
</div>
Bonjour,
Je découvre nftables sur une machine équipée de Bullseye.
Sur cette machine j'ai les règles:
# ip rule show
0: from all lookup local
0: from all fwmark 0x2 lookup link2
32766: from all lookup main
32767: from all lookup default
J'aimerai que nftables ajoute une marque donnée pour le trafic non-marqué reçu sur une interface Ethernet donnée, auto-configurée par DHCP.
Comment l'obtenir ?
J'ai essayé (sans succès) où ens3.432 est le nom de l'interface (virtuelle) sur laquelle le trafic est reçu:
add rule ip mangle input iifname "ens3.432" meta mark 0 log prefix "Rule42-A1" counter ct mark set 0x2
La table mangle et sa chaine input sont définies par:
table mangle {
chain prerouting { type filter hook prerouting priority -150; }
chain input { type filter hook input priority -150; }
chain forward { type filter hook forward priority -150; }
chain output { type route hook output priority -150; }
chain postrouting { type filter hook postrouting priority -150; }
}
Dans les faits, j'observe que:
- la règle mangle ci-dessus est exécutée car je elle figure dans les logs et la commande "conntrack -L -o id,extended" montre qu'une marque est appliquée sur le rafic avec l'émetteur
- la réponse est émise vers l'émetteur avec la bonne adresse source mais une autre interface (celle par défaut).
Ces deux observations me laissent pense que la règle "fwmark 0x2 lookup link2" est ignorée.
Cette conviction est renforcée par le fait que quand je remplace cette règle par une règle basée sur l'IP source ("from 192.168.17.0/24 lookup link2"), l'émetteur reçoit la réponse via la bonne interface.
Comme l'interface est configurée par DHCP, j'aimerai autant que possible
ne pas utiliser de règle faisant intervenir des données que je ne maîtrise pas (ie celles fournies par le serveur DHCP).
J'ai l'impression que:
soit il y a une confusion de ma part entre les marques de conntrack et
celles de nftables,
soit il y a une erreur dans la définition de la chaine input ou sa table mangle,
soit encore autre chose.
Qui pourrait me mettre sur la bonne voie ?
Slts
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Bonjour,</div><div><br></div><div>Je découvre nftables sur une machine équipée de Bullseye.</div><div><br></div><div>Sur cette machine j'ai les règles:</div><div><br></div><div># ip rule show<br>0: from all lookup local<br>0: from all fwmark 0x2 lookup link2<br>32766: from all lookup main<br>32767: from all lookup default<br></div><div><br></div><div>J&#
Dans [1], j'ai lu:
nft add rule inet classify output ip daddr 1.1.1.1 ct mark set numgen inc
mod 3 offset 390
nft add rule inet classify output ip daddr 1.1.1.1 meta mark set ct mark
Qui pourrait m'expliquer ces 2 lignes ?
[1] https://forums.gentoo.org/viewtopic-t-1136379-start-0.html
Le lun. 18 oct. 2021 à 16:17, Olivier <oza.4h07@gmail.com> a écrit :
Bonjour,
Je découvre nftables sur une machine équipée de Bullseye.
Sur cette machine j'ai les règles:
# ip rule show
0: from all lookup local
0: from all fwmark 0x2 lookup link2
32766: from all lookup main
32767: from all lookup default
J'aimerai que nftables ajoute une marque donnée pour le trafic non-marqué >> reçu sur une interface Ethernet donnée, auto-configurée par DHCP.
Comment l'obtenir ?
J'ai essayé (sans succès) où ens3.432 est le nom de l'interface
(virtuelle) sur laquelle le trafic est reçu:
add rule ip mangle input iifname "ens3.432" meta mark 0 log prefix
"Rule42-A1" counter ct mark set 0x2
La table mangle et sa chaine input sont définies par:
table mangle {
chain prerouting { type filter hook prerouting priority -150; }
chain input { type filter hook input priority -150; }
chain forward { type filter hook forward priority -150; }
chain output { type route hook output priority -150; }
chain postrouting { type filter hook postrouting priority -150; }
}
Dans les faits, j'observe que:
- la règle mangle ci-dessus est exécutée car je elle figure dans les logs >> et la commande "conntrack -L -o id,extended" montre qu'une marque est
appliquée sur le rafic avec l'émetteur
- la réponse est émise vers l'émetteur avec la bonne adresse source mais >> une autre interface (celle par défaut).
Ces deux observations me laissent pense que la règle "fwmark 0x2 lookup
link2" est ignorée.
Cette conviction est renforcée par le fait que quand je remplace cette
règle par une règle basée sur l'IP source ("from 192.168.17.0/24 lookup >> link2"), l'émetteur reçoit la réponse via la bonne interface.
Comme l'interface est configurée par DHCP, j'aimerai autant que possible
ne pas utiliser de règle faisant intervenir des données que je ne maîtrise
pas (ie celles fournies par le serveur DHCP).
J'ai l'impression que:
soit il y a une confusion de ma part entre les marques de conntrack et
celles de nftables,
soit il y a une erreur dans la définition de la chaine input ou sa table
mangle,
soit encore autre chose.
Qui pourrait me mettre sur la bonne voie ?
Slts
chain forward { type filter hook forward priority -150; }<br> chain output { type route hook output priority -150; }<br> chain postrouting { type filter hook postrouting priority -150; }<br>}</div><div><br></div><div>Dans les faits, j'observeque:</div><div><br></div><div>- la règle mangle ci-dessus est exécutée car je elle figure dans les logs et la commande "conntrack -L -o id,extended" montre qu'une marque est appliquée sur le rafic avec l'émetteur<br></div><div><br><
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 83:58:52 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,097 |
Messages: | 5,276,894 |