Bonjour,
est-il possible de forcer un programme à utiliser une interface réseau spécifique ?
Sans utiliser iptables. Un programme qui - dans le meilleurs des monde - permetterait de lancer le soft en question en le forçant à utiliser l'interface. Du style :
le_programme nom_de_la_carte mon_programme_a_lancer
# ?
Posté par defmonkey . Évalué à 2.
À ton avis, les tables de routage du kernel servent à quoi ?
[^] # Re: ?
Posté par 28pYPcsK . Évalué à -4.
Sur les tables de routage du kernel, je ne sais pas ce que c'est et je vais regarder. Merci.
Comme il y avait un intérèt, regarder un truc que je ne connaissais pas.
[^] # Re: ?
Posté par Grunt . Évalué à 4.
Waw.
Ami du vendredi, bonsoir.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ?
Posté par 28pYPcsK . Évalué à -5.
[^] # Re: ?
Posté par Obsidian . Évalué à 10.
D'abord, parce que l'entraide va dans les deux sens, et que celle qu'on peut t'apporter doit pouvoir profiter aux autres aussi. Pas la peine, donc, de demander de l'aide en disant « ne cherchez pas à comprendre pourquoi, c'est confidentiel. ».
Ensuite, parce que ce genre de problématique est fréquente et que si tu ne connais pas la solution, c'est que ne connais pas assez bien le système. Ce n'est pas un tort en soi, mais il y a neuf chances sur dix pour ce que tu cherches à faire soit la mauvaise solution à ton problème.
Enfin, et surtout, parce qu'il y a bel et bien moyen d'exploiter directement une carte réseau définie, mais probablement pas de la manière que tu crois. Et d'ailleurs, même en temps normal, un programme « n'utilise » jamais de carte réseau. Il envoie des données qui sont ensuite routées là où il faut par les différents équipements qu'il rencontre, comme une capsule dans un pneumatique. Et le noyau de ta machine n'est que le premier d'entre eux.
Vide ton sac, maintenant.
# une route statique ?
Posté par Xavier Maillard . Évalué à 1.
je ne sais pas si ça répond complètement à ton problème mais en positionnant des routes statiques, tu peux forcer un programme à utiliser (indirectement) une interface réseau bien spécifique (je trouve ça laid ce pendant).
# Utiliser xinetd ?
Posté par Olivier (site web personnel) . Évalué à 4.
xinetd, via le paramètre "bind", tu peux faire que xinetd n'écoute que les communications arrivant sur une interface réseau bien spécifique.
Lorsque des paquets répondes à tes critère, xinetd lance alors ton programme en lui passant la connexion.
Tu peux regarder ce que j'avais écrit ici : http://olivieraj.free.fr/fr/linux/information/firewall/fw-02(...)
Par contre, il faut que ton programme soit écrit de tel manière à ce qu'il puisse dialoguer avec xinetd.
[^] # Re: Utiliser xinetd ?
Posté par KiKouN . Évalué à 1.
[^] # Re: Utiliser xinetd ?
Posté par benoar . Évalué à 2.
[^] # Re: Utiliser xinetd ?
Posté par Pierre Bourdon . Évalué à 2.
Si l'IP 1.2.3.4 contacte 5.6.7.8 via eth1, mais que 5.6.7.8 a une route qui dit « 1.2.3.4 va sur eth0 », les données de 1.2.3.4 vers 5.6.7.8 sont reçues sur eth1 mais la réponse de 5.6.7.8 à 1.2.3.4 passera par eth0.
# merci
Posté par 28pYPcsK . Évalué à -2.
ça me donne une bonne base pour continuer ma petite bidouille.
[^] # Re: merci
Posté par 28pYPcsK . Évalué à 1.
J'ai un tunnel vpn et je veux être sur que le traffic passe par le tunnel vpn et que le traffic est bloqué lorsque le vpn est deconnecté.
J'ai solutionné le problème avec iptables, en forcant le traffic à passer par l'interface tap0. Ca marche bien.
Mais je me pose du coup cette question. Est-ce que je peux lancer un programme, par exemple firefox, en l'obligeant a passer par tap0, quoiqu'il arrive, même si iptable est coupé ?
Et du coup est-ce que je peux forcer firefox à passer uniquement par eth0, wlan0, tap0 au choix ? Un peu à la manière de torsocks qui tente de faire passer le traffic par tor. A la manière car le lancement est très souple (torsocks nom_du_soft).
Pas de but précis, c'est juste pour m'occuper. Et pas d'interet particulier à faire ça, dans la pratique, que firefox passe par eth0 ou wlan0 cela n'a pas d'importance. Mais j'aimerais savoir si il est possible de le faire et si oui comment. J'insiste sur le fait qu'il n'y a aucune application concrète.
[^] # Re: merci
Posté par BFG . Évalué à 1.
Cela pourrait vous intéresser, spécifier une adresse source à utiliser pour les connexions sortantes d'un programme, de sorte qu'une seule interface réseau sera utilisée : [http://wari.mckay.com/~rm/bindhack.c.txt]. Le commentaire du début du fichier explique brièvement comment s'en servir.
De même que l'on peut faire qu'un serveur n'écoute que sur 127.0.0.1, de sorte qu'il ne pourra pas accepter les connexions venant de eth0, on peut aussi le faire pour les connexions sortantes. Cela se fait par l'appel système bind(2).
[^] # Re: merci
Posté par Obsidian . Évalué à 2.
Déjà, iptables n'est pas « coupé ». Netfilter fait partie intégrante du noyau et, donc, de la gestion du trafic réseau en général. « iptables » est le logiciel qui te permet de paramétrer le filtre. Tu n'as pas besoin de lancer un processus qui surveillerait le trafic en temps réel et se chargerait d'intercepter les paquets au vol. Et heureusement !
Ensuite, si tu travailles en IP et que tu as un tunnel VPN, alors celui-ci a forcément un sous-réseau dédié et sur ce sous-réseau, il doit y avoir une passerelle vers Internet qui, elle, se trouve de l'autre côté du tunnel.
Si tu veux être sûr que ton trafic vers Internet passe par ton VPN, il faut définir ta passerelle par défaut comme étant celle-ci et supprimer les autres si elles existent et référencent un réseau qui n'est pas celui du VPN.
Si tu veux que seul Firefox ou un logiciel de ton choix soit soumis à ces règles, effectivement tu utilises iptables. Celui-ci propose entre autres une option "--gid-owner" qui te permettra de faire une exception pour les paquets dont le processus initiateur appartient à un groupe donné. Tu peux t'en servir pour autoriser ces privilégiés à utiliser certaines voies.
Mais dans tous les cas, il faut d'abord raisonner en terme de routage avant de considérer les interfaces par lesquelles ces routes transitent.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.