j'ai plusieurs accès internet, plusieurs dongles et connections wifi
ouvertes, mais tous les programmes accent à internet via le même lien,
comment attribuer un lien wifi à un logiciel ?
Ok, donc avec un système de conteneurs (virtualisation légère) auxquels tu affectes un bridge et donc la configuration réseau qui te sied sur l'hôte.
J'ai donné un lien avec l'utilisation de namespaces sans conteneurs.
Les vrf semblent permettre d'éviter l'utilisation de conteneurs et donc probablement éliminer l'overhead de ces derniers.
Ils utilisent probablement les namespaces.
En fait, je crois que pas mal de trucs dans netfilter sont simplement entrain d'être réimplémentés, pour de bonnes ou de mauvaises raisons, je ne sais pas.
Je ne connais pas assez Linux pour avoir une idée définitive sur le sujet (j'utilise principalement OpenWRT/LEDE), mais je trouve que l'UI (cli) pour les fonctionnalités réseau est plutôt fouillis et que rien n'est vraiment documenté de façon exhaustive.
Dans mon expérience, netfilter est très logique et très bien documenté. La seule difficulté est si la fonction dont tu as besoin n'a pas été compilée par ta distribution (j'ai dû l'une et l'autre fois compiler un ou l'autre module très spécifique, typiquement SAVEMARK -- aujourd'hui intégré dans ma LTS).
Eric Masson <emss@free.fr> wrote:
Ok, donc avec un système de conteneurs (virtualisation légère) auxquels
tu affectes un bridge et donc la configuration réseau qui te sied sur
l'hôte.
J'ai donné un lien avec l'utilisation de namespaces sans conteneurs.
Les vrf semblent permettre d'éviter l'utilisation de conteneurs et donc
probablement éliminer l'overhead de ces derniers.
Ils utilisent probablement les namespaces.
En fait, je crois que pas mal de trucs dans netfilter sont
simplement entrain d'être réimplémentés, pour de bonnes
ou de mauvaises raisons, je ne sais pas.
Je ne connais pas assez Linux pour avoir une idée définitive sur le
sujet (j'utilise principalement OpenWRT/LEDE), mais je trouve que l'UI
(cli) pour les fonctionnalités réseau est plutôt fouillis et que rien
n'est vraiment documenté de façon exhaustive.
Dans mon expérience, netfilter est très logique et très bien documenté.
La seule difficulté est si la fonction dont tu as besoin n'a pas été
compilée par ta distribution (j'ai dû l'une et l'autre fois compiler
un ou l'autre module très spécifique, typiquement SAVEMARK --
aujourd'hui intégré dans ma LTS).
Ok, donc avec un système de conteneurs (virtualisation légère) auxquels tu affectes un bridge et donc la configuration réseau qui te sied sur l'hôte.
J'ai donné un lien avec l'utilisation de namespaces sans conteneurs.
Les vrf semblent permettre d'éviter l'utilisation de conteneurs et donc probablement éliminer l'overhead de ces derniers.
Ils utilisent probablement les namespaces.
En fait, je crois que pas mal de trucs dans netfilter sont simplement entrain d'être réimplémentés, pour de bonnes ou de mauvaises raisons, je ne sais pas.
Je ne connais pas assez Linux pour avoir une idée définitive sur le sujet (j'utilise principalement OpenWRT/LEDE), mais je trouve que l'UI (cli) pour les fonctionnalités réseau est plutôt fouillis et que rien n'est vraiment documenté de façon exhaustive.
Dans mon expérience, netfilter est très logique et très bien documenté. La seule difficulté est si la fonction dont tu as besoin n'a pas été compilée par ta distribution (j'ai dû l'une et l'autre fois compiler un ou l'autre module très spécifique, typiquement SAVEMARK -- aujourd'hui intégré dans ma LTS).
Marc SCHAEFER
Pascal Hambourg wrote:
Va dire à un processus d'utiliser une table de routage particulière et on en reparle.
Je n'ai jamais fait ça. Toutefois, avant les namespaces et les VRF, il semblerait qu'on pouvait utiliser les MARK et: https://stackoverflow.com/questions/4314163/create-iptables-rule-per-process-service a) soit utiliser --pid-owner (qui semble, toutefois, avoir des limitations) b) soit utiliser un hack avec un gid supplémentaire spécifique à ce processus Avec les namespaces, on pouvait utiliser les MARK et la table de routage dépendant d'un MARK. Ou simplement configurer une table de routage dans un namespace et mettre le processus dedans: https://roidelapluie.be/blog/2015/10/13/specific-routing-table/ Et aujourd'hui (2017+?), on peut utiliser VRF + namespaces.
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
Va dire à un processus d'utiliser une table de routage particulière et
on en reparle.
Je n'ai jamais fait ça.
Toutefois, avant les namespaces et les VRF, il semblerait qu'on pouvait
utiliser les MARK et:
Va dire à un processus d'utiliser une table de routage particulière et on en reparle.
Je n'ai jamais fait ça. Toutefois, avant les namespaces et les VRF, il semblerait qu'on pouvait utiliser les MARK et: https://stackoverflow.com/questions/4314163/create-iptables-rule-per-process-service a) soit utiliser --pid-owner (qui semble, toutefois, avoir des limitations) b) soit utiliser un hack avec un gid supplémentaire spécifique à ce processus Avec les namespaces, on pouvait utiliser les MARK et la table de routage dépendant d'un MARK. Ou simplement configurer une table de routage dans un namespace et mettre le processus dedans: https://roidelapluie.be/blog/2015/10/13/specific-routing-table/ Et aujourd'hui (2017+?), on peut utiliser VRF + namespaces.
Marc SCHAEFER
Eric Belhomme <rico-{nospam}@ricozome.net> wrote:
En ayant zyeuté 30 secondes le lien posté par Eric, j'ai vu une usine à gaz qui monte des ponts virtuels pour faire du transit entre eux. Je n'ai pas pris plus le temps que ça de regarder ce que ça fait, mais la big picture, c'est du bridging. Si je me gourre, merci de me faire voir la lumière ;)
En fait, je pense que ce Linux VRF sert à tout autre chose. Il doit servir à pouvoir implémenter du routage dans des réseaux MPLS, où le routage est basé flux plutôt qu'adresse destination. Il y a d'ailleurs de plus en plus de bruit chez les opérateurs pour des protocoles de routage plus simple, basé `Flow' qui permettraient de simplifier aussi certains protocoles de routage. Il y a des chances que ce Linux VRF a été développé comme solution `plug-in' alternative à Cisco VRF. La portée de cette solution et sa généralité *semble* être un peu le canon à mouches comme tu dit pour le problème énoncé ici. Si je devais réaliser un tel routage par processus, je pense que je ferais du MARK dans des namespaces, aujourd'hui. Ou que je jouerais avec des groupes supplémentaires.
Eric Belhomme <rico-{nospam}@ricozome.net> wrote:
En ayant zyeuté 30 secondes le lien posté par Eric, j'ai vu une usine à
gaz qui monte des ponts virtuels pour faire du transit entre eux. Je n'ai
pas pris plus le temps que ça de regarder ce que ça fait, mais la big
picture, c'est du bridging. Si je me gourre, merci de me faire voir la
lumière ;)
En fait, je pense que ce Linux VRF sert à tout autre chose. Il
doit servir à pouvoir implémenter du routage dans des réseaux
MPLS, où le routage est basé flux plutôt qu'adresse destination.
Il y a d'ailleurs de plus en plus de bruit chez les opérateurs
pour des protocoles de routage plus simple, basé `Flow' qui
permettraient de simplifier aussi certains protocoles de routage.
Il y a des chances que ce Linux VRF a été développé comme solution
`plug-in' alternative à Cisco VRF.
La portée de cette solution et sa généralité *semble* être un peu
le canon à mouches comme tu dit pour le problème énoncé ici.
Si je devais réaliser un tel routage par processus, je pense
que je ferais du MARK dans des namespaces, aujourd'hui. Ou que
je jouerais avec des groupes supplémentaires.
En ayant zyeuté 30 secondes le lien posté par Eric, j'ai vu une usine à gaz qui monte des ponts virtuels pour faire du transit entre eux. Je n'ai pas pris plus le temps que ça de regarder ce que ça fait, mais la big picture, c'est du bridging. Si je me gourre, merci de me faire voir la lumière ;)
En fait, je pense que ce Linux VRF sert à tout autre chose. Il doit servir à pouvoir implémenter du routage dans des réseaux MPLS, où le routage est basé flux plutôt qu'adresse destination. Il y a d'ailleurs de plus en plus de bruit chez les opérateurs pour des protocoles de routage plus simple, basé `Flow' qui permettraient de simplifier aussi certains protocoles de routage. Il y a des chances que ce Linux VRF a été développé comme solution `plug-in' alternative à Cisco VRF. La portée de cette solution et sa généralité *semble* être un peu le canon à mouches comme tu dit pour le problème énoncé ici. Si je devais réaliser un tel routage par processus, je pense que je ferais du MARK dans des namespaces, aujourd'hui. Ou que je jouerais avec des groupes supplémentaires.
