Je ne suis pas encore prêt pour les namespace, que je ne maîtrise pas...

En fait, pour la petite histoire, j'ai utilisé ça au boulot pour simplifier un setup qui était devenu relativement complexe : marquage par uid, conntrack TCP, copie conntrack->fwmark, remplissage des tables de routage, reroute-check, masquerading uniquement pour corriger l'IP source, rp_filter=2 pour ne pas refuser les réponses, chacun de ces petits détails étant requis pour que la connexion TCP fonctionne correctement.
Là où ça a vraiment apporté un double gain de maintenabilité, c'est que le netns principal ne sert que pour une interface d'administration et une table de routage triviale. Le netns spécifique peut être détruit, modifié, cassé, manipulé par des outils d'automatisation (think: Puppet/SaltStack/Chef/Ansible) sans jamais risquer de perdre la connexion à la machine.
Et depuis je ne rêve que de segmenter toutes les manips réseaux qui constituent ma gateway en de petits netns (network namespaces) tout propres avec des tables de routage simples. Au détriment d'une perte de performances (théorique ? sensible ?) à mesure que le kernel s'amuse à faire circuler le trafic d'un namespace à un autre. Comme souvent en I.T., on ne peut pas tout avoir (performances maximales, maintenabilité, sécurité, pérennité).

À noter que les cgroups sont un pas vers les namespaces dans la mesure où ces deux technologies sont les principales fondations des containers sous Linux.

Par contre, pour le RENEW DHCP, je trouve assez fastidieux de devoir mettre à jour le PID dans le fichier tasks. Si pour une raison ou une autre, la mise à jour du pid ne fonctionne pas, c'est un coup a chercher pendant des heures. le skgid, me semble plus simple pour cela.

Alors, pour rendre à César ce qui est à César : le topic mentionné par zoc utilise des commandes cg* pour lancer dhclient directement dans le cgroup netprio adéquat plutôt que de l'y déplacer après lancement (= la race condition assurée).

Sinon, j'utilise effectivement systemd pour lancer les dhclient, quand tu dis qu'il y a des facilités cgroup, tu penses à quoi comme variable ? j'ai regardé vite fait et je n'est rien trouvé de spécial sur la partie cgroup/ip/routage.

systemd lance TOUT dans des cgroups dédiés... c'est tout simplement comme ça qu'il traque les processus relatifs à un service (finis les fichiers pid avec les race conditions qui vont avec). Tu peux voir ça avec systemd-cgls ou dans une moindre mesure avec systemctl status. Donc en théorie tu dois pouvoir simplement filtrer sur quelque chose comme -m cgroup --path system.slice/isc-dhcp-client@orange1.service (syntaxe iptables). Cela dit, j'ai comme l'impression que nftables n'offre pas les mêmes fonctionnalités qu'iptables pour matcher sur les cgroups (ça parle de matcher sur un cgroup number, je vois pas qui ça intéresse).

Ensuite, quand je trouvais dommage de ne pas pouvoir utiliser uniquement une regles mangle/OUTPUT, je suggérais de se passer de tout autre mécanisme comme le skgid. Et donc en analysant uniquement les caractéristiques 'standards' des paquets RENEW.

Ah oui, ça, c'est juste mort.

De plus, visiblement les rules [...]
Qu'en penses-tu ?

C'est marrant que ça ne fonctionne pas avec ipproto udp sport 68 dport 67, il y a peut-être un bug sous-jacent.
Mais pour réitérer mes recommandations : ne duplique pas tes discriminations. Tu as déjà discriminé sur UDP sport 68 dport 67 dans Netfilter/nftables et tu as associé cette discrimination aux fwmark 0x100 et 0x200. Plus besoin de répéter ces discriminations dans ip rule. Dans ip rule, tu mentionnes la fwmark, qui signifie non plus "le trafic DHCP machin truc" mais "ce qui doit être routé en utilisant la table de routage 0x100 / 0x200" et basta.
Je confirme que ça me semble une bonne idée de mettre toutes les ip rule fwmark en priorité. Si ça a des effets de bord, c'est probablement que tu as du trafic mal marqué.
Enfin, un mot sur toutes les rules "from x.x.x.x lookup xxx" : ces rules supposent que l'IP source est déjà connue et correcte au moment du routage. À manipuler avec précaution donc.

Pour les namespace, je vais creuser. Je me souviens avoir lu une petite doc sur wireguard et les namespace. Mais je ne sais pas si c'est applicable dans mon cas de gateway load-balancer multiwan. J'ai du routage évidemment, mais surtout du markage de paquets qui est (je pense) indispensable à mes use-cases. Si tu as une petite doc ou des liens interessants la-dessus, je suis preneur...

Je n'ai pas spécialement de doc en tête mais d'après mon historique, j'avais lu ça : https://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/
À noter que le namespacing ne nuit normalement à aucune des techniques utilisées pour marquer, router ou filtrer des paquets (sauf peut-être les techniques qui souffriraient d'une segmentation physique).
J'ai chez moi un cas similaire mais plus simple (gateway + VPN + failover fibre->LTE) ; j'ai schématisé ce que ça donnerait si j'injectais un maximum de network namespaces, voir schéma ci-joint.

Enfin, pour mes rules "from x.x.x.x lookup xxx", je me demande si elles sont vraiment utiles ?

Je me suis posé la question aussi. De par l'apparente complexité de ton setup, je n'ai pas de réponse d'autorité à te fournir

J'ai trouvé un petit script de config générique nftables / mutlwan :
On voit que dans ce script (je n'ai pas encore testé) :
- le markage se fait uniquement dans mangle/prerouting. Pas dans output ni postrouting.

Dans mon cas, je m'embête à marquer dans output, prerouting et postrouting. Est-ce bien utile ?

mangle/output, c'est clairement un cas particulier pour rerouter du trafic local sortant, ton dhclient quoi.
mangle/prerouting a beaucoup de sens pour du trafic forwardé (le job principal d'un routeur quoi) parce qu'à ce niveau les paquets sont plus ou moins garantis frais/intacts/pas retouchés.
du marquage dans mangle/postrouting... effectivement, cette partie là n'a peut-être pas de sens, du moins pas pour influer sur le routing (puisque, par définition, dans postrouting, il est trop tard pour router ou re-router).

- il y a juste une restauration dans mangle/postrouting.

Elle ne semble pas servir à grand chose.

- pas de rule "from x.x.x.x lookup xxx", uniquement "fmwark xxx lookup xxx"

De même, je me demande si mes rules "from x.x.x.x lookup xxx" sont nécessaires ...

Clairement, si tout le trafic est marqué, les rules fwmark doivent suffire.

Il n’y a pas d’explication, mais il doit bien y avoir une raison...

« copied from forum-posting by user aldoir Dual-WAN forum posting » -- peut-être parce qu'on est des milliers à adapter des confs trouvées ici et là à grands coups de copier-coller et qu'à force il s'y accumule des choses inutiles, comme du calcaire dans une machine à laver ?
Cela dit, ça met le doigt sur un autre principe important : toujours documenter le "pourquoi".

On te fait confiance pour réduire le nombre de lignes de configuration au strict minimum. Avec un peu de temps et de patience, tu dois pouvoir associer une explication à chaque ligne que tu conserves.

C'est complètement hors-scope pour dhclient (il émet et reçoit des paquets sur une interface réseau, il ne monitore pas la santé des liens physiques en aval [ou amont, question de point de vue]). Cela dit, tu peux utiliser divers outils de monitoring pour surveiller ta connectivité et agir sur dhclient en conséquence. Par exemple, tu pourrais utiliser lsm avec un event script qui relance ton dhclient.

Sais-tu s'il y a un moyen propre de dire à un daemon DHCP existant de forcer son RENEW ? je n'ai rien vu dans le genre. j'ai bien essayé kill -1, mais le dhclient tombe.

C'est spécifique à chaque implémentation. Dans le cas du client DHCP de l'ISC, il y a une interface « OMAPI » pour accéder à un « control object », mais honnêtement...

J'aimerais éviter le restart pur et dur du process.

... je ne pense pas que le jeu en vaille la chandelle. Claque un restart et basta