split tunnel with deluge user, gtk errors
|
Posts: 12
Threads: 1
Joined: Oct 2016
Reputation:
0
[Not Solved]
Oct 13, 2016, 06:37 PM
(This post was last modified: Oct 13, 2016, 06:42 PM by bluenote.)
(Oct 13, 2016, 06:24 PM)drake Wrote: Sorry, I missed that.
Everything looks fine to me, but I'm not sure about the openvpn base config.
Please try without the following lines:
route-metric 1 -> not sure if this options interferes with route-noexec, it is very likely
remote-random (should not matter, it just randomizes if multiple vpn addresses are given, but remove it for now)
And let's check the some remaining config options to be sure everything is set as needed. What is the output of
Code:
sudo cat /proc/sys/net/ipv4/conf/tun0/rp_filter
In /etc/iproute2/rt_tables you have added user deluge, correct? So you have
200 deluge
It might take some time to troubleshoot, but it needs to work!
Hey Drake
You did catch the fact that my tests ^^^ above pointed the finger to only name resolution not working through the tunnel (and I guess thats because of filtering with the iptables part that I don't know much about). Since I can ping through the vpn interface just fine (and, before starting the guide, I confirmed proper operation of the tunnel).
cat /etc/iproute2/rt_tables
Quote:#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
200 deluge
RP filter reports 2 as we expect
thx
Here's output demonstrating what I'm talking about - the forwarding of traffic according to user tagging appears to work, but not DNS.
Quote:[alarm@alarmpi ~]$ sudo -u deluge ping http://www.google.ca
ping: http://www.google.ca: Name or service not known
[alarm@alarmpi ~]$ sudo -u deluge ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=118 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=116 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=132 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=171 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=137 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 116.035/135.066/171.910/20.120 ms
[alarm@alarmpi ~]$ ping http://www.google.ca
PING http://www.google.ca (66.199.151.173) 56(84) bytes of data.
64 bytes from http://www.google.ca (66.199.151.173): icmp_seq=1 ttl=58 time=68.7 ms
64 bytes from http://www.google.ca (66.199.151.173): icmp_seq=2 ttl=58 time=34.7 ms
^C
--- http://www.google.ca ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 34.744/51.722/68.700/16.978 ms
Posts: 244
Threads: 1
Joined: Jul 2016
Reputation:
12
[Not Solved]
Oct 13, 2016, 06:57 PM
This is the problem if I read from the phone using Tapatalk, sorry for this. To me it was not clear that actually your tunnel is working, but only name resolution over tunnel is not.
I really don't get why curl is no working for you. You started in the first post that
Code:
sudo -u deluge -i -- curl ipinfo.io
doesn't work for you. I just don't get it.
Can you try
Code:
sudo -u deluge -i -- ping google.ca
I just tested, and it works perfectly fine for me.
Quote:sudo -u vpn -i -- ping google.ca
PING google.ca (195.95.178.222) 56(84) bytes of data.
64 bytes from 195.95.178.222: icmp_seq=1 ttl=58 time=41.7 ms
64 bytes from 195.95.178.222: icmp_seq=2 ttl=58 time=41.3 ms
64 bytes from 195.95.178.222: icmp_seq=3 ttl=58 time=41.4 ms
64 bytes from 195.95.178.222: icmp_seq=4 ttl=58 time=41.8 ms
64 bytes from 195.95.178.222: icmp_seq=5 ttl=58 time=41.6 ms
64 bytes from 195.95.178.222: icmp_seq=6 ttl=58 time=41.7 ms
64 bytes from 195.95.178.222: icmp_seq=7 ttl=58 time=42.1 ms
64 bytes from 195.95.178.222: icmp_seq=8 ttl=58 time=42.3 ms
64 bytes from 195.95.178.222: icmp_seq=9 ttl=58 time=41.3 ms
64 bytes from 195.95.178.222: icmp_seq=10 ttl=58 time=41.5 ms
64 bytes from 195.95.178.222: icmp_seq=11 ttl=58 time=42.1 ms
64 bytes from 195.95.178.222: icmp_seq=12 ttl=58 time=41.9 ms
^C
--- google.ca ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11017ms
rtt min/avg/max/mdev = 41.338/41.779/42.353/0.340 ms
I can only think of the missing update-resolv-conf. Try to add that part as well (you can use Google's DNS as option 1 and 2, and add OpenDSN as third option).
I just spoke with a friend of mine, he uses Arch, and the same guide and same config as here works for him perfectly.
We had a problem with resolv-conf if the static IP was set on the server instead of the router. Do you have static IP set from router to the server running split tunnel? I'm just thinking out loud what could be the problem.
Posts: 12
Threads: 1
Joined: Oct 2016
Reputation:
0
[Not Solved]
Oct 13, 2016, 08:55 PM
(Oct 13, 2016, 06:57 PM)drake Wrote: This is the problem if I read from the phone using Tapatalk, sorry for this. To me it was not clear that actually your tunnel is working, but only name resolution over tunnel is not.
I really don't get why curl is no working for you. You started in the first post that
Code:
sudo -u deluge -i -- curl ipinfo.io
doesn't work for you. I just don't get it.
Can you try
Code:
sudo -u deluge -i -- ping google.ca
I just tested, and it works perfectly fine for me.
Quote:sudo -u vpn -i -- ping google.ca
PING google.ca (195.95.178.222) 56(84) bytes of data.
64 bytes from 195.95.178.222: icmp_seq=1 ttl=58 time=41.7 ms
64 bytes from 195.95.178.222: icmp_seq=2 ttl=58 time=41.3 ms
64 bytes from 195.95.178.222: icmp_seq=3 ttl=58 time=41.4 ms
64 bytes from 195.95.178.222: icmp_seq=4 ttl=58 time=41.8 ms
64 bytes from 195.95.178.222: icmp_seq=5 ttl=58 time=41.6 ms
64 bytes from 195.95.178.222: icmp_seq=6 ttl=58 time=41.7 ms
64 bytes from 195.95.178.222: icmp_seq=7 ttl=58 time=42.1 ms
64 bytes from 195.95.178.222: icmp_seq=8 ttl=58 time=42.3 ms
64 bytes from 195.95.178.222: icmp_seq=9 ttl=58 time=41.3 ms
64 bytes from 195.95.178.222: icmp_seq=10 ttl=58 time=41.5 ms
64 bytes from 195.95.178.222: icmp_seq=11 ttl=58 time=42.1 ms
64 bytes from 195.95.178.222: icmp_seq=12 ttl=58 time=41.9 ms
^C
--- google.ca ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11017ms
rtt min/avg/max/mdev = 41.338/41.779/42.353/0.340 ms
I can only think of the missing update-resolv-conf. Try to add that part as well (you can use Google's DNS as option 1 and 2, and add OpenDSN as third option).
I just spoke with a friend of mine, he uses Arch, and the same guide and same config as here works for him perfectly.
We had a problem with resolv-conf if the static IP was set on the server instead of the router. Do you have static IP set from router to the server running split tunnel? I'm just thinking out loud what could be the problem.
It's definitely name resolution related only:
Quote:sudo -u deluge curl 52.45.201.150
{
"ip": "209.x.x.x", (vpn IP)
"hostname": "No Hostname",
"city": "San Jose",
"region": "California",
"country": "US",
"loc": "37.3394,-121.8950",
"org": "AS7203 Leaseweb USA, Inc.",
"phone": "408"
Quote: curl ipinfo.io
{
"ip": "x.y.z.a", (home outside ip)
"hostname": "xxx",
"city": "xxx",
"region": "xxx",
"country": "xx",
"loc": "49.2475,-123.1210",
"org": "xxx",
"postal": "XXX"
I am thinking that right now, dns requests are being filtered, or still somehow being forced out that interface when I don't want them to be.
Do you have ideas on how I can test that to narrow it down?
thx
Posts: 244
Threads: 1
Joined: Jul 2016
Reputation:
12
[Not Solved]
Oct 13, 2016, 09:03 PM
I don't understand, really. It works for me. Did you try to configure update-resolv-conf like I said? As you can see, I can ping google.ca over vpn without any problem.
Maybe a router setting, like LocalDNS?
There might be an iptables setting too, I will take look into this, but I'm startimg to get out of ideas, since it really works for me and I can't see what could be wrong on your setup.
Sent from my Xperia Z3 Compact using Tapatalk
Posts: 12
Threads: 1
Joined: Oct 2016
Reputation:
0
[Not Solved]
Oct 13, 2016, 10:04 PM
(Oct 13, 2016, 09:03 PM)drake Wrote: I don't understand, really. It works for me. Did you try to configure update-resolv-conf like I said? As you can see, I can ping google.ca over vpn without any problem.
Maybe a router setting, like LocalDNS?
There might be an iptables setting too, I will take look into this, but I'm startimg to get out of ideas, since it really works for me and I can't see what could be wrong on your setup.
Sent from my Xperia Z3 Compact using Tapatalk
I haven't tried the update-resolv since I don't have a base file to use. Could you paste yours?
thx
Posts: 12
Threads: 1
Joined: Oct 2016
Reputation:
0
[Not Solved]
Oct 13, 2016, 11:29 PM
(This post was last modified: Oct 14, 2016, 06:21 AM by bluenote.)
Ok, I think figured it out - indeed, you're correct that it (sortof) has to do with the dns-resolve-conf.
The problem is that DNS is set to a private IP on the local interface. So since user deluge DNS requests will also be forwarded out that way, but they can never be routed properly to 192.168 address.
This is demonstrated like so:
Quote:Success:
sudo -u deluge drill http://www.google.ca 8.8.8.8
[sudo]
[sudo] password for alarm:
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 59322
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; http://www.google.ca. IN A
;; ANSWER SECTION:
http://www.google.ca. 299 IN A 172.217.5.99
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 130 msec
;; SERVER: 8.8.8.8
;; WHEN: Thu Oct 13 16:27:01 2016
;; MSG SIZE rcvd: 47
Failure:
sudo -u deluge drill http://www.google.ca
Error: error sending query: Could not send or receive, because of network error
Actually I mostly got it working now by adding a public DNS. But what I do need to know how to do now, maybe you can help, is to allow local access? For example, if deluge-web runs as regular user, then it cannot talk to the daemon. Or if it runs as deluge user, then PC's on the local network cannot talk to the web interface.
thanks
Posts: 244
Threads: 1
Joined: Jul 2016
Reputation:
12
[Not Solved]
Oct 14, 2016, 08:03 AM
(This post was last modified: Oct 14, 2016, 08:06 AM by drake.)
(Oct 13, 2016, 11:29 PM)bluenote Wrote: Ok, I think figured it out - indeed, you're correct that it (sortof) has to do with the dns-resolve-conf.
The problem is that DNS is set to a private IP on the local interface. So since user deluge DNS requests will also be forwarded out that way, but they can never be routed properly to 192.168 address.
This is why I told you to check the DNS settings. You need to use a public DNS, and the proper way to do that is to use update-resolv-conf Here is the copy of the update-resolv-conf default, replace the 3 DNS entries with the DNS you choose (public DNS). Update-resolv-conf
You can do it other way, but this is how it should be if using VPN. Note: your DNS will be the one set in update-resolv-con for non VPN users until the VPN tunnel is up! But if you disconnect VPN, it will revert back to the default DNS you set.
Quote:bluenote
Actually I mostly got it working now by adding a public DNS. But what I do need to know how to do now, maybe you can help, is to allow local access? For example, if deluge-web runs as regular user, then it cannot talk to the daemon. Or if it runs as deluge user, then PC's on the local network cannot talk to the web interface.
Glad to hear it is working. For local access you need to run an nginx reverse proxy. Since the whole point of vpn split tunnel is to 1) separate non-vpn traffic from other users, and 2) make sure there is no IP leak (automatic killswitch). The safest and best way to achieve this is by using iptables. You can't have access to Deluge daemon from other then localhost (localhost is allowed in the iptables if you look at the script), as everything else is blocked/rejected. This actually prevents any leak from or to vpn<->non-vpn interfaces. (We use only conntrack --ctstate ESTABLISHED for INPUT, and we don't even use a ctstate for OUTPUT at all, except when port forwarding is needed).
If you need only local network access to Deluge daemon, then you can use a very simple nginx vhost. The draft of the Deluge with Split Tunnel on Ubuntu Server 16.04 is basically ready, you can check the guide here: Configure Deluge for VPN Split Tunneling Ubuntu 16.04 Note: this is still an unpublished draft, but everything should work.
Go to the Configure Deluge Remote Access with nginx Reverse Proxy part and do those simple steps, and you will have access to your Deluge daemon from your local network. Note: if you need access from outside of your local network, make sure you use TLS/SSL nginx configuration, don't use unencrypted http!
Deluge Web UI can be configured to be run as your non-vpn user. You need to modify the user Web UI runs, put your regular user there, leave the group as deluge. A new set of configuration files will be created in your regular user's home directory for the Web UI (/home/user/.config/deluge/) once you start the Web UI systemd unit. You need to make sure that your Deluge daemon directory and files are readable and writable by the user running Web UI (you will have the Deluge daemon config in /home/deluge/.config/deluge/ directory), and make sure your user is part of the deluge group. You will of course need to make sure that the Web UI's defaul daemon in web.conf is the localhost ("127.0.0.1:58846"). That should be. I had this running for a while, but I went to ngixn reverse proxy as it is so much better and safer, and I need access to Deluge daemon from outside of my local network, and opening ports is really not a good idea.
Note: I wrote this without my notes, as I don't have access to them now, but it should work the way I described.
One more awesome possibility you can do with Deluge: you can use a ThinClien of the Deluge to access Deluge Daemon. Check out this guide: Configure Deluge ThinClient on Ubuntu + Windows For me this is the best way to manage torrents (when I'm not using Transdroid). And the good news is, you can have even access with ThinClien from outside of your local network, you need to open port 58846 in your router, but Deluge ThinClient and Deluge daemon uses encrypted communication and it is considered pretty much safe to do it. Just make sure you set a strong password, as always.
Hope this helps you, let me know what you managed to configure.
Posts: 12
Threads: 1
Joined: Oct 2016
Reputation:
0
[Not Solved]
Oct 14, 2016, 05:04 PM
I don't really want to use nginx for local access. Do you know how I would go about modifying the iptables to allow only from/to specific local subnet? Or, for example, to route DNS packets to local subnet? I would like to do those two things.
thanks
Posts: 244
Threads: 1
Joined: Jul 2016
Reputation:
12
[Not Solved]
Oct 14, 2016, 05:52 PM
You can use Deluge web ui without nginx like I told you, you just need to do the steps I wrote you. As for modify the iptables, I'm sorry, but I can't help you as it would need a complete rewrite since this behaviour is intended with the vpn split tunnel, in order to be sure that vpn tunnel is completely isolated from other interfaces. With nginx on localhost you just have localhost access, and no other interfaces. But since Deluge has a separate web ui service, it is even possible without nginx. Both ways give you the benefit of having secure vpn tunnel for torrents and all the other services you would like to route over vpn.
Sent from my Xperia Z3 Compact using Tapatalk
Posts: 12
Threads: 1
Joined: Oct 2016
Reputation:
0
[Not Solved]
Oct 14, 2016, 09:34 PM
(This post was last modified: Oct 14, 2016, 09:35 PM by bluenote.)
I think we might be misunderstanding each other. When running the deluge-web as regular user, it doesn't seem to be able to speak to the deluged service. So that didn't work for me. (Probably because packets go out from source IP rather than localhost? I'm guessing here, but anyways, they are filtered it seems.) If you can tell me how to make that part work, that would be the best solution.
Anyways, since I needed access besides localhost (since this is on a pi and it is headless for the most part) I finally comprehended enough iptables to make this change:
iptables -t mangle -A OUTPUT ! --dest 192.168.10.0/24 -m owner --uid-owner $VPNUSER -j MARK --set-mark 0x1
iptables -t mangle -A OUTPUT ! --src 192.168.10.0/24 -j MARK --set-mark 0x1
I am not super comfortable with this (for reasons you mention), but it does seem to work. When I test deluged with two torrent-leak testers, it reports VPN ip only. When I take the tunnel offline, then deluge is receiving timeouts only.
I would like to have a better understanding of iptables though to do a better job. :/
thank you f you enlighten me with any improvements on this, please go ahead because I have so little confidence in my iptables skills
EDIT: Note that even though that allows local network access, technically it should not be able to reach out beyond the network, since destination would have to be other than local network to be routed. And if dest is outside, then that rule does not fire and packet is filtered to VPN.
|
|
|