nginx volume mount and layer4 reverse proxing

Currently reading
nginx volume mount and layer4 reverse proxing

777
291
NAS
DS216+II, DS118, DS718+, DS720+
Router
  1. RT2600ac
  2. MR2200ac
Operating system
  1. Windows
Mobile operating system
  1. Android
So this post aspired me to have a look, which of course obviously I'm looking into a Docker solution (although I still struggle alot with Docker...........................)

Actualy this limitation has its origin in the Synology UI - nginx itself is perfectly capable to act on layer4.

So pretty obvious that if I want to try and get nginx to do layer 4 reverse proxy-ing for me, I would try to get this done on a seperate entity running in a Docker container instead of risking to mess up the nginx were DSM is running on.

So why not use an official image: Docker Hub

So of course I'd assume, when I get this running, I need to be able to access all the files inside the container's filesystem without hassle to be able to configure this reverse proxy'ing. I would assume to just put attributes like -v /volume1/docker/nginx1/etc:/etc -v /volume1/docker/nginx1/usr:/usr/ inside the docker run command. But if I do that, then the container fails to run at all as it doesn't want to fill the volume with the content it needs (don't know why other docker container solutions does work this way without problems, the others don't).

1600510771382.png



I've also tried looking here:

It would be nice if you could change the mountpoint of a volume, but there seems to be no way to do that?

1600510276046.png
 
Last edited:
ut if I do that, then the container fails to run at all as it doesn't want to fill the volume with the content it needs (don't know why other docker container solutions does work this way without problems, the others don't).
There is a huge difference between bind mount (what the ui provides and why you used in aboves -v parameters) and docker volumes. A bind mount will overlay on top of of an existing container folder, which makes the content of the original folder unavailable for the container. For Volumes on the other hand, the behavior is identical with the difference that the original content of the target folder gets copied back into the volume the first time the volume is mounted - this behavior even works if the docker volume is backed by a bind. I hope this makes sense.

It would be nice if you could change the mountpoint of a volume, but there seems to be no way to do that?
The declaration(!) of a volume is immutable. Once created, it will never be update. This confuses people declaring volumes in docker-compose.yml files all the time :) You have to delete the declaration and create a new volume using the right parameters.

-v /volume1/docker/nginx1/etc:/etc -v /volume1/docker/nginx1/usr:/usr/
Your bind mounts kind of rip out the spine of the container...
For reverse proxy cases, in general it is sufficient to only replace /etc/nginx/nginx.conf.

Btw. If one of your usecases is TLS-Passthrogh (balance raw tls-encrypted traffic to a backend), then you might find this example useful: nginx TLS SNI routing, based on subdomain pattern
 
Last edited:
There is a huge difference between bind mount (what the ui provides and why you used in aboves -v parameters) and docker volumes. A bind mount will overlay on top of of an existing container folder, which makes the content of the original folder unavailable for the container. For Volumes on the other hand, the behavior is identical with the difference that the original content of the target folder gets copied back into the volume the first time the volume is mounted - this behavior even works if the docker volume is backed by a bind. I hope this makes sense.

Euhm.... I'll circle my head back to this one day.... Let me ditch this volume I manually created myself...

The declaration(!) of a volume is immutable. Once created, it will never be update. This confuses people declaring volumes in docker-compose.yml files all the time :) You have to delete the declaration and create a new volume using the right parameters.
Thats actually what I ment. I can't find any info how to create the volume + store it on a location I desire (like in /volume1/docker/nginx1 ) in the same command.

Your bind mounts kind of rip out the spine of the container...
I tought it kinda works like symbolic/junction links or something. Apparently not...

For reverse proxy cases, in general it is sufficient to only replace /etc/nginx/nginx.conf.
So in that case this should suffice: -v /volume1/docker/nginx1/nginx.conf:/etc/nginx/nginx.conf ?

Btw. If one of your usecases is TLS-Passthrogh (balance raw tls-encrypted traffic to a backend), then you might find this example useful: nginx TLS SNI routing, based on subdomain pattern

I think it is. So the codes shown on this page, those have to go into the nginx.conf ?

For example I want to run Synology VPN Plus on my RT2600AC , but I have port 80/443 already forwarding from WAN to my NAS. I want to find a solution to have this VPN Plus service to also run on port 443 (as it's originally designed for) so I want to somehow forward ALL traffic to vpn.mydomain.net towards my RT2600AC . Doing this via the Syno UI doesn't , because as you know that only works for layer 7 traffic.

.........Well, it works in the sense of you do get the Synology VPN Plus webpage, but once you hit 'connect' you get an error.. :)
 
Euhm.... I'll circle my head back to this one day.... Let me ditch this volume I manually created myself...
How about your try to put it in own words and I confirm or correct it?

Thats actually what I ment. I can't find any info how to create the volume + store it on a location I desire (like in /volume1/docker/nginx1 ) in the same command.

Here you go:
Code:
docker volume create --opt type=none --opt o=bind --opt device=/volume1/docker/nginx1  nginx1

Then use -v nginx1:/path/in/container to use the volume with a container.


I tought it kinda works like symbolic/junction links or something. Apparently not...

When a volume is used by a container, its source is mounted into /volume1/@docker/volumes/{volumname}/_data (replace the volume, if the docker package is not installed on volume1), which then is used to bind this host folder on top of the target folder in the container (the same way sude mount --bind /source /target would do). If the container stops the volume source gets unmounted again.

So in that case this should suffice: -v /volume1/docker/nginx1/nginx.conf:/etc/nginx/nginx.conf
For your scenario: yep.

If you'd want to terminate tls, you'd need to mount the certificate related files as well.

I think it is. So the codes shown on this page, those have to go into the nginx.conf ?
The page was ment as a starting point. ofc you'll have to adept it for your situation and let nginx forward traffic to the target based on the SNI Hostname.
 
Last edited:
You already marked the typo in the host side of the mount yourself.. just correct it.

Also:
- If you only want to use TLS passthrough, you neither need to mount certificates, nor mount content underneath/usr/share/nginx/html.
- make sure the folder/files ownership on the host side matches the uid/gid of the nginx process inside the container. I would be surprised if nginx would be executed as user root. update: docker run --rm nginx id -> i am surprised!
 
How about you post your complete docker run commands and your nginx.conf here and we work things out?

I can understand why it might look complicated, though if someone experiences has the chance to get a glimpse on what you are actualy doing, chances are high that things will be sorted out :)
 
How about you post your complete docker run commands

My last try was running this command:
docker run --name nginx1 --hostname nginx1 --restart unless-stopped --network physical_network_noproxy --ip 192.168.1.204 --dns 192.168.1.194 -v /volume1/docker/nginx1/html:/usr/share/nginx/html -v /volume1/docker/nginx1/nginx.conf:/etc/nginx/nginx.conf -d nginx

your nginx.conf here and we work things out?
euhm.... shouldn't that automatically be created by the docker container (in my case, it doesn't) ......?
 
Last edited:
euhm.... shouldn't that automatically be created by the docker container (in my case, it doesn't) ......?
Actualy the image contains a nginx.conf, but your bind mount replaces it with whatever is in your host's /volume1/docker/nginx1/nginx.conf file. It is completly up to you, to create the nginx conf. Usualy people create custom container networks, and is used for the nginx reverse proxy to target app communication. Though, if the provided dns server is able to lookup other containers and hosts in your network it should work as well..

Here is an example how an nginx.conf could look like:
YAML:
worker_processes auto;

events {
    worker_connections 2048;
}

# Error log goes to console output (we run inside a Docker container)
error_log /dev/stdout info;

http
{
    # Access log goes to console output (we run inside a Docker container)
    access_log /dev/stdout;

    include /etc/nginx/mime.types;
    default_type  application/octet-stream;

    # Connection upgrade to HTTPS1.1
    map $http_upgrade $connection_upgrade
    {
        default upgrade;
        ''      close;
    }

    server
    {
        # set DNS resolver as Docker internal DNS
        resolver 127.0.0.11 valid=10s;
        resolver_timeout 5s;

        # NGINX listener (at the container level)
        listen 443 ssl;

        # Supported HTTPS protocols
        ssl_protocols TLSv1.2;

        # SSL Certificate components (bound mind from host)
        ssl_certificate /run/secrets/cert.pem;
        ssl_certificate_key /run/secrets/key.pem;

        # Location for Docker health checks
        location /healthcheck
        {
            return 200 "healthy\n";
            default_type text/html;
        }

        # Proxy context /test back to the test service and add X-Forwarded header.
        location /test/
        {
            # Pass header info to the target service
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-Port 443;

            # Connection upgrade to HTTP1.1
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";

            # advantage of using a variable:
            # No DNS caching when resolving names, which is important if working with randomly assigned container ips.
            set $target http://test:8080;
            proxy_pass $target;

            # URLs rewriting rules inside content
            #sub_filter      '/test/gui/'  '/test-gui/';
            #sub_filter_once off;
        }
    }
}

Maybe I should look into traefik instead, hopefully things are a bit more clear there.
Traefik is only easy to use, if containers are labled with the reverse proxy rules, which does not make much sense without docker-compose. You will end up creating .toml configuration files which will have more complexity then nginx.conf files without the label detection.
 
Usualy people create custom container networks, and is used for the nginx reverse proxy to target app communication. Though, if the provided dns server is able to lookup other containers and hosts in your network it should work as well..

Yes I've setup DNS so everything is reachable with my internal DNS. But I'm hoping to also be able to reverse proxy to other apps (like MailPlus, Drive). I like the idea of having a container facing the Internet instead of the reverse proxy of my DSM.

Here is an example how an nginx.conf could look like:

I saved the example file in /volume1/docker/nginx1/etc/nginx.conf .
I then tried to start up the container again using the command I specified earlier: docker run --name nginx1 --hostname nginx1 --restart unless-stopped --network physical_network_noproxy --ip 192.168.1.204 --dns 192.168.1.194 -v /volume1/docker/nginx1/html:/usr/share/nginx/html -v /volume1/docker/nginx1/nginx.conf:/etc/nginx/nginx.conf -d nginx

Then I'm getting a tsunami of errors....
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration

/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/

/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh

10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf

10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf

/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh

/docker-entrypoint.sh: Configuration complete; ready for start up

2020/10/03 09:53:44 [emerg] 1#1: cannot load certificate "/run/secrets/cert.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/run/secrets/cert.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

nginx: [emerg] cannot load certificate "/run/secrets/cert.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/run/secrets/cert.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration

/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/

/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh

10-listen-on-ipv6-by-default.sh: error: IPv6 listen already enabled

/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh

/docker-entrypoint.sh: Configuration complete; ready for start up

2020/10/03 09:53:49 [emerg] 1#1: cannot load certificate "/run/secrets/cert.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/run/secrets/cert.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

nginx: [emerg] cannot load certificate "/run/secrets/cert.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/run/secrets/cert.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration

/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/

/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh

10-listen-on-ipv6-by-default.sh: error: IPv6 listen already enabled

/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh

/docker-entrypoint.sh: Configuration complete; ready for start up

2020/10/03 09:53:54 [emerg] 1#1: cannot load certificate "/run/secrets/cert.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/run/secrets/cert.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

nginx: [emerg] cannot load certificate "/run/secrets/cert.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/run/secrets/cert.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration

/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/

/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh

10-listen-on-ipv6-by-default.sh: error: IPv6 listen already enabled

/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh

/docker-entrypoint.sh: Configuration complete; ready for start up

2020/10/03 09:53:57 [emerg] 1#1: cannot load certificate "/run/secrets/cert.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/run/secrets/cert.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

nginx: [emerg] cannot load certificate "/run/secrets/cert.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/run/secrets/cert.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
 
That's to be expected if you don't modify the config according your needs.

The example binds SSL (actualy TLS) to port 443, which requires a certificate. I left it like this, cause I thought you are heading for a HTTPS setup. of course you need to provide certificates and mount them into the container.
 
Last edited:
ok think we are making a step forward. In the nginx.conf I first commented out SSL related stuff and added 'listen 80' just to see if the container would even work. And it does:

1601721768086.png



The example binds SSL (actualy TLS) to port 443, which requires a certificate. I left it like this, cause I thought you are heading for a HTTPS setup. of course you need to provide certificates and mount them into the container.

Yes I do want that indeed. For my domain I have these cert files:
1601721871304.png


Looking at your example, I can
certificate.crt -> copy to: /volume1/docker/nginx1/certs/ -> rename to cert.pem -> inside nginx.conf ssl_certificate /certs/cert.pem
certificate.key -> copy to: /volume1/docker/nginx1/certs/ -> rename to key.pem -> inside nginx.conf ssl_certificate /certs/key.pem

And mount this folder inside the container using -v /volume1/docker/nginx1/certs:/certs ?

Then after this works, try to figure out how to begin setting reverse proxy 'routes' inside this nginx.conf file. :)
 
You are heading in the right direction! :)

Since it's a bind mount, instead of renaming the files, you could simply rename the expected file for the certificate in the nginx.conf. I assume its a typo that you copy certificate.crt and certificate.key as cert.pem :)

This is not a letsencrypt certificate, is it? I am asking, because the filenames don't look like tat and usualy you'd want to use the "fullchain.pem" (which includes the certificate.pem and chain.pem) in order to present the client the whole required certificate chain including all intermediate ca's certificates. Don#t be confused about the .pem names I reference to, those are the names letsencrypt would've used.

Can you check if the content of certificate.crt is included in cabundle.crt? If not, you might want to create a new file that contains the content of both, which should be the equivalent to fullchain.pem and use this for your cert.pem file.
 
Last edited:
Since it's a bind mount, instead of renaming the files, you could simply rename the expected file for the certificate in the nginx.conf. I assume its a typo that you copy certificate.crt and certificate.key as cert.pem :)

That was a typo indeed. So I left the files in their original names. And it works:

1601726844315.png


Not exactly sure why it doesn't load the index.html via port 443, but since I want to use it as a reversre proxy it might not be a concern for me.

This is not a letsencrypt certificate, is it? I am asking, because the filenames don't look like tat and usualy you'd want to use the "fullchain.pem" (which includes the certificate.pem and chain.pem) in order to present the client the whole required certificate chain including all intermediate ca's certificates. Don#t be confused about the .pem names I reference to, those are the names letsencrypt would've used.

No. These are from COMODO. Let's Encrypt doesnt (or didn't) support wildcard certs, so that's why I purchased them myself.

Can you check if the content of certificate.crt is included in cabundle.crt? If not, you might want to create a new file that contains the content of both, which should be the equivalent to fullchain.pem and use this for your cert.pem file.

They aren't. in cabundle.crt I see content that looks to be 2 certificates, but inside certificate.crt I see what looks to be something else. Creating a new file with the content of both of these files resultes in these errors:
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration


/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/


/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh


10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf


10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf


/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh


/docker-entrypoint.sh: Configuration complete; ready for start up


2020/10/03 12:01:43 [emerg] 1#1: SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


nginx: [emerg] SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration


/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/


/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh


10-listen-on-ipv6-by-default.sh: error: IPv6 listen already enabled


/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh


/docker-entrypoint.sh: Configuration complete; ready for start up


2020/10/03 12:01:47 [emerg] 1#1: SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


nginx: [emerg] SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration


/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/


/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh


10-listen-on-ipv6-by-default.sh: error: IPv6 listen already enabled


/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh


/docker-entrypoint.sh: Configuration complete; ready for start up


2020/10/03 12:01:52 [emerg] 1#1: SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


nginx: [emerg] SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration


/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/


/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh


10-listen-on-ipv6-by-default.sh: error: IPv6 listen already enabled


/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh


/docker-entrypoint.sh: Configuration complete; ready for start up


2020/10/03 12:01:56 [emerg] 1#1: SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


nginx: [emerg] SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration


/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/


/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh


10-listen-on-ipv6-by-default.sh: error: IPv6 listen already enabled


/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh


/docker-entrypoint.sh: Configuration complete; ready for start up


2020/10/03 12:02:00 [emerg] 1#1: SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


nginx: [emerg] SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration


/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/


/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh


10-listen-on-ipv6-by-default.sh: error: IPv6 listen already enabled


/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh


/docker-entrypoint.sh: Configuration complete; ready for start up


2020/10/03 12:02:05 [emerg] 1#1: SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


nginx: [emerg] SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration


/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/


/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh


10-listen-on-ipv6-by-default.sh: error: IPv6 listen already enabled


/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh


/docker-entrypoint.sh: Configuration complete; ready for start up


2020/10/03 12:02:11 [emerg] 1#1: SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)


nginx: [emerg] SSL_CTX_use_PrivateKey("/certs/key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)[/qupte]
-- post merged: --

Interesting. The example you gave me gives me some kind of 'virtual' directory that can proxy route. Nice example. But 99% of my proxy route traffic will be like <service>.mydomain.com . How to do that. (Ill google meanwhile how to write that in the nginx.conf).

1601727261424.png
 
Last edited:
No. These are from COMODO. Let's Encrypt doesnt (or didn't) support wildcard certs, so that's why I purchased them myself.
Actualy it does, if your dns provider is supported by the used Let's Encrypt client (certbot, traefik, ...) for the dns01-challenge. My dns provider is supported and I am using Treafk to create and use a LE wildcard cert, heck I even run my own dyndns service at home that updates the dns entries to point to my dynamic wan ip :)

Hmm, nginx complains about a missmatch between key and cert. How did you create the new cert file? Something like this cat certificate.crt cabundle.crt > fullchain.pem?

For subdomain reverse proxying you will need to add a server block for each subdomain, which can listen on the same port, but require the fqdn for the subdomain as server_name to be different.

The healthcheck location is just an endpoint I use with a docker healthcheck I created to detect whether the container is still operationial. If a docker healthcheck is registered, it restarts the container after 3 (or was it 5?) consequitive missing responses. You can remove it - or dig deeper into the healthcheck topic ^^

I told we would sort things out, once you engage and share your progress :) In german we have a tense which litteraly translates to "completed future". So consider your objective as a completed future :) Update: I see its "Future Perfect Simple" in english.

I am heading out now and will return later tonight.
 
Actualy they do, if you dns provider is supported by the used Let's Encrypt client (certbot, traefik, ...) for the dns01-challenge. My dns provider is and I am using a LE wildcard cert, heck I even run my own dyndns service at home that updates the dns entries to point to my dynamic wan ip :)
My certs also came via my DNS provider (and they get the certs from Comodo :)). But if LE can supply free wildcard certs then I should definitly have a look at it. I have a couple of months time before my current certs expires. Automating the renewals would also be awesome.. (I use Synology's DDNS, so basically my own domain has records that eventually all CNAME's back to my Synology DDNS address).

Hmm, nginx complains about a missmatch between key and cert. How did you create the new cert file? Something like this cat certificate.crt cabundle.crt > fullchain.pem?
Euhh... No. I just copy&pasted the contents in a new file using Notepad++ on my Windows machine. Perhaps I need to look into the encoding that this editor uses, because this happened before I think...

1601729399559.png



For subdomain reverse proxying you will need to add a server block for each subdomain, which can listen on the same port, but require the fqdn for the subdomain as server_name to be different.

I am heading out now and will return later tonight.
Ah. This I should be able to play around with. I wonder why this isn't specified here:



I am heading out now and will return later tonight.
Thank you so much for everything so far. You are truly a hero!
 
I've tried to most simple stuff first. For example I have portainer container running on port 9000 (HTTP) on my NAS (not connected to the macvlan network). In my DSM I set a reverse proxy rule for portainer.mydomain.com , so I can just easily access it via port 443 in the browser. So I tought, this should easily work in this new nginx container.

To test it out, I have this in the nginx.conf:

Code:
location /portainer/
        {
            # Pass header info to the target service
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-Port 443;
            
            proxy_buffering off;

            # Connection upgrade to HTTP1.1
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";

            # The trick of using a variable gives us two advantages:
            #   1. No DNS caching when resolving names. This leverages the Docker DNS round-robin feature among instances of the same service.
            #   2. NGINX starts up without crashing even if the target service is not yet running in the Swarm cluster.
            set $target http://192.168.1.193:9000;
            proxy_pass $target;

            # URLs rewriting rules inside content
            #sub_filter      '/test/gui/'  '/test-gui/';
            #sub_filter_once off;
        }


(192.168.1.193 is the macvlan interface on the host NAS: Using Docker macvlan networks · The Odd Bit )

But all I get is this:
1601745301326.png


I tried to search the nginx config files of DSM itself to see if I can spot inside there if I should change anything with headers or something to configure in the docker nginx.conf. After searching I've finally found it in /var/tmp/nginx/ReverseProxy.tmp:
1601745406065.png


But I don't see anything here that gives me an 'aha' moment. Why does this work, but my nginx.conf in docker doesn't..?
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

  • Question
No need to internally also push it to HTTPS. You can use HTTPS (public) to HTTP (internal, that works for...
Replies
3
Views
2,520
  • Solved
Yes just to close the loop on this for everyone else's benefit (for those who may come across this in the...
Replies
12
Views
16,787
Replies
21
Views
7,070
It's okay, this morning it just came up, so not sure what was happening. I deleted and re-ran the docker...
Replies
2
Views
2,318
Well, that's the reason as you already noticed. So you haven't migrated the @docker content? Do you have...
Replies
5
Views
1,877
This looks interesting and not so inventory dependent... https://github.com/davideshay/groceries
Replies
8
Views
1,204

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top