Hello,
Tu n'as pas précisé tes contraintes de déploiement (c'est quoi ton routeur, hardware, kernel, distribution, ce que tu peux configurer, ce que tu es prêt à configurer, etc.) du coup c'est un peu difficile de te répondre.
Comme ça parle de supersede (=isc-dhcp-client) à droite et d'iptables à gauche, je vais imaginer que tu as un isc-dhcp-client sur un Linux quelconque, sur lequel tu peux facilement ajouter de nouveaux outils en userland mais pas forcément passer sur un nouveau kernel.
Petit enfonçage de porte ouverte : la route <dhcp_server_ip> via <ma_gw_orange> dev <mon_iface_orange> est idéalement à ajouter dynamiquement via un hook DHCP.
Si tu as deux connexions séparées sur deux interfaces séparées avec un dhclient chacune, je vois deux grandes approches.
Approche 1 : séparation par utilisateur Unix :
1 tu t'arranges pour que le dhclient pour ton interface orange0 tourne avec un utilisateur différent du dhclient pour ton interface orange1
2a si ton kernel est un peu vieux :
2a.1 tu joues avec iptables -m owner --uid-owner pour mark-er les paquets qui t'intéressent
2a.2 tu joues avec ip rule et fwmark pour que chaque client DHCP ait sa propre table de routage. Note : c'est généralement assez chiant car il faut parfois prendre en compte les subtilités du genre "est-ce que au sein du kernel, le socket est toujours associé à un pid et donc à un couple uid/gid ou est-ce que le processus a close() et est mort depuis longtemps ?" ainsi que "fwmark, connmark, ou les deux ?"
2b si ton kernel est assez récent : tu joues avec ip rule et uidrange, c'est normalement beaucoup, beaucoup moins chiant.
Approche 2 : séparation par network namespace :
L'idée serait de faire tourner tes dhclients dans des network namespaces à part, dans lesquels tu déplacerais tes interfaces physiques, un peu comme si tu décidais d'avoir deux containers router0 et router1 mais avec juste le strict minimum. C'est élégant mais ça peut devenir compliqué parce que :
- une interface ne peut appartenir qu'à un seul network namespace
- un processus ne peut appartenir qu'à un seul network namespace (attention au monitoring)
Au final, cette technique implique de construire, au boot de ton routeur, un ou deux network namespaces, d'y assigner, activer et configurer toutes les interfaces réseau qui vont bien (tes interfaces physiques mais aussi la boucle locale et probablement des interfaces virtuelles), d'y ajouter les routes et iptables adéquates et enfin d'y lancer tes dhclients.
C'est fatigant. Mais c'est une solution.