Suite à mon journal précédent et aux commentaires très constructifs que l'on y trouve (un grand merci aux auteurs). J'ai entrepris d'analyser et parfois tester les différentes solutions proposées.
Les solutions :
- Full virtualisation (la mienne, donc testée et fonctionnelle).
- Virtualisation par cloisonnement LXC (testée et fonctionnelle)
- Namespace réseau (testée, fonctionnelle et adoptée)
- Tag du trafic par utilisateur (se base sur des règles Iptables, non testée mais potentiellement très puissante)
- Utiliser Shorewall (se base sur des règles Iptables, non testée)
- La commande méconnue unshare(qui ressemble beaucoup à la solution du namespace détaillée plus bas, non testée)
- Un patch de transmission pour choisir la carte réseau (ne correspond pas entièrement car je veux pouvoir lancer d'autres programme sur le tunnel VPN).
Détails :
En ce qui concerne la solution avec LXC ce post donne déjà presque toute la solution (même si j'ai eu un peu peur de tomber sur un anneau), la seule chose que j'ai eu à faire c'est de modifier une ligne du fichier /boot/grub/grub.cfg :
linux /vmlinuz-3.14-1-amd64 root=UUID=eb94f23a-7675-4d78-880c-521d776e68ae ro quiet cgroup_enable=memory
pour que LXC fonctionne.
Sinon une fois OpenVPN installé tout fonctionne bien, la configuration ressemble à celle qu'il faut faire dans une VM de type KVM.
Pour les namespace réseau j'ai principalement suivi ce lien qui m'avait été donné dans un des commentaires, donc une fois fait on arrive à une architecture comme ça :
Du coup je profite que ce soit frais pour détailler un peu la procédure (on ne sait jamais cela peut aider des gens).
Prérequis
Avoir un bridge br0 avec l'ip 10.0.0.1/24
Avoir une règle de NAT entre br0 et eth0
pour cela voir le journal précédent
Être root
Création du Namespace réseau :
ip netns add vpn_ns
Création des interfaces virtuelles :
ip link add veth_vpn type veth peer name veth0
Cette commande crée 2 interfaces virtuelles connectées "physiquement" c'est à dire comme si il y avait un câble entre les deux, ceci permettra de faire la liaison entre l'intérieur et l'extérieur du namespace réseau.
Paramétrage des interfaces virtuelles :
ifconfig veth0 10.0.0.253/24 up
On active veth0 avec une ip dans le même réseau que le bridge
brctl addif br0 veth0
On définit veth0 comme une interface du bridge
ip link set veth_vpn netns vpn_ns
On insère veth_vpn dans le namespace réseau
A partir de maintenant pour agir sur le namespace réseau il faut le dire explicitement par la commande ip netns exec vpn_ns c'est pourquoi je trouve pratique de faire un alias : alias vpnc='ip netns exec vpn_ns' donc toute commande préfixée par vpnc (pour VPN Command, oui je suis un original) sera exécutée dans le namespace.
vpnc ifconfig veth_vpn 10.0.0.252/24 up
On définie veth_vpn dans le même réseau que le bridge, à ce stade on doit pourvoit "pinger" l'ip du bridge (10.0.0.1)
vpnc route add default gw 10.0.0.1
On définie l'IP du bridge comme gateway
Pour finir
vpnc openvpn --config /etc/openvpn/<ma-config>.conf
On lance Openvpn qui va faire toute sa configuration dans le namespace
vpnc sudo -u <user> transmission-gtk &
On lance transmission avec l'utilisateur user
vpnc sudo -u <user> <votre_navigateur> &
On lance votre_navigateur sur le tunnel VPN sudo -u <user> <votre_navigateur> &
On lance une autre instance de votre_navigateur
On ouvre l'url http://www.whatismyip.com/ sur les deux navigateurs, cette page doit renvoyer 2 ip différentes, l'une doit donner l'adresse de votre serveur VPN, et l'autre celle attribuée par votre FAI.
\o/
# tsocks ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
tsocks (+ ssh -D au besoin) ou toute autre solution qui détourne les flux réseau vers un proxy donné via le LD_PRELOAD ?
[^] # Re: tsocks ?
Posté par reynum (site web personnel) . Évalué à 1.
Je ne pense pas que cela ait un rapport avec mon cas (faire passer les flux réseaux d'une application particulière par un L2 VPN)
Tsocks permet aux flux réseaux de certaines applications de passer un par proxy alors que nativement elle ne le peuvent pas.
De plus dans mon cas je ne suis pas propriétaire du serveur de VPN c'est un service que je loue donc pas de SSH disponible.
kentoc'h mervel eget bezan saotred
[^] # Re: tsocks ?
Posté par reynum (site web personnel) . Évalué à 1.
Du coup pourrais tu changer l'URL de l'image dans le journal par celle de l'image ci-dessous STP ?
kentoc'h mervel eget bezan saotred
# Image
Posté par reynum (site web personnel) . Évalué à 0.
Désolé mais le site refuse d'afficher l'image chez moi du coup le l'ai mise ailleurs.
kentoc'h mervel eget bezan saotred
[^] # Re: Image
Posté par steph1978 . Évalué à 2.
si https, il faut charger explicitement l'url d'une image "https://img.linuxfr.org/..." et accepter le certificat.
[^] # Re: Image
Posté par reynum (site web personnel) . Évalué à 1.
Le problème est résolu je pense que Benoît Sibaud a modifié l'url de l'image comme je lui ai demandé dans le topic "tsocks ?".
kentoc'h mervel eget bezan saotred
[^] # Re: Image
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Oui, j'ai modifié l'URL comme demandé.
[^] # Re: Image
Posté par reynum (site web personnel) . Évalué à 1.
c'est bien ce que je pensais, merci !
kentoc'h mervel eget bezan saotred
# Un petit problème
Posté par reynum (site web personnel) . Évalué à 1.
C'est bien beau de dire que tout est bien qui fini bien la vie est belle et tout, mais présentement je viens de tomber sur une petite coquille.
Comme je suis sur mon pc portable j'utilise dnsmasq comme miroir DNS, c'est plus facile quand on bouge car les machines virtuelles qui tournent ont toutes l'ip du bridge comme gateway et comme serveur dns, sur l'hôte dnsmasq met à disposition le service de DNS sur la loopback (127.0.0.1) et modifie donc le fichier resolv.conf ; d'un autre côté il écrit les ip reçues par le DHCP dans le fichier /var/run/dnsmasq/resolv.conf.
Mais quand on est dans le namespace réseau (vpn_ns dans mon cas) on a plus accès à la loopback du namespace root, donc il n'arrive pas à se connecter au service de DNS et donc de résoudre résoudre les noms (ce qui est un peu gênant).
J'ai donc remis les @DNS en dur dans /etc/resolv.conf et stoppé dnsmasq en attendant de trouver une solution.
kentoc'h mervel eget bezan saotred
[^] # Re: Un petit problème
Posté par Anonyme . Évalué à 1.
Et en ajoutant une route vers 127.0.0.0/8 via lo dans le netns ?
Je connais pas les netns, mais avec les VRF Cisco, c'est comme ça que ça se ferait.
[^] # Re: Un petit problème
Posté par reynum (site web personnel) . Évalué à 1.
Ça fonctionne pas.
En fait le namespace isole complètement ce qu'il y a dedans donc impossible de router quelque chose.
C'est pour cette raison que l'on crée 2 interfaces virtuelles reliées par un "câble virtuel" l'une étant dans le NS l'autre à l'extérieur.
Reprenant cette idée je me suis dit que je devait créer une interface virtuelle connectée avec la lo et la mettre dans le ns (comme ça je pourrais créer une route) mais je n'arrive pas à créer un tel lien.
kentoc'h mervel eget bezan saotred
[^] # Re: Un petit problème
Posté par reynum (site web personnel) . Évalué à 1.
La solution ne me satisfait pas encore entièrement mais elle est déjà beaucoup moins contraignante.
Il faut que dnsmasq soit paramétré pour écouter les requêtes DNS sur le bridge br0.
Comme l'ip de br0 est atteignable à partir du namespace si on ajoute
nameserver 10.0.0.1(qui est l'ip du bridge) au fichier /etc/resolv.conf (en dessous denameserver 127.0.0.1) les requêtes DNS lancées dans le namespace trouveront le serveur miroir fait par dnsmasq.Mais cette solution est simple mais n'est pas encore complètement dynamique.
kentoc'h mervel eget bezan saotred
[^] # Re: Un petit problème
Posté par reynum (site web personnel) . Évalué à 1.
La bonne solution pour avoir un DNS spécifique au namespace est de créer un fichier
/etc/netns/NAMESPACE_NAME/resolv.confEt bien entendu de mettre dans ce fichier l'adresse du serveur DNS voulue \o/
kentoc'h mervel eget bezan saotred
[^] # Re: Un petit problème
Posté par reynum (site web personnel) . Évalué à 2.
Autre problème relatif à cette solution.
Quand on fait ouvrir un torrent avec transmission automatiquement à partir d'un navigateur, le système ne va pas prendre l'instance de transmission qui est déjà lancée dans le namespace mais en ouvrir une autre qui elle ne sera pas dans le namespace.
De même quand on sort de mise en veille, openvpn va se relancer hors du namespace, il faut l'arrêter et le releancer dans le NS à la main ce qui n'est pas user friendly.
kentoc'h mervel eget bezan saotred
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.