Collabora/Talk behind reverse-proxy [ok] but internal traffic also routed via haproxy

[saintcore]

I'm coming from this after collabora/talk wasn't working behind haproxy: #1358

As I do ssl-offloading on haproxy, I've ensured that my lan-clients can connect via haproxy (internal dns does resolve to internal ip of haproxy) which works fine. This however means that the same is also true (hub.domain.tld resolves to internal ip) for all ncaio-containers. I've realized this by running the mentioned debug commands from the above link:

# Go into the container
sudo docker exec -it nextcloud-aio-nextcloud bash
# Now inside the container
curl -vvv https://$NC_DOMAIN:443/hosting/discovery
exit

$NC_DOMAIN resolved ofc to the ip of my haproxy-instance. As this was blocked by a firewall, it didn't worked. Once I've allowed https-traffic from ncaio to my haproxy, everything was working fine (including the above debug commands and a quick talk test and also editing a file via collabo). This however means rn traffic between my containers (in this case the high performance backend as this one wasn't reachable according to the nc settings ) which should be internal from what I expect is routed to my haproxy-instance (log from haproxy, the first ip-address from the left you can see is the source ip and 180.115 is my ncaio instance and not a client or so ):

It works but I expect this is definetly not a nice setup and I'm a bit lost here. I tend to think I've got something really wrong from a design perspective. Is there a better approach to ensuring that I can access my ncaio instance from lan and external then via ensuring the domain does resolve to my haproxy instance within my lan ? Pointing it directly to ncaio seems to be no option as I do ssl-offloading as mentioned above.

If my setup isn't clear I could also draw a quick map to show what is going on.

[saintcore]

One thing might worth to mention or ask: What is the "best practices" for the local hostname of my docker-host for ncaio ? Normaly I use some generic names and numbers and not the actual mydomain.tld . Maybe this is related to that fact ? I've seen that the /etc/hosts file of my host does resolve the hostname of localhost to one of the ip's of the ncaio containers. I could imagine that therefore the same is true for the containers itself ? Instead of resolving the mydomain.tld to the container-ip, it resolves the choosen hostname of the docker-host to the container-ip ? (Pure guessing, hadn't a chance to validate that yet)

[szaimen]

Once I've allowed https-traffic from ncaio to my haproxy, everything was working fine (including the above debug commands and a quick talk test and also editing a file via collabo). This however means rn traffic between my containers (in this case the high performance backend as this one wasn't reachable according to the nc settings ) which should be internal from what I expect is routed to my haproxy-instance (log from haproxy, the first ip-address from the left you can see is the source ip and 180.115 is my ncaio instance and not a client or so ):

It works

This is how it is inteded to work so the design seems feasible. It is called Split-Brain-DNS.