TerraMaster Forum

Yes, it's working now. Traefik is exposed to :80 and :443 and receives the request. It'll forward the request to other containers based on the domain name, that have been activated by docker-compose labels.

So the structure is:
- disable jumpd in /etc/nasips.ini to deactivate the redirect from :80 / :443 to the TOS admin. "service S99nasips restart".
- create a docker bridge called web
- install traefik by docker-compose having: - start traefik by "docker-compose up -d"
- get network info: "docker network inspect web"
- check "ip route list" and "ip a" for the created bridge-interface
- adjust the route for the bridge-interface to the ip range of the "web" bridge
- add the gateway ip to the bridge-interface

For a quick test you should be able to ping the traefik ip from your host. If docker created a bridge inside 172.18.0.0/16 you should be able to ping 172.18.0.2 from the host/NAS.

After that I can add any docker container to the network and interconnect it with Traefik by the docker-compose labels. So after that I've installed nextcloud via docker-compose. Traefik gets a notification and pulls a lets-encrypt cert. As soon as the nextcloud setup is done, the container is reachable by entering the domain name in browser.

Meh. Post editing ended again.

What I've forgotten to mention is, that the mariadb container for nextclound is running inside its own internal network. It's specified in the docker-compose.yml file of nextcloud:
The final setup looks like the sketch in my previous posts.

Good!

If anyone is interested in the final setup, I've written two tutorials about it:

Docker network + Traefik:
https://blog.mukmuk.eu/2021/docker-reve ... on-f2-221/

Nextcloud:
https://blog.mukmuk.eu/2021/installing- ... on-f2-221/

mukmuk wrote: ↑13 Jan 2021, 16:39 I'm aware of the 169-range. As soon as the container starts, the bridge gets routed over this subnet. But only when the first container starts...

Code: Select all

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

# docker network create heymatt
acfe7629b9c70b38429a8ab972c2cc53d520c17c432130f7740e1fb5b9e1a799
# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
c9ad54e42073        bridge              bridge              local
acfe7629b9c7        heymatt             bridge              local
83ec6ae8033b        host                host                local
61ee2316d6d1        none                null                local

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-acfe7629b9c7
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

--- fine up to here ---

second shell: # docker run --rm -it --name debian4 --network heymatt debian:buster

first shell: # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 br-acfe7629b9c7
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 vethaf32b60
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

# ip route list
default via 192.168.178.1 dev eth0 src 192.168.178.36 
169.254.0.0/16 dev br-acfe7629b9c7 proto kernel scope link src 169.254.251.125 
169.254.0.0/16 dev vethaf32b60 proto kernel scope link src 169.254.251.81 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.178.0/24 dev eth0 scope link src 192.168.178.36

Modifying the route as well as the interface of br-acfe7629b9c7 to the docker assigned subnet 172.18.0.0/16 seem to work fine.

I've the same problem, how have you fixed It?
Thanks!

nygage wrote: ↑31 Jan 2021, 23:47 I've the same problem, how have you fixed It?
Thanks!

Hey nygage,

yup, I've solved it. You can find more infos in my blog post under: https://blog.mukmuk.eu/2021/docker-reve ... on-f2-221/

The interesting part comes at "Changing the network interface and routes". As well as here: https://blog.mukmuk.eu/2021/docker-0-me-1/

I saw it thanks! But after reboot, how do you automate it?

I haven't set up any automation for now. Just form the theory of it, it should be enough having a service after reboot, which sets the route + ip to the interface. If I find the time in the next few days, I might post a tutorial for it.

Hello guys,

I find it very inconvenient to change jumpd to NO every reboot, so I created a script to fully automate disabling the nasips.ini / setting jumpd = YES to NO after reboot, follow steps below:

1. SSH to TNAS as root
2. cd /etc
3. cd crontabs
4. vi root
5. add the following to the crontabs config:
@reboot cd /etc ; sed -i '2s/^.*$/jumpd = NO/' nasips.ini ; service S99nasips restart
6. press ESC then :wq

This should disable redirect after every reboot! Reboot TNAS and check if it worked.

This is also very important to deactivate because when jumpd is set to YES, it makes a redirection to the local nas even though I only talk to the CPE router with a Port on my nas. I do not see any use of this redirect function!