ANSWERED Split-tunneling: rutorrent in VPN, nginx out

[rgrdgr 0]

I am running a number of services on my Ubuntu machine that I don't want or need to go through the tunnel.  They are proxied using Nginx.  However, as soon as I start eddie-cli, I lose external access to Nginx.  I assume that's to do with the port forwarding, etc.

Is there a way to tell eddie (or using routes or iptables?) to leave the Nginx out?  I tried tell Nginx to bind to eno1 instead of tun0, but that didn't make a difference.

I do need rutorrent to accept incoming connections via a port forwarded by airvpn.  I assume (not sure if I'm correct) that I need eddie running for that to work?

[OpenSourcerer 1442]

No easy way, I guess. All your traffic is routed through the VPN according to the routing table, so even binding software to some interfaces won't reverse it.
A more complicated way is to use cgroups, as Mr. corrado's qomui is doing it:

[NaDre 157]

3 hours ago, rgrdgr said:

I am running a number of services on my Ubuntu machine that I don't want or need to go through the tunnel.  They are proxied using Nginx.  However, as soon as I start eddie-cli, I lose external access to Nginx.  I assume that's to do with the port forwarding, etc.

Is there a way to tell eddie (or using routes or iptables?) to leave the Nginx out?  I tried tell Nginx to bind to eno1 instead of tun0, but that didn't make a difference.

I do need rutorrent to accept incoming connections via a port forwarded by airvpn.  I assume (not sure if I'm correct) that I need eddie running for that to work?

For an example of how to use the VPN only for programs that you bind to the VPN IP address see this:

https://github.com/tool-maker/VPN_just_for_torrents/wiki/Running-OpenVPN-on-Linux-without-VPN-as-Default-Gateway
or
https://gitlab.com/tool-maker/vpn_guides/-/wikis/Running-OpenVPN-on-Linux-without-VPN-as-Default-Gateway

That example does not use Eddie. But you should be able to adapt the exit code there for use with Eddie. It sets up "source address routing" for the VPN IP address. And creates the illusion that the local IP address is the same for any server. You can then bind rtorrent to that local IP address ("bind = 10.44.0.2" in rtorrent.conf).

If you would be OK with having the VPN be the default gateway, just so long as you can still access your remote server by ssh or nginx, then see this:

https://github.com/tool-maker/VPN_just_for_torrents/wiki/Maintaining-SSH-Access-Using-a-VPN-on-a-Remote-Linux-Server
or
https://gitlab.com/tool-maker/vpn_guides/-/wikis/Maintaining-SSH-Access-Using-a-VPN-on-a-Remote-Linux-Server

When the VPN becomes the default gateway, access to ssh or nginx from remote locations will no longer work, unless you do some set up before starting the VPN, as in that example.

The examples use iptables. I have been meaning to update them to use nft, since iptables will be deprecated before long.
 

[rgrdgr 0]

I figured out a simple way that's more of a workaround, but was very straightforward.  I have a Synology NAS on the same network, so I let the Synology NAS act as a reverse proxy.  Synology uses nginx, so it was pretty simple to configure that.  Connections via the local network don't go through the VPN, so it works exactly as I wanted.