Can an Nginx reverse proxy container communicate with the host?

[JC Connell]

I'm running netdata (https://github.com/firehol/netdata) on my Proxmox hosts. One of the hosts runs an Nginx reverse proxy LXC container so that I can remotely access some internal services.

I decided to try and setup Nginx to reverse proxy the netdata info but I couldn't get sort it out. The nginx logs state that the connection was timing out.

Are LXC containers allowed to communicate with the host in this manner? Is something blocking what I'm trying to accomplish?

 

[fortechitsolutions]

Hi JC, I am not entirely certain I understand how your nginx instance is desired to be communicating with the proxmox underlying bare-metal host. I briefly skimmed https://github.com/firehol/netdata and I'm guessing, maybe, you are trying to use something like IPC/Semaphore and this is timing out? Which is more or less what we would expect, unless you precisely configured the LXC instance to have access to the designated underlying bare-metal resources of the proxmox-box. (I'm not even sure that is possible to be honest - I have only done mickeymouse things like pass-through-filesystem access )

Anyhoo. I am guessing that vanilla IPV4 network based communication would work kickety-boo, since it is more inherently 'not trust based on same physical host way of communicating' but rather throwing packets back and forth over the network (ie, in this case a network which is very local indeed, but still nonetheless a IPV4 network ..)

Tim

 

[JC Connell]

I have netdata installed on the Proxmox host. It's available on the LAN as http://pve1:19999. I have nginx installed as a reverse proxy in an LXC container on the same host, pve1.

I'm trying to make netdata accessible from the WAN using nginx. With this configuration, I was unable to access netdata and I'm not sure why.

nginx has this in the error log:

2017/06/02 17:51:28 [error] 4286#4286: *186784 upstream timed out (110: Connection timed out) while connecting to upstream, client: 10.0.1.164, server: netdata.example.com, request: "GET / HTTP/2.0", upstream: "http://10.0.100.10:19999/", host: "netdata.example.com"

The reason I've posted here is because I recall at one point reading that there may be issues when and LXC container attempts to access resources on the host, even if using IPV4. Otherwise, I'm not sure why I'm experiencing this issue.

 

[fortechitsolutions]

I don't think there should be any problem just because it is LXC that happens to be where the nginx instance lives. Can you simplify to debug, for example, proxy something else more boring first (a hello world web page?) as a light bulb test ? (ie, is your reverse proxy well configured, etc?)

Tim

 

[JC Connell]

There are six other services, some of them more complex even, being proxied from this container. Here is the Nginx config file for this subdomain.

upstream netdata {
        # change this to your port number
        server 10.0.100.10:19999;
        keepalive 64;
}

server {
        listen 80;
        listen [::]:80;
        server_name netdata.example.com; # replace this with your domain
        return 301 https://$server_name$request_uri;
}

server {
        listen 443 ssl;
        listen [::]:443;

        server_name netdata.example.com;

        root /var/www/netdata-certbot-webroot;

        # The public and private parts of the certificate are linked here
        ssl_certificate /etc/letsencrypt/live/netdata.example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/netdata.example.com/privkey.pem;

        location /.well-known {
                root /var/www/ssl-proof/netdata/;
        }

        location / {
                #include /etc/nginx/naxsi.rules;
                proxy_pass_header Authorization;
                proxy_set_header Host $host;
                #proxy_set_header X-Real-IP $remote_addr;
                #proxy_set_header X-Forwarded-Proto $scheme;
                #proxy_set_header X-Forwarded-Port $server_port;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header Connection "";
                #proxy_read_timeout 900s;

                proxy_set_header X-Forwarded-Host $host;
                proxy_set_header X-Forwarded-Server $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_pass http://netdata;
                proxy_http_version 1.1;
                proxy_pass_request_headers on;
                proxy_set_header Connection "keep-alive";
                proxy_store off;
                gzip on;
                gzip_proxied any;
                gzip_types *;
        }

        # WordPress Pingback Request Denial
        if ($http_user_agent ~* "WordPress") {
            return 403;
        }

        if ($request_method !~ ^(GET|HEAD|OPTIONS)$ ) {
            return 403;
        }
}

 

[fortechitsolutions]

Hi, alas I think nginx config review exceeds my brain today (I'm doing 'fun forum posts to pass time while I'm sick, sorry). So functionalist perspective I might suggest,
-- rule out the LXC issue, by spinning up a small KVM based ?debian or whatever you prefer? host and transplant, precisely, your nginx config and so forth, in there, spin down the LXC instance and even use the same IP etc. on the new test-deb-host.
-- get things working there - if required, strip out all other services you are proxying, simplify the config, until you have a 'minimum viable success use case' for precisely the thing only which appears to be failing. remove all the other bits (comment out .. temporary measures) .. so that you can get your desired proxy behaviour for this port 19999 data). Use a boring known-good-working sometthing else first if necessary, then back over to to desired config next.

I might guess? it is an issue with nginx reverse proxy for example more so than anything else, but I am certainly not positive. Just a few fly-by comments really..


Tim