Gérer les flux avec OpenVPN

ztheoz · 27-06-2017 22:24:15

Bonjour,
j'ai installé Deluge et OpenVPN sur mon serveur. La configuration de VPN étant effectué, j'ai cherché à faire en sorte qu'il n'y ai uniquement le flux de Deluge qui passe par le tunnel VPN.

La première étape (très facile) était de faire en sorte qu' OpenVPN ne force aucun flux à passer par le tunnel. J'ai juste eu à ajouter "route-nopull" à la fin du fichier .conf, et le tour est joué.

Maintenant, je veux forcer le flux entrant et sortant par le VPN, mais je ne sais vraiment pas comment faire, tout ce que j'ai vu me parait très compliqué.

Le tunnel VPN est assigné à l'interface tun0

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          inet addr:10.61.10.6  P-t-P:10.61.10.5  Mask:255.255.255.255

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Deluge est lancé avec l'utlilisateur "deluge", je ne sais pas si l'ont peut faire passer tout le trafic de cet utilisateur par tun0.

Je précise que je n'ai aucune connaissance en la matière.

Merci pour votre (précieuse) aide.

Dernière modification par ztheoz (27-06-2017 22:26:19)

raleur · 28-06-2017 11:31:22

Pour le routage sortant, il faut faire du routage avancé. Cf. le Linux Advanced Routing and Traffic Control (LARTC) HOWTO.

Une possibilité consiste à configurer l'application pour utiliser l'adresse source de l'interface VPN, 10.61.10.6. Ensuite il suffit de router les paquets émis avec cette adresse source via le tunnel.

ip route add default dev tun0 table 6

ip rule add from 10.61.10.6 table 6

Ou bien, si le programme s'exécuter avec un UID spécifique, marquer ses paquets avec iptables, rerouter les paquets marqués via tun0 et les masquerader pour qu'ils aient la bonne adresse source.

ip route add default dev tun0 table 6

ip rule add fwmark 6 table 6

iptables -t mangle -A OUTPUT -m owner --uid-owner deluge -j MARK --set-mark 6

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Dans les deux cas, s'assurer que le reverse-path filtering n'est pas en mode strict sur tun0 (rp_filter != 1).

Dernière modification par raleur (28-06-2017 13:33:50)

ztheoz · 28-06-2017 13:08:31

Merci pour ton aide,

J'ai appliqué la première méthode que tu m'as indiqué, mais j'ai 2 questions :

-Faut-il que je lance les commandes à chaque lancement du serveur, ou sont-elles permanentes?
-Lorsque je lance le VPN, "inet addr" change : toujours sous la forme 10.**.10.6 apparemment. Y a-t-il un moyen de faire en sorte qu'OpenVPN fixe cette
adresse? Car les 2 méthodes sont sensibles à cette adresse.

Merci

raleur · 28-06-2017 13:41:24

Aucune de ces commandes n'est permanente après un redémarrage.
La route mentionnant l'interface tun0 est automatiquement supprimée quand cette interface est désactivée. Donc il faut la recréer quand le VPN monte. Cela doit être automatisable avec un script appelé par openvpn lors de cette phase.
Si l'adresse IP de tun0 change, il reste possible de la même façon de créer la règle lorsque le VPN monte (et l'adresse IP connue), et de la supprimer quand le VPN tombe.
Comme je n'utilise pas openvpn souvent, je ne me souviens pas comment on peut fixer l'adresse, mais ça doit se configurer côté serveur.
La seconde méthode ne dépend pas de l'adresse de tun0. C'était une erreur de copier-coller que je viens de corriger.

Dernière modification par raleur (28-06-2017 13:42:55)

ztheoz · 28-06-2017 16:21:51

Bon alors j'ai créé un script qui se lance à chaque connexion du VPN, et qui change les paramètres en fonction de l'IP :

#!/bin/sh

IP=`/sbin/ifconfig tun0 | grep 'inet addr:' | cut -d: -f2 | awk '{print $1}'`

sudo -u deluge deluge-console config -s listen_interface $IP

sudo ip route flush 6

sudo ip route add default dev tun0 table 6

ip rule add from $IP table 6

mais dès que les deux dernières commandes sont lancées, je ne peux plus me connecter à l'interface de déluge, même avec l'adresse locale.
J'en déduis donc que la solution est "trop puissantes", il faudrait pouvoir laisser passer certaines données pour que je puisse accéder à l'interface.

Je ne sais vraiment pas si c'est possible, car l'interface et le "cœur" de l'application sont lancés par le même user.

ztheoz · 29-06-2017 11:30:17

J'ai peut-être un piste :
Le daemon de Deluge tourne sur un port spécifique : le 8112, on purrait donc faire une exception sur ce dernier, non?

raleur · 29-06-2017 12:24:37

L'option listen_interface affecte-t-elle seulement l'adresse d'écoute (comme le nom le laisse entendre) des connexions entrantes ou aussi l'adresse source des connexions sortantes ?

ztheoz a écrit :

sudo ip route flush 6

Il ne manque pas "table" dans cette commande ? De toute façon elle ne devrait pas être nécessaire car les routes liées à tun0 sont effacées quand le tunnel est arrêté et l'interface est désactivée.

ztheoz a écrit :

je ne peux plus me connecter à l'interface de déluge, même avec l'adresse locale.

C'est-à-dire ? qu'appelles-tu te connecter à l'interface de déluge, et l'adresse locale ?

ztheoz a écrit :

Le daemon de Deluge tourne sur un port spécifique : le 8112

Même question que pour l'adresse : port d'écoute seulement ou aussi port source des connexions sortantes ?

ztheoz · 29-06-2017 13:11:20

L'option listen_interface affecte-t-elle seulement l'adresse d'écoute (comme le nom le laisse entendre) des connexions entrantes ou aussi l'adresse source des connexions sortantes ?

J'ai lu sur un forum que cette option est pour les torrents, je n'en sais pas plus malheureusement.

Il ne manque pas "table" dans cette commande ? De toute façon elle ne devrait pas être nécessaire car les routes liées à tun0 sont effacées quand le tunnel est arrêté et l'interface est désactivée.

Non, la commande marche bien sans le "table". Je l'ai mise ici, au cas où, même si elle ne sert à rien, on ne sais jamais.

C'est-à-dire ? qu'appelles-tu te connecter à l'interface de déluge, et l'adresse locale ?

L'interface de Déluge est l'endroit où l'on peut ajouter ou gérer ses torrents. C'est pourquoi il est essentiel que je puisse y accéder. L'adresse locale est l'adresse à laquelle je peux accéder à cette interface avec l'adresse "192.168.1.**:58846". Sinon je peux y accéder par "<NOM DE DOMAINE>:8812" quand je suis à l’extérieur du réseau où est mon serveur (car il est hébergé chez moi).

Même question que pour l'adresse : port d'écoute seulement ou aussi port source des connexions sortantes ?

Non, je me suis trompé : Cette adresse est utilisé par le serveur web de Deluge, et le port 58846 pour se connecter uniquement avec le client Windows de Deluge. Lors de l'activation du VPN, et donc du script, les deux ports sont injoignables tant que le VPN est en route.

Le port 8812 est seulement pour le service deluge-web, donc il sert uniquement à l'interface web, je peux lancer Deluge sans ce service. Malgré cela, le service est aussi exécuté par l'utilisateur deluge, donc pris en compte lors routage vers tun0.

Le port 58846 est utilisé uniquement pour le daemon, donc pour l'interface :

Pour les flux torrent, ce sont ces ports qui semblent êtres utilisés :

(Je suis désolé, les images sont petites, mais si on clique dessus c'est bon).

J’espère que ces précisions on pu d'aider.

Dernière modification par ztheoz (29-06-2017 13:14:50)

raleur · 29-06-2017 14:43:46

ztheoz a écrit :

L'interface de Déluge est l'endroit où l'on peut ajouter ou gérer ses torrents. C'est pourquoi il est essentiel que je puisse y accéder. L'adresse locale est l'adresse à laquelle je peux accéder à cette interface avec l'adresse "192.168.1.**:58846".

Ce n'est pas l'adresse de tun0, donc normalement le routage des paquets avec cette adresse ne devrait pas être affecté par la règle de routage de la première méthode.
Tu y accèdes depuis la machine elle-même ou depuis une autre machine dans le réseau local ?
Dans le second cas, il peut être utile d'ajouter une route pour la plage d'adresses du réseau local dans la table 6, du style :

ip route add 192.168.1.0/24 dev eth0 table 6

Si tu veux baser le routage sur un ou plusieurs ports source, il faut utiliser la seconde méthode avec "--sport $PORT:$PORT2" (intervalle) ou "-m multiport --sports $PORT1,$PORT2..." (liste)

Dans la capture d'écran sur les ports entrants et sortants, les plages sont grisées, sont-elles actives ?
Il faut absolument connaître les caractéristiques des paquets à router par le tunnel. S'il le faut, fais des captures de trafic.

Dernière modification par raleur (29-06-2017 14:46:46)

ztheoz · 29-06-2017 15:09:59

Dans le second cas, il peut être utile d'ajouter une route pour la plage d'adresses du réseau local dans la table 6, du style :
ip route add 192.168.1.0/24 dev eth0 table 6

J'ai ajouté cette commande, et en effet je peux y accéder depuis mon réseau local.

Maintenant plus qu'une étape avant de terminer, est-il possible d'ajouter une règle de ce type pour que je puisse y accéder depuis un autre réseau que le mien (avec mon nom de domaine)?

Dernière modification par ztheoz (29-06-2017 15:11:24)

raleur · 29-06-2017 16:38:09

Je suis surpris. Normalement avec cette règle,

ip rule add from $IP table 6

Seuls les paquets sortants dont l'adresse source est $IP devraient être affectés. Or quand tu te connectes depuis un autre poste du réseau local, tu utilises l'adresse LAN de la machine, n'est-ce pas ?
En tout cas cette route pour le réseau local n'est pas automatiquement supprimée, donc il faut soit la flusher comme tu le fais soit ne la créer qu'une seule fois.

ztheoz a écrit :

est-il possible d'ajouter une règle de ce type pour que je puisse y accéder depuis un autre réseau que le mien (avec mon nom de domaine)?

Via quel chemin réseau ? Le VPN ou l'accès internet normal ?
Par le VPN, il n'y a rien de spécial à faire.
Par l'accès internet normal, il faut créer une route hors VPN pour l'adresse IP du client. Une route ne contient qu'une adresse IP, pas un nom de domaine.

PS :
L'interface tunnel a une adresse IP privée, donc le serveur au bout du tunnel doit rediriger les connexions entrantes ?
Il ne devrait pas y avoir de sudo dans ton script, ou alors toutes les commandes devraient l'avoir.
La règle de routage doit être explicitement supprimée (ip rule del) à la fin de la connexion VPN, sinon les règles vont s'accumuler.

Dernière modification par raleur (29-06-2017 16:42:47)

ztheoz · 29-06-2017 16:52:05

La règle de routage doit être explicitement supprimée (ip rule del) à la fin de la connexion VPN, sinon les règles vont s'accumuler

Ok merci, je vais ajouter ça dan down.sh.

Par l'accès internet normal, il faut créer une route hors VPN pour l'adresse IP du client

Oui, je voudrais faire ça.
Peux-tu m'indiquer comment faire, car là à part recopier le commandes, je ne sais pas faire grand chose dans ce sujet

Merci !

raleur · 29-06-2017 17:18:15

ip route add $DEST_ADDR via $GW_ADDR table 6

ou $DEST_ADDR est l'adresse de destination (du client extérieur) et $GW_ADDR est l'adresse interne du routeur (passerelle) de l'accès internet du réseau local.

ztheoz · 29-06-2017 18:52:00

$DEST_ADDR est l'adresse de destination (du client extérieur)

J'ai n'ai pas bien compris : c'est l'adresse IP de l'appareil à partir duquel on se connecte ou mon nom de domaine?

raleur · 29-06-2017 19:00:46

L'adresse IP (vue de la machine qui reçoit la connexion). La commande ip ne comprend pas les noms de domaine. De toute façon même si elle savait résoudre un nom de domaine en adresse IP, ce serait au moment de la création de la route car une route ne peut pas contenir de nom de domaine.

Dernière modification par raleur (29-06-2017 19:01:25)

ztheoz · 29-06-2017 19:40:34

L'adresse IP (vue de la machine qui reçoit la connexion).

Bon ça ne me va pas, j'utilise plusieurs autres réseaux, mais tous avec des IP dynamiques, je me vois mal modifier ma conf à chaque changement d'IP sur me boxes.

Mais je pense que je pourrais (dis-moi si je me trompe) faire une redirection de ports au niveau de Debian : par exemple Debian reçoit la connexion sur le port 58847 et fait une redirection sur 127.0.0.1:58846

iptables -t nat -A PREROUTING -d 192.0.2.33 -p tcp --dport 1234 -j DNAT --to 127.0.0.1:58846

iptables -t nat -A POSTROUTING -d 127.0.0.1 -p tcp --dport 58846 -j SNAT --to 192.0.2.33

d'après https://www.debian-fr.org/t/rediriger-u … port/59326.

Le problème est que je ne sais pas quoi mettre au niveau de l'IP entrante (je peux mettre ça : xxx.xxx.xxx.xxx ?, ou alors l'IP externe de ma box (donc l'IP externe de mon serveur)?)

Dernière modification par ztheoz (30-06-2017 11:16:30)

Debian-facile

#1 27-06-2017 22:24:15

Gérer les flux avec OpenVPN

#2 28-06-2017 11:31:22

Re : Gérer les flux avec OpenVPN

#3 28-06-2017 13:08:31

Re : Gérer les flux avec OpenVPN

#4 28-06-2017 13:41:24

Re : Gérer les flux avec OpenVPN

#5 28-06-2017 16:21:51

Re : Gérer les flux avec OpenVPN

#6 29-06-2017 11:30:17

Re : Gérer les flux avec OpenVPN

#7 29-06-2017 12:24:37

Re : Gérer les flux avec OpenVPN

#8 29-06-2017 13:11:20

Re : Gérer les flux avec OpenVPN

#9 29-06-2017 14:43:46

Re : Gérer les flux avec OpenVPN

#10 29-06-2017 15:09:59

Re : Gérer les flux avec OpenVPN

#11 29-06-2017 16:38:09

Re : Gérer les flux avec OpenVPN

#12 29-06-2017 16:52:05

Re : Gérer les flux avec OpenVPN

#13 29-06-2017 17:18:15

Re : Gérer les flux avec OpenVPN

#14 29-06-2017 18:52:00

Re : Gérer les flux avec OpenVPN

#15 29-06-2017 19:00:46

Re : Gérer les flux avec OpenVPN

#16 29-06-2017 19:40:34

Re : Gérer les flux avec OpenVPN

Pied de page des forums