jamesmcm / vopono

Run applications through VPN tunnels with temporary network namespaces
GNU General Public License v3.0
888 stars 46 forks source link

Running a vopono instance with multiple programs #261

Closed jramseygreen closed 8 months ago

jramseygreen commented 8 months ago

I am currently successfully using vopono to run one browser - e.g. firefox - but I would like to run two - e.g. firefox and chrome - using the same network namespace provided by vopono. In an ideal world I would also be able to proxy two ports; one for each program.

I envision being able to do something like: vopono exec -f 8080 -f 8081 --custom /vpn.ovpn --protocol openvpn program1 program2

jamesmcm commented 8 months ago

You can do this already by just running two commands:

 $ vopono exec -f 8080 -f 8081 --custom /vpn.ovpn --protocol openvpn program1
 $ vopono exec --custom /vpn.ovpn --protocol openvpn program2

It should automatically detect and use the running network namespace (note the network configuration options are only applied for the first program creating the namespace though i.e. -f there ).

Check the output in the second run for the line:

Using existing namespace: $NAMESPACE_NAME, will not modify firewall rules
jramseygreen commented 8 months ago

Okay so this functionality does indeed seem to work

However I'm running into issues when trying to use Prowlarr with nginx

/usr/bin/vopono -v exec -k -f 9696 -f 8080 --custom /vpn.ovpn --protocol openvpn "/opt/Prowlarr/Prowlarr -nobrowser -data=/var/lib/prowlarr/"

does launch Prowlarr and works correctly when I connect through my local ip - i.e. I connect to 192.168.x.x:9696 and it's working as expected. Similarly when I later launch another program which uses 8080 this also works correctly and binds to the existing namespace as you detailed above.

This second program has no issues running through a similar nginx configuration as what I will show you with prowlarr, which makes me think it's something prowlarr specific

server {
      server_name prowlarr.mydomain.com;

      location / {
          proxy_pass http://127.0.0.1:9696;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

          #upgrade to WebSocket protocol when requested
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "Upgrade";
      }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/prowlarr.mydomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/prowlarr.mydomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = prowlarr.mydomain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

      listen 80;
      server_name prowlarr.mydomain.com;
    return 404; # managed by Certbot

}

Regardless of whether the certbot configuration for ssl is included it has the same result; Prowlarr is unreachable via prowlarr.mydomain.com even though it is accessible from 192.168.x.x:9696

Using the -v flag for verbose it seems to send a lot of messages reading DEBUG basic_tcp_proxy > Remote closed connection when trying to connect via the domain + nginx

jramseygreen commented 8 months ago

Okay I've investigated further and solved this issue.

It turns out I was missing proxy_http_version 1.1; and it was as simple as that