Forum Astuces.divers Spécifier une interface réseau à un processus

Posté par .
1
10
fév.
2012

Bonjour

Cela fait maintenant un certain temps de que je cherche sans résultats.
Peut être quelqu'un ici pourra m'aider.

Suite à un courriel désagréable d'infâmes espions je me suis abonné à un VPN, celui-ci utilise OpenVPN pour la connection.

Globalement j'en suis content mais ce que je voudrais faire, c'est que seulement un de mes logiciel (transmission) utilise l'interface offerte par OpenVNP (qui se nomme tap0) et que les autre logiciels (le navigateurs, les jeux en réseau,...) passent par l'interface eth0 pour gagner en latence en gigue et en vitesse.
On m'a dit que iptables pouvait le faire, mais je n'ai trouvé aucune option qui puisse permettre de filtrer (ou rediriger) le trafic d'un processus, j'ai aussi pensé faire un filtre par rapport aux ports utilisés, mais je ne suis pas sûr que ceux-ci soient les même à chaque démarrages car je n'ai pas vu d'option pour les imposer dans la man page de transmission.

Ce que j'ai trouvé de plus proche était sur :
http://korben.info/logiciel-interface-reseau.html
Mais c'est un tuto pour windaube :-(

Si l'un d'entre vous a une idée ou une solution géniale ce serait super.

Merci d'avance.

(12 commentaires).
  • # openvpn et les passerelles

    Posté par . Évalué à 4.

    deja, regarde si openvpn est configuré pour remplacer toutes tes passerelles par celle du VPN ou pas.

    si c'est le cas, il faut modifier la config openvpn pour qu'elle ne change pas ta passerelle par defaut, mais qu'elle ajoute la route du vpn aux routes existantes.

    ensuite il faudrait simplement preciser à transmission que ca passerelle est celle du VPN.
    comme en torrent on recoit sur une serie de ports "entrants" tu les connais (configurés dans ton logiciel)

    il faut alors declarer dans transmission que ton adresse externe est celle du VPN (plutot que la detection automatique qui va surement trouvé celle de ta connexion adsl)

    et finalement tout le reste doit se faire tout seul.

    tu surferas alors avec ton ADSL (route par defaut), transmission dira aux autres usagers qu'il faut tout envoyer à l'adresse du VPN.

    et quand ca arrivera sur ton PC, ben ca communiquera par le VPN (route retour)

    • [^] # Re: openvpn et les passerelles

      Posté par . Évalué à 0.

      Merci pour cette réponse rapide, je n'avais pas pensé à regarder du côté d'OpenVPN.
      Je vais creuser dans cette voie, et faire un feedback de ce que j'arrive (ou pas) à faire.

  • # Pas avec openVPN, mais l'idée est là...

    Posté par . Évalué à 2. Dernière modification : le 10/02/12 à 22:56

  • # --uid-owner

    Posté par (page perso, jabber id) . Évalué à 2.

    On m'a dit que iptables pouvait le faire, mais je n'ai trouvé aucune option qui puisse permettre de filtrer (ou rediriger) le trafic d'un processus

    Bon ça veut dire que le process doit tourner en tant qu'un certains utilisateur. Il y a certainement moyen de faire ça par process mais a priori ça nécessite d'écrire un module iptables (ou de jouer avec SystemTap ou autre).

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

  • # Iptables + ip rule

    Posté par . Évalué à 5.

    Il te faut une règle iptables qui va matcher tout le trafic de transmission.
    Le plus simple, c'est d'exécuter tes applis qui doivent passer dans le VPN avec un utilisateur spécial, et d'utiliser le module 'owner' d'iptables. Ou d'utiliser un wrapper qui va marquer les paquets. Ou quoi que ce soit d'autre...

    Pour les paquets que tu veut faire passer par ton VPN, marque tes paquets dans une chaîne OUTPUT avec -j MARK --set-mark 0x42, par exemple. Ou avec n'importe quelle marque... Il faut être dans la table mangle pour pouvoir modifier des marques.

    Après, tu peux créer une table de routage spéciale qui va faire passer tout le trafic sur ton VPN, du genre ip route add default via la_bonne_gateway_de_ton_vpn table 42. Puis créer une règle pour dire d'utiliser cette table de routage avec les paquets marqués : ip rule add type unicast fwmark 0x42 table 42. Il faudra peut-être une règle pour le retour aussi, pour dire que tes paquets qui viennent de l'interface de ton vpn utilisaient cette table de routage, sinon le reverse path filtering va jeter tes paquets parce qu'ils sont censé venir de ton interface filaire...

    Fin bref, ça doit être drôle à expérimenter, tout ça. Après il faudra le sécuriser ;) Le noyau linux peut faire des choses bizarre, comme répondre à une requête ARP qui concerne l'IP que tu à sur le vpn, mais depuis ton interface filaire publique. Du coup c'est facile pour un espion avec le même FAI que le tiens de te trouver s'il cherche qui est derrière le VPN...

  • # force_bind

    Posté par . Évalué à 5.

    Le programme force_bind permet de lancer un programme en le limitant à une IP. Pour transmission:

    FORCE_BIND_ADDRESS_V4=IP_DU_VPN LD_PRELOAD=/usr/lib/force_bind.so transmission
    
    
  • # ...

    Posté par . Évalué à 1.

    Merci beaucoup pour vos réponses, ça en fait des pistes à suite et des docs à lire :-D
    Je pense qu'avec ça je vais finir par y arriver.
    Quand ce sera le cas je vous le ferai savoir.

    @+

    • [^] # Re: ...

      Posté par (page perso) . Évalué à 5.

      J'arrive un peu tard... Mais je pense que la solution la plus propre (et peut-être la plus simple) est d'utiliser un namespace réseau différent via unshare et créer des interfaces veth.

      L'archi cherchée est

      shell 1                 shell 2
        |---------|            |-----------------
      eth0 host veth0 ------- veth1 ton process  |
        |---------|            |-----------------
      
      

      A la louche (j'ai pas essayé)

      shell 1:

      # crée 2 interface veth0, veth1 c'est comme s'il y a un cable croisé entre les 2
      $ ip link add name veth0 type veth peer name veth1
      # Tu configures veth0
      
      

      shell2:

      $ su -
      $ unshare -n bash
      # on prend le pid du shell
      $ echo $$
      8705
      
      

      shell 1:
      # Tu migres l'interface veth1 dans le namespace du shell 2
      $ ip link veth1 set veth1 netns PIDSHELL2
      
      

      Shell 2
      # tu configure le réseau
      $ ...
      # tu re-deviens user normal
      $ su - username
      $ tonprogramme
      
      

      Comme d'hab plein de doc dans les manpages et dans les doc du kernel.

      manuel : unshare, clone (pour les détails des namespaces), ip, ip-link
      doc : lxc

      • [^] # Re: ...

        Posté par (page perso) . Évalué à 2.

        J'ai oublié de le mentionner. Par « tu configures veth0 », je veux dire : tu crées un bridge br0 et tu associes veth0 et tap0 à celui-ci :

           shell 1        --------                     shell 2
          |---------|    | Switch |                   |-----------------
        eth0 host  br0 --| virtuel|----  veth0 ---- veth1 ton process  |
          |---------|     --------                    |-----------------
                              |
                            Tap0
                              |
                           VPN net
        
        

        Ensuite, il suffit de mettre comme gateway de shell2 l'ip remote du vpn.

        • [^] # Re: ...

          Posté par . Évalué à 3.

          Pourquoi ne pas mettre simplement le VPN dans le second namespace ? comme ça y a une configuration classique sans VPN d'un coté et une configuration classique avec VPN de l'autre. Ça serait plus simple à gérer je pense.

          • [^] # Re: ...

            Posté par (page perso) . Évalué à 2.

            Effectivement, c'est plus simple.

            Je voulais également donner la possibilité d'accès au réseau local pour, par exemple, des disques partagés.

        • [^] # Re: ...

          Posté par . Évalué à 3.

          il suffit de mettre comme gateway de shell2 l'ip remote du vpn.

          Foutaise ! ^^

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.