@one-eyed-king
I can use telnet from any container to any container by NAS-IP:container port.
still about the container (exposed) public port (not the internal container port). Sorry for the misunderstanding. No need to worry about my mental health (need to explain to my doctor)
.
Sometimes is better to use paper and pencil or something like that.
This is a simplification of my point of view on the Netfilter packet flow + Nginx + Docker. I can't find any scheme on the internet; take it as my draft of the big picture.
However, it will be helpful for others to attach it (after tunning) to this resource.
Note: Yes, I understand, that the architecture is more complex. Again - this is drafted for the simplification purpose.
1. When config: server.ReverseProxy.conf is right (reconstructed from a scratch, never manually tuned)
and
2. When config: nginx.conf is right (it is working, include logging/SSL termination/... )
Note: in my case is the /etc/nginx/conf.d/main.conf empty .... is it OK?
and
3. NAS firewall is OFF (avoid possible wrong IPTABLES rules, just to be sure)
then
there is just a single possible wrong point (environment):
the Ngnix communication with the NAT definitions in IPTABLES for the docker networks (just for cases when RP was used).
No errors in Nginx Access/Error log ---> so, seems to be the Nginx is convinced that the RP is sending packets to the right destination/port.
Because all of the container targets defined by RP records are routed to a single destination ---> localhost
SM-https-port
The <DSM-https-port> is the port defined for DSM UI.
But in the
there isn't such rule = reason why all of the containers are accessible when no RP is used.
Conclusion
It doesn't matter what is defined in the RP config (location/proxy_pass):
- localhost:public-container-port
or
- IP address of the NAS interface (both of them in my case), instead of the localhost def. (still it is landing to the localhost)
or
- http/https as destination protocol
or
- even ... I know, I know (just for a test purpose) IP address of the container (based on the Docker bridge interface), , instead of the localhost def.
All of the containers are working and accessible from LAN through NAS interfaces and their public ports.
Also accessible from WAN by direct Router NAT to NAS interfaces and their public ports (out od the RP).
There is valid SSL/TLS test of my wildcard cert and ngnix.cof + server.ReverseProxy.conf contains path to its cert/key. Then no possible SSL termination damage. As was written the same cert is working with the same SSL termination directly (out of the RP).