Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Nftables/Conntrack: confusion ctmark/fwmark

2 réponses
Avatar
Olivier
--000000000000a6acde05cea13376
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

--000000000000a6acde05cea13376
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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&#39;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&#39;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.</div><div>Comment l&#39;obtenir ?</div><div><br></div><div>J&#39;ai essay̓© (sans succ̓¨s) o̓¹ ens3.432 est le nom de l&#39;interface (virtuelle) sur laquelle le trafic est re̓§u:</div><div><br></div><div>add rule ip mangle input iifname &quot;ens3.432&quot; meta mark 0 log prefix &quot;Rule42-A1&quot; counter ct mark set 0x2</div><div><br></div><div>La table mangle et sa chaine input sont d̓©finies par:</div><div><br></div><div>table mangle {<br> chain prerouting { type filter hook prerouting priority -150; }<br> chain input { type filter hook input priority -150; }<br> 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&#39;observe que:</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 &quot;conntrack -L -o id,extended&quot; montre qu&#39;une marque est appliqu̓©e sur le rafic avec l&#39;̓©metteur<br></div><div><br></div><div>- la r̓©ponse est ̓©mise vers l&#39;̓©metteur avec la bonne adresse source mais une autre interface (celle par d̓©faut).</div><div><br></div><div>Ces deux observations me laissent pense que la r̓¨gle &quot;fwmark 0x2 lookup link2&quot; est ignor̓©e.</div><div>Cette conviction est renforc̓©e par le fait que quand je remplace cette r̓¨gle par une r̓¨gle bas̓©e sur l&#39;IP source (&quot;from <a href="http://192.168.17.0/24">192.168.17.0/24</a> lookup link2&quot;), l&#39;̓©metteur re̓§oit la r̓©ponse via la bonne interface.</div><div>Comme l&#39;interface est configur̓©e par DHCP, j&#39;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).</div><div><br></div><div>J&#39;ai l&#39;impression que:</div><div>soit il y a une confusion de ma part entre les marques de conntrack et celles de nftables,</div><div>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></div>

--000000000000a6acde05cea13376--

2 réponses

Avatar
Olivier
--000000000000369b3f05cea13aeb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 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

--000000000000369b3f05cea13aeb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="ltr"><div>Dans [1], j&#39;ai lu:</div><div>nft add rule inet classify output ip daddr 1.1.1.1 ct mark set numgen inc mod 3 offset 390
<br>
nft add rule inet classify output ip daddr 1.1.1.1 meta mark set ct mark</div><div><br></div><div>Qui pourrait m&#39;expliquer ces 2 lignes ?<br></div><div><br></div><div>[1] <a href="https://forums.gentoo.org/viewtopic-t-1136379-start-0.html">https://forums.gentoo.org/viewtopic-t-1136379-start-0.html</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le͂ lun. 18 oct. 2021 ̓ ͂ 16:17, Olivier &lt;<a href="mailto:"></a>&gt; a ̓©crit͂ :<br></div><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&#39;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&#39;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.</div><div>Comment l&#39;obtenir ?</div><div><br></div><div>J&#39;ai essay̓© (sans succ̓¨s) o̓¹ ens3.432 est le nom de l&#39;interface (virtuelle) sur laquelle le trafic est re̓§u:</div><div><br></div><div>add rule ip mangle input iifname &quot;ens3.432&quot; meta mark 0 log prefix &quot;Rule42-A1&quot; counter ct mark set 0x2</div><div><br></div><div>La table mangle et sa chaine input sont d̓©finies par:</div><div><br></div><div>table mangle {<br> chain prerouting { type filter hook prerouting priority -150; }<br> chain input { type filter hook input priority -150; }<br> 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&#39;observe que:</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 &quot;conntrack -L -o id,extended&quot; montre qu&#39;une marque est appliqu̓©e sur le rafic avec l&#39;̓©metteur<br></div><div><br></div><div>- la r̓©ponse est ̓©mise vers l&#39;̓©metteur avec la bonne adresse source mais une autre interface (celle par d̓©faut).</div><div><br></div><div>Ces deux observations me laissent pense que la r̓¨gle &quot;fwmark 0x2 lookup link2&quot; est ignor̓©e.</div><div>Cette conviction est renforc̓©e par le fait que quand je remplace cette r̓¨gle par une r̓¨gle bas̓©e sur l&#39;IP source (&quot;from <a href="http://192.168.17.0/24" target="_blank">192.168.17.0/24</a> lookup link2&quot;), l&#39;̓©metteur re̓§oit la r̓©ponse via la bonne interface.</div><div>Comme l&#39;interface est configur̓©e par DHCP, j&#39;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).</div><div><br></div><div>J&#39;ai l&#39;impression que:</div><div>soit il y a une confusion de ma part entre les marques de conntrack et celles de nftables,</div><div>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></div>
</div>
--000000000000369b3f05cea13aeb--
Avatar
Olivier
--0000000000003ef5ae05cedb1d83
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
D'apr̓¨s mes essais, il semble que la marque appel̓©e fwmark dans ip rule
correspond ̓  une marque sur le paquet (mark) et pas celle sur les
connexions (connmark).
J'esp̓¨re que ̓§a pourra aider quelqu'un d'autre.
Slts
Le lun. 18 oct. 2021 ̓  16:18, Olivier a ̓©crit :
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 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


--0000000000003ef5ae05cedb1d83
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="ltr"><div>D&#39;apr̓¨s mes essais, il semble que la marque appel̓©e fwmark dans ip rule correspond ̓  une marque sur le paquet (mark) et pas celle sur les connexions (connmark).</div><div><br></div><div>J&#39;esp̓¨re que ̓§a pourra aider quelqu&#39;un d&#39;autre.</div><div>Slts<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le͂ lun. 18 oct. 2021 ̓ ͂ 16:18, Olivier &lt;<a href="mailto:"></a>&gt; a ̓©crit͂ :<br></div><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>Dans [1], j&#39;ai lu:</div><div>nft add rule inet classify output ip daddr 1.1.1.1 ct mark set numgen inc mod 3 offset 390
<br>
nft add rule inet classify output ip daddr 1.1.1.1 meta mark set ct mark</div><div><br></div><div>Qui pourrait m&#39;expliquer ces 2 lignes ?<br></div><div><br></div><div>[1] <a href="https://forums.gentoo.org/viewtopic-t-1136379-start-0.html" target="_blank">https://forums.gentoo.org/viewtopic-t-1136379-start-0.html</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le͂ lun. 18 oct. 2021 ̓ ͂ 16:17, Olivier &lt;<a href="mailto:" target="_blank"></a>&gt; a ̓©crit͂ :<br></div><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&#39;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&#39;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.</div><div>Comment l&#39;obtenir ?</div><div><br></div><div>J&#39;ai essay̓© (sans succ̓¨s) o̓¹ ens3.432 est le nom de l&#39;interface (virtuelle) sur laquelle le trafic est re̓§u:</div><div><br></div><div>add rule ip mangle input iifname &quot;ens3.432&quot; meta mark 0 log prefix &quot;Rule42-A1&quot; counter ct mark set 0x2</div><div><br></div><div>La table mangle et sa chaine input sont d̓©finies par:</div><div><br></div><div>table mangle {<br> chain prerouting { type filter hook prerouting priority -150; }<br> chain input { type filter hook input priority -150; }<br> 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&#39;observe que:</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 &quot;conntrack -L -o id,extended&quot; montre qu&#39;une marque est appliqu̓©e sur le rafic avec l&#39;̓©metteur<br></div><div><br></div><div>- la r̓©ponse est ̓©mise vers l&#39;̓©metteur avec la bonne adresse source mais une autre interface (celle par d̓©faut).</div><div><br></div><div>Ces deux observations me laissent pense que la r̓¨gle &quot;fwmark 0x2 lookup link2&quot; est ignor̓©e.</div><div>Cette conviction est renforc̓©e par le fait que quand je remplace cette r̓¨gle par une r̓¨gle bas̓©e sur l&#39;IP source (&quot;from <a href="http://192.168.17.0/24" target="_blank">192.168.17.0/24</a> lookup link2&quot;), l&#39;̓©metteur re̓§oit la r̓©ponse via la bonne interface.</div><div>Comme l&#39;interface est configur̓©e par DHCP, j&#39;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).</div><div><br></div><div>J&#39;ai l&#39;impression que:</div><div>soit il y a une confusion de ma part entre les marques de conntrack et celles de nftables,</div><div>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></div>
</div>
</div>
--0000000000003ef5ae05cedb1d83--