C'est quand un coup de bol d'avoir 2 ips fixes Orange dans 2 range bien distincts. J'ai repéré sur le forum des users qui avaient le même serveur DHCP que moi.
Du coup, je m'étais dis que tout le monde avait le même serveur DHCP chez Orange...

Quand je vois la complexité de nftables vs PF (packet filter) d'openbsd, je me dis que y a des mecs qui doivent pas bien dormir ...
Mais bon, faut vivre avec son temps, pas vrai ?

J'ai quand même bcp appris sur ce post, certaines choses sont plus claires dans ma tete, c'est grace à toi  merci !
 

+1 vous ne voulez pas continuer ? Pour la beauté du geste ?

comme un air de moquerie ? 

Oh non, pas du tout. La curiosité et le challenge avant tout.
J'ai appris pleins de choses, lu assidûment et suis un peu déçu de ne pas voir au bout la solution malgré votre investissement.

moi aussi, surtout que je dois avoir un bidule mal configuré qque part, c'est stressant 

Du coup, en pièce jointe, j'ai posté l'ensemble de mes rêgles NFT, rule et routes.

J'ai anonymsé certaines IP.
J'ai retiré les modifs que nous avions faites pour tenter de solutionner le problème de re-routecheck histoire de repartir from scratch.

Perso si je devais faire ce que tu essayes de faire, j’utiliserais cgroups, et en particulier le network classifier group, ce qui permet d’une part d’avoir une table de routage spécifique pour chaque process, et d’autre part si besoin d’appliquer la CoS sans devoir patcher dhclient en utilisant le groupe network priority, comme certains l’ont déjà expliqué ici ( https://lafibre.info/remplacer-livebox/isc-dhcp-client-raw-socket-solution )

J’avoue que j’ai très peu joué avec cgroups (d’autant plus que le kernel de mon ER4 ne supporte pas le network priority group), mais il y a quelques pistes ici https://www.evolware.org/?p=369 par exemple).

 En pratique il s’agirait de mettre en place 2 groupes, un process dhclient dans chaque groupe avec la table de routage qui va bien.

Premièrement la route dans la table main avec nexthop ne fonctionne pas, c'est soit l'un soit l'autre.

Ah, c'est bien ce qu'il me semblait

Suite aux modifs proposées par Xavier, j'ai effectivement 3 logs par DHCPREQUEST.

Excellent.

Code: [Sélectionner]

Oct 03 08:31:10 cerber.nbux.org kernel: mangle/OUTPUT: entering IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=34374 PROTO=UDP SPT=68 DPT=67 LEN=391
Oct 03 08:31:10 cerber.nbux.org kernel: mangle/OUTPUT: about to mark IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=34374 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0x100
Oct 03 08:31:10 cerber.nbux.org kernel: mangle/OUTPUT: freshly marked IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=34374 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0xcafecafe


Tu remarqueras que le paquet se fait d'abord marquer en 0x100 avant de se faire marquer en 0xcafecafe (ou 0x200 comme initialement voulu). C'est peut-être dans cette zone que se situe le bloquage rencontré jusqu'à maintenant.

Ensuite, merci ZOC pour ta suggestion.
En réfléchissant (si si ça m'arrive , je ne vois pas comment marker mes paquets dans ces conditions sachant que l'interface ET l'IP source ne sont pas bons. Du coup, effectivement, il reste de le process (ou le skgid comme l'avait suggéré Xavier avant d'ailleurs).
J'ai modifié ma table mangle/OUTPUT en ajoutant un markage sur meta cgroup.

Oui, très clairement, comme déjà mentionné, tu ne PEUX PAS te baser sur les informations que tu veux corriger (ici : celles choisies lors du routage initial : IP source et interface de sortie) pour repérer les paquets qui t'intéressent, tu DOIS te baser sur une discrimination relative au processus ayant émis les paquets (uid ça a foiré, skgid c'est toujours sympa parce que c'est simple et réutilisable, cgroup je l'avais mentionné mais selon ton setup ça peut être un peu plus chiant à gérer) ou une discrimination relative au payload UDP (comme repérer ton login Orange dans le payload).

j'ai modifié mes rules :

Ça me semble un peu redondant. Je proposerais :
0:      from all lookup local
1:      from all fwmark 0x100 lookup 100
2:      from all fwmark 0x200 lookup 200
100:    from <iporange1> lookup 100
200:    from <iporange2> lookup 200
300:    from 192.168.4.254 lookup 300
301:    from all fwmark 0x300 lookup 300
500:    from 192.168.251.2 lookup 500
501:    from all fwmark 0x500 lookup 500
600:    from 10.4.102.16 lookup 600
601:    from all fwmark 0x600 lookup 600
700:    from 10.2.23.241 lookup 700
701:    from all fwmark 0x700 lookup 700
900:    from 10.3.5.248 lookup 900
901:    from all fwmark 0x900 lookup 900
32766:  from all lookup main
32767:  from all lookup default
À mon sens tu pourrais même grouper toutes tes rules fwmark au début et ensuite seulement te baser sur l'IP source. Mais c'est du chipotage à ce stade.

ensuite, j'ai ajouté les PID des process dhclient dans /sys/fs/cgroup/net_cls/dhcp-orange1|2/tasks et chacun avec son $cgroup_wanX dans /sys/fs/cgroup/net_cls/dhcp-orange1|2/net_cls.classid

Ça c'est à mon sens la partie "un peu plus chiant que changer le gid"... mais si par hasard c'est systemd qui lance tes dhclients, ça peut se simplifier. Dans tous les cas, cgroups ou skgid, ça reste ton choix, le principe restant le même : un reroute-check basé sur une fwmark elle-même basée sur une propriété du processus possédant le file descriptor du socket utilisé pour émettre les paquets.

Résultat, ca a marché de suite, le RENEW de l'interface orange2 est passé direct !

\o/

Par contre, ne sachant pas trop, dois-je ajouter les lignes de markage cgroup dans la chain OUTPUT AVANT le "meta mark set ct mark" final ?

Moi je vote non. Tu es sur un cas de marquage très simple (UDP, sortant, pas d'état, pas de tracking, pas de paquets liés, rien), ne gâche pas ça en prenant le risque de l'écraser à cause d'un marquage conntrack présent ou futur.

Est-ce une bonne idée, je ne sais pas ... qu'en pensez-vous ? d'un point de vue perf, c'est surement mieux non ?

Les performances c'est bien mais la maintenabilité et la stabilité sont à prendre en compte aussi. Ne risque pas des heures de prises de tête dans le futur pour épargner 10 microsecondes ici et là.

Enfin, c'est vrai que ce serait plus simple sans utiliser les cgroup et d'arriver à marker les paquets avec une regle mangle/OUTPUT

Mais c'est ce que tu fais. Tu marques tes paquets dans mangle/OUTPUT. Et cette fois ça fonctionne.

mais compte-tenu des caractéristiques des paquets, avec l'ip source et l'interface qui correspondent bien (alors que c'est faux), j'avoue que je ne vois pas trop comment faire.

Je te sens encore très très confus sur le sujet, mais je ne peux que réitérer l'explication :
1 - la route choisie lors de l'émission du paquet par le processus est fausse parce qu'à ce stade le système n'a pas connaissance de la discrimination que tu souhaites implémenter. Cela lui assigne une IP source erronée et une interface de sortie erronée, ce qui ruine effectivement tes chances de filtrer sur ces éléments.
2 - marquer tes paquets dans mangle/OUTPUT t'offre la possibilité de réévaluer leur route, ce qui, combiné à une ip rule fwmark corrige leur interface de sortie (yay !)
3 - l'IP source est corrigée par le masquerading
4 - profit!

C'est peut-être plus simple et plus flexible, il suffirait de faire tourner les process dans leur groupe...

avec leur groupe

La question qui persiste, est de savoir s'il faut mettre les regles nft avant ou apres le 'meta mark set ct mark' final de la chain OUTPUT ?

Je confirme mon vote : skgid, après le "meta mark set ct mark".

Et dois-je marké les paquets dans les chains mangle/OUTPUT, mangle/PRETROUTING et mangle/POSTROUTING comme je le fais, ou bien mangle/OUTPUT et mangle/PREROUTING ne suffirait-il pas ?

Je ne suis pas sûr de te suivre pour cette dernière question ; je n'ai pas analysé l'intégralité de tes nftables mais je peux te confirmer que dans le cadre de cette histoire de discrimination sur les paquets DHCP sortants, il est nécessaire et suffisant de marquer ces paquets dans mangle/OUTPUT (ou devrais-je dire dans "type route hook output priority mangle").