Problème accès à RuTorrent en connexion VPN

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Problème accès à RuTorrent en connexion VPN

NIPSEN

Bonjour à tous,

Je suis un peu, beaucoup, au bout du rouleau. Depuis plusieurs jours je cherche une solution à mon problème... Je vais essayer de vous expliquer.

J'ai un Raspeberry qui tourne sous Arch Linux, j'y ai installé nginx, PHP, rtorrent, rutorrent et openvpn.
Tout fonctionne normalement dans que le client openvpn n'est pas connecté, j'ai bien accès à rutorrent depuis une IP extérieur.

Cependant dès que je connecte openvpn au serveur distant, je n'arrive plus à accéder à rutorrent depuis l'extérieur en interrogeant l'ip réel de ma connexion internet.

En gros je voudrais pouvoir passer "à travers" la connexion VPN.

La seul solution que j'ai trouvé est de faire :

echo 200 main >> /etc/iproute2/rt_tables
echo 201 NONVPN >> /etc/iproute2/rt_tables

puis

ip route add default via 192.168.1.1 table main
ip route add default via 192.168.1.1 table NONVPN

ip rule add from 10.13.0.0/24 table main
ip rule add from 192.168.1.0/24 table NONVPN

Alors j'arrive bien à accéder à mon serveur web depuis une ip extérieur, mais je perd la connexion SSH en local...

Si vous avez une idée...

MERCI !

xavier

Salut

si jai bien compris il faut rediriger ton port serveur sur ton rpi en passant par le vpn
en gros(a faire sur le srv vpn)

/sbin/iptables -A FORWARD -i eth0 -p tcp --dport 81 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 81 -j DNAT --to 10.8.0.2:80

si ip client vpn et 10.8.0.2
donc adresse sera ipserveurvpn:81

NIPSEN

Je n'ai pas accès à la configuration du serveur :-/
Et l'iptables du raspeberry est full accept :

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

xavier

normalement si tu actives le vpn tu devrais pas perdre la connection en local.
oui oui en full accept pour le client.
donc après je sais pas, faudrait savoir comment le vpn est configuré (client/serveur) les routes , la passerelle etc etc

ps: si tu arrives pas, demain ou un autre jour je te crée un certificat avec mon serveur et on fera les tests

NIPSEN

Lorsque je connecte le raspberry au serveur VPN, je ne perd pas la connexion locale, je perd l'accés à rutorrent depuis une ip extérieur, mon smartphone par exemple.

La config du client VPN :

client
dev tun1
proto tcp
remote 212.129.33.61 443
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass auth.txt
comp-lzo
verb 3
cipher AES-128-CBC
fast-io
pull
route-delay 2
redirect-gateway

La config serveur je ne la connais pas.

Le routage sans VPN:

[rtorrent@alarmpi ~]$ ip route list
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.18 metric 1024
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.18
192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.18 metric 1024

Le routage avec VPN:

[rtorrent@alarmpi ~]$ ip route list
0.0.0.0/1 via 10.13.0.241 dev tun1
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.18 metric 1024
10.13.0.1 via 10.13.0.241 dev tun1
10.13.0.241 dev tun1 proto kernel scope link src 10.13.0.242
128.0.0.0/1 via 10.13.0.241 dev tun1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.18
192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.18 metric 1024
212.129.33.61 via 192.168.1.1 dev eth0

xavier

Salut.
On dirait que t'as une configuration assez standard..
Ta box (192.168.1.1) redirigé ton port 80 sur ton rpi? Même si vpn est en route tu devrais arriver à te connecter à ton rpi depuis extérieur (ip de ta box)

NIPSEN

xavier Oui le port 80 est ouvert sur ma box, et ça fonctionne normalement jusqu'à la connexion au VPN.

J'ai envie de pleurer 😢

xavier

On va faire test taleur..je te cree un certificat client .tu me diras si il y du mieux..Envoi moi un mail (sur mon profil tu trouveras mon mail)

xavier

@NIPSEN regarde dans spam

NIPSEN

xavier Je viens de me connecter à ton vpn, le résultat est le même.

xavier

lol juste a l'intant je tai envoyer un mail

NIPSEN

xavier ah, je ne l'ai pas reçu, j'ai exactement le même résultat avec ton fichier de conf 😢

NIPSEN

J'ai fait un TCPDUMP, le raspberry répond bien aux requêtes d'un pc en local pour afficher le site web :

22:46:25.190279 IP 192.168.1.18.80 > 192.168.1.11.57172: Flags [P.], seq 10733:11005, ack 27546, win 1699, length 272: HTTP: HTTP/1.1 200 OK
22:46:25.191361 IP 192.168.1.11.57172 > 192.168.1.18.80: Flags [.], ack 11005, win 16425, length 0

Mais rien lorsque la demande vient de l'extérieur, pas de réponse :

22:49:59.552523 IP 81.xx.xx.xx.64405 > 192.168.1.18.80: Flags [S], seq 694085907, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
22:49:59.553381 IP 81.xx.xx.xx.64406 > 192.168.1.18.80: Flags [S], seq 1937738857, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
22:49:59.557862 IP 81.xx.xx.xx.64407 > 192.168.1.18.80: Flags [S], seq 1960188199, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
22:49:59.558911 IP 81.xx.xx.xx.64408 > 192.168.1.18.80: Flags [S], seq 795987901, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

Pourtant la requête arrive bien.

Malakai

La je pense qu'il s’agit d'un probleme de routage :

[rtorrent@alarmpi ~]$ ip route list
0.0.0.0/1 via 10.13.0.241 dev tun1
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.18 metric 1024
10.13.0.1 via 10.13.0.241 dev tun1
10.13.0.241 dev tun1 proto kernel scope link src 10.13.0.242
128.0.0.0/1 via 10.13.0.241 dev tun1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.18
192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.18 metric 1024
212.129.33.61 via 192.168.1.1 dev eth0

Lorsque tu te connecte depuis ton reseau local au serveur web du raspberry, il utilise la regle lui disant de repondre au travers de eth0 (donc reseau local), par contre lorsque tu te connecte depuis l'ip publique (81.xx.xx.xx), le raspberry utilise la premiere regle (0.0.0.0/1 via 10.13.0.241 dev tun1) pour repondre car pour lui il doit utiliser l'interface tun1 pour toutes les autres adresses (0.0.0.0/1), ce qui fait qu'il te repond au travers de tun1.
Et la il y a un probleme, parce que tu fais ta demande au travers de eth0 et il te repond au travers de tun1, ce qui est pas possible (il y a une regle qui fait que ce genre de paquets sont bloques, car pris pour du flood).
Ce que tu peux faire dans un premier temps pour essayer de valider ma supposition et de rajouter une route lorsque le vpn est up disant que pour repondre a l'adresse 81.xx.xx.xx il faut utiliser l'interface eth0. Si ca marche et que ton ip 81.xx.xx.xx est statique, tu gardes cette regle et le tour et joue.

NIPSEN

Malakai salut Malakai, merci pour ton analyse, je pense que tu a bien identifié la source de mon problème, cependant je souhaiterais que toutes les ip extérieur puisse accéder à mon serveur. Dans un premier temps je peux toujours essayer avec 1 ip comme tu le suggères, je vais chercher la commande, à moins que tu ais déjà une idée?

Malakai

Ca fait un moment que je n'ai pas eu a faire de routage mais je pense que ca devrait etre ca :

ip route add 81.xx.xx.xx dev eth0 proto kernel scope link src 192.168.1.X

J'ai pas bien identifie si ton routeur a la maison est 192.168.1.1 ou 192.168.1.18 (a la place du X dans la commande il faut mettre l'ip du routeur).

Si d'autres peuvent confirmer car je ne suis pas a 100% sur de la commande.

NIPSEN

Malakai La commande que tu proposes ne fonctionne pas, mais en effet lorsque je supprime cette route :

0.0.0.0/1 via 10.13.1.25 dev tun1

J'ai bien accés au site depuis l'extérieur, en revanche rTorrent ne passe plus par le VPN... Aille.

NIPSEN

Bon j'ai peut-etre enfin trouvé :

ip route add 77.xx.xx.xx via 192.168.1.1 dev eth0

Avec ceci j'arrive bien à me connecté depuis l'ip 77..... au webserver 🙂
Maintenant, il faudrait que je trouve comment reussir depuis toutes les ip extérieurs !

ip route show :

0.0.0.0/1 via 10.8.0.237 dev tun0 
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.18 metric 1024 
10.8.0.1 via 10.8.0.237 dev tun0 
10.8.0.237 dev tun0 proto kernel scope link src 10.8.0.238 
77.xx.xx.xx via 192.168.1.1 dev eth0 
128.0.0.0/1 via 10.8.0.237 dev tun0 
149.202.187.8 via 192.168.1.1 dev eth0 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.18 
192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.18 metric 1024

NIPSEN

Petit complément d'info, j'ai du mal à comprendre pourquoi j'ai des différences entre "netstat" et "ip route" :

[root@alarmpi ~]# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.8.0.237      128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
10.8.0.1        10.8.0.237      255.255.255.255 UGH       0 0          0 tun0
10.8.0.237      0.0.0.0         255.255.255.255 UH        0 0          0 tun0
128.0.0.0       10.8.0.237      128.0.0.0       UG        0 0          0 tun0
149.202.187.8   192.168.1.1     255.255.255.255 UGH       0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.1.1     0.0.0.0         255.255.255.255 UH        0 0          0 eth0

[root@alarmpi ~]# ip route show
0.0.0.0/1 via 10.8.0.237 dev tun0 
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.18 metric 1024 
10.8.0.1 via 10.8.0.237 dev tun0 
10.8.0.237 dev tun0 proto kernel scope link src 10.8.0.238 
128.0.0.0/1 via 10.8.0.237 dev tun0 
149.202.187.8 via 192.168.1.1 dev eth0 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.18 
192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.18 metric 1024

Malakai

Le probleme avec cette methode est que si t'as une personne qui partage/telecharge le meme fichier que toi et utilise l'ip 77.xx.xx.xx (je sais pas si c'est ton ip publique), la connexion ne se ferra plus au travers du vpn mais en direct par ton FAI. Ce qui veut dire que si tu veux que ca marche depuis toutes les ips exterieures, alors ton vpn n'a plus d'utilite car toutes les connexions se ferront en direct.
Faut trouver un autre moyen de faire passer le traffic torrent au travers du vpn mais le reste non...
Je sais plus ou j'ai lu ca (sans l'avoir tester, donc a voir), mais il est possible d'avoir plusieurs tables de routage. Une table de routage normale utilisee pour tout le traffic (sauf torrent) et une autre table de routage exclusivement pour torrent (qui utilise comme gateway ton vpn). Apres tu tag le traffic sur les ports utilises par le client vpn pour qu'il utilise la seconde table de routage.
Malheureusement comme je sais plus ou j'ai lu ca je n'ai pas de lien sous la main, mais je pense qu'en cherchant un peu sur Google il y a moyen de trouver des tutos.

Edit: Une recherche rapide sur notre ami gg m'a donne ce lien (le second exemple peut etre pris comme base pour ce que tu veux faire - contenu en anglais).

NIPSEN

Malakai j'ai trouvé ça, j'en avais parlé dans mon premier post, mais je n'arrive pas à l'appliquer à mon cas:

http://superuser.com/questions/753736/accessing-a-webserver-hosted-behind-vpn-with-closed-ports-remotely

Page suivante »