Service Dependencies

[mgaulton]

Hey There, I'm using a different method and looking at switching to your project, as I was hoping it would skip the need for bridged interfaces that my current method uses. I'm hoping that if I put the tun interface into the namespace, that the reset of the system can not live with the restrictions of not being able to host services, is this the case? I'm trying to set it up so that this MUST be running as a service before other services (ie torrent) are launched. This is the current method i'm using https://gist.github.com/JimboMonkey1234/1dfed632f6a45bb5f06bbb1c7eef770d

[slingamn]

Thanks for your question! I think it's likely that namespaced-openvpn can simplify your setup.

I'm having trouble understanding your question. Is "reset" a typo for "rest"? What do you mean by "host services"?

[mgaulton]

Sorry, thinking and typing got away from me :)

hosting services ie the machine has ssh/http on it but with vpn running, i can't access those remotely. I had hoped using a namespace would allow for external IP access while still maintaining privacy for the namespace connected applications.

rest as in the root namespace, where the default network stack and applications run. Yes reset was a typo :) The goal VPN in namespace, isolating specific processes. root namespace can still received connections from external on the ISP address to ssh/https

Thanks!

[slingamn]

namespaced-openvpn should handle this use case correctly (I've tested it myself on a colocated machine). Since the sshd and httpd continue to run in the root namespace, their routes are unaffected and they should be able to respond to TCP connections as usual.

[mgaulton]

OK, so maybe my current method is doing something to the routes. I attempted your project but still couldn't connect. I'll keep experimenting. Any thoughts on the making it a service dependency for something like deluged?

[mgaulton]

OK, so i've created a systemd unit file calling your project and the dependency seems to be working as expected. What i'm seeing is it creates the namespace "vpn" with tun1 inside the namespace but also tun0 gets created in the root namespace. I cannot connect to the external ssh port while its active. Any thoughts?

[mgaulton]

Ahh i see why i think, not sure how to fix it though. I'm getting martian errors :( my connect goes "internet > router > linuxbox" 2019-01-15T14:14:35.958214-05:00 server6 kernel: [ 757.907915] IPv4: martian source 192.168.x.x from y.y.y.y, on dev eth0

[mgaulton]

So this seems to work for the service

path: /etc/systemd/system/vpn-namespace.service

[Unit] Description=Setup the VPN namespace

[Service] Type=oneshot ExecStart=/usr/local/sbin/namespaced-openvpn --namespace vpn --dev tun --config /etc/openvpn/torguard.conf ExecReload=/usr/bin/killall namespaced-openvpn;/usr/local/sbin/namespaced-openvpn --namespace vpn --dev tun --config /etc/openvpn/torguard.conf ExecStop=/usr/bin/killall namespaced-openvpn RemainAfterExit=yes

[Install] WantedBy=deluged.service

[mgaulton]

Follow up question: is there any need for this https://github.com/wknapik/vpnfailsafe with the way you build sessions?

[slingamn]

1. Do things work as expected when run manually from the command line, i.e., when you just invoke sudo namespaced-openvpn --config my.config.file?
2. What do the output of ip addr and ip route say (both in the root namespace and the protected namespace) when the bad behavior is observed? (Feel free to redact any private information; you can also e-mail me at the address found in the git log.)

Martians or rpaf failures seem like symptoms of the isolation not working correctly.

re. service dependencies, there are some subtleties involved in communicating the process status between openvpn and systemd. One strategy that might work is to use the --daemon argument to openvpn together with Type=forking in the systemd unit file (i.e., systemd's backwards compatibility with traditional UNIX daemonization). See man 5 systemd.service and man 8 openvpn for details.

[slingamn]

Oh, sorry, your latest comments came in while I was still writing :-)

namespaced-openvpn should eliminate the need for any "fail safe" or "kill switch". As long as the sensitive process is being run in the protected namespace, if the VPN connection fails, it will have no connectivity, rather than reverting to an unencrypted connection.

[mgaulton]

OK, sorry, I started experimenting again and wanted to document while it was fresh lol Service seems to work as expected at the moment. Tun1 in namespace, tun0 outside, with traffic routing out. I do have rules that say "isolation user cannot send to eth0 out, only tun0" in iptables and that is the user that starts the sensitive process.

Thank you. I figured that the vpnfailsafe would be unnecessary. I just like to confirm my thoughts :) You've been great, I really appreciate your help.

[slingamn]

No problem --- thanks for your input! It's very helpful to have a real-world use case.

If this issue is resolved, we can close it and open a separate one to investigate/document different ways of running namespaced-openvpn as a systemd unit. I think Type=forking is the "right" approach but I'd have to confirm it.

[mgaulton]

i wasn't sure. type=forking assumes that it will exit after forking a new process. i wasn't sure if it stays resident.

[mgaulton]

Closing pending a separate issue for systemd options.