slingamn / namespaced-openvpn

Wrapper for OpenVPN on Linux solving various privacy issues

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Split hosted services from tunnel

mgaulton opened this issue · comments

So I mentioned this before about hosting http/s and ssh on the host machine while running the tunnel inside the namespace.
I am still getting martians when I attempt this, so my router is forwarding the traffic but the kernel isn't handling it.
What should the routes look like in the root namespace when the tunnel is established.

I think the 0.0.0.0/1 and 128.0.0.0/1 routes are the problem.

namespaced-openvpn should not make any changes to the routes in the root namespace. Is --route-noexec appearing on the final openvpn command line as expected?

i just bounced the box so waiting for it to come up. I thought I cleared anything from the old method i was using but perhaps i missed something and those got left behind?

Can you show me what your routes look like so I can compare?

Hmm, this is what I found. Ip route/link/add for both namespaces and a ps output showing openvpn.

ROOT namespace
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 4c:cc:6a:43:45:5b brd ff:ff:ff:ff:ff:ff
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100
link/none
5: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 02:42:36:e0:b4:1e brd ff:ff:ff:ff:ff:ff
7: veth6a1e87b@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
link/ether aa:d4:be:a2:69:8c brd ff:ff:ff:ff:ff:ff link-netnsid 0

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 4c:cc:6a:43:45:5b brd ff:ff:ff:ff:ff:ff
inet 192.168.2.5/24 brd 192.168.2.255 scope global eth0
valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.35.0.26 peer 10.35.0.25/32 scope global tun0
valid_lft forever preferred_lft forever
5: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:36:e0:b4:1e brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
7: veth6a1e87b@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether aa:d4:be:a2:69:8c brd ff:ff:ff:ff:ff:ff link-netnsid 0

0.0.0.0/1 via 10.35.0.25 dev tun0
default via 192.168.2.1 dev eth0
10.35.0.1 via 10.35.0.25 dev tun0
10.35.0.25 dev tun0 proto kernel scope link src 10.35.0.26
128.0.0.0/1 via 10.35.0.25 dev tun0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
VPNIP via 192.168.2.1 dev eth0
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.5

Netspace VPN

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
4: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100
link/none

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
4: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.35.0.34 peer 10.35.0.33/32 scope global tun1
valid_lft forever preferred_lft forever
inet6 fe80::789f:6db7:d0dd:9db1/64 scope link flags 800
valid_lft forever preferred_lft forever

default dev tun1 scope link
10.35.0.33 dev tun1 proto kernel scope link src 10.35.0.34

Procs
4 S root 1466 1 1 80 0 - 11758 SyS_po 16:35 ? 00:00:05 openvpn --dev tun --config /etc/openvpn/vpn.conf --ifconfig-noexec --route-noexec --script-security 2 --route-up /usr/local/sbin/namespaced-openvpn vpn push = 0
5 S root 1520 1 2 80 0 - 11757 SyS_po 16:35 ? 00:00:13 /usr/sbin/openvpn --daemon --suppress-timestamps --writepid /run/openvpn/vpn.pid --cd /etc/openvpn/ --config vpn.conf

So i have a tun on the inside and outside of the namespace, but when iptraf looks, it seems to be working?

Also, i'm starting from a systemd unit file for vpn-namespace, then it launches the sub-service in the namespace. This seems to be working.

Process 1466 is the correct/desired openvpn process started by namespaced-openvpn. Process 1520 is an additional, undesired process started by some other systemd unit (or something outside systemd); this is what's breaking your routes.

Here's my output (with some redactions and substitutions): https://gist.github.com/slingamn/496d6fc2b369b339d465abb11d12ebe8

hmm, i thought 1520 was just a child of 1466 initially. let me comb my configs, see if i can find it.
I removed the old unit files / bash scripts I was using previously, but maybe i missed something.
will update you

Ah ha! i found it. I tweaked the unit files that i used with the last method to make this work and I had a line that was calling openvpn.

Wants=openvpn@torguard.service

So now I can ssh in, and the tun0 is in the namespace. Thanks. That was my mistake.