I've probably found a solution. While tinkering with "route", I saw that the docker bridges get random IPs from an unknown range. The F2-221 has 2 physical NICs - I have only one of them (eth0) running. eth1 has - despite being disabled - an IP from the subnet 169.254.0.0 assigned!
Take a look here:
Code: Select all
# ip a
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 6c:bf:b5:01:5f:56 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.36/24 brd 192.168.178.255 scope global eth0
11: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 6c:bf:b5:01:5f:57 brd ff:ff:ff:ff:ff:ff
inet 169.254.253.106/16 brd 169.254.255.255 scope global eth1
valid_lft forever preferred_lft forever
# docker network create newbridge
# docker network ls
NETWORK ID NAME DRIVER SCOPE
c9ad54e42073 bridge bridge local
83ec6ae8033b host host local
7528eb0f37de newbridge bridge local
# ip addr show br-7528eb0f37de
37: br-7528eb0f37de: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:f7:66:65:c0 brd ff:ff:ff:ff:ff:ff
inet 169.254.251.231/16 brd 169.254.255.255 scope global br-7528eb0f37de
valid_lft forever preferred_lft forever
My LAN runs on eth0 192.168.178.0. The disabled eth1 interface has an IP inside 169.0.0.0. The bridge, that docker has created, got a correct route, but a
wrong ip (169.254.251.231) on its interface. Adding the docker virtual ip to the interface, the container can connect to the internet:
Code: Select all
~~~ inside debian container on newbridge ~~~
root@9ad61a932cad:/# ping 172.19.0.1
PING 172.19.0.1 (172.19.0.1) 56(84) bytes of data.
^C
--- 172.19.0.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 64ms
~~~ on the NAS ~~~
# ip addr add 172.19.0.1/24 dev br-7528eb0f37de
~~~ inside debian container again ~~~
root@9ad61a932cad:/# ping 172.19.0.1
PING 172.19.0.1 (172.19.0.1) 56(84) bytes of data.
64 bytes from 172.19.0.1: icmp_seq=1 ttl=64 time=0.209 ms
64 bytes from 172.19.0.1: icmp_seq=2 ttl=64 time=0.133 ms
^C
--- 172.19.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 18ms
rtt min/avg/max/mdev = 0.133/0.171/0.209/0.038 ms
root@9ad61a932cad:/# ping google.com
PING google.com (216.58.212.142) 56(84) bytes of data.
64 bytes from ams15s21-in-f14.1e100.net (216.58.212.142): icmp_seq=1 ttl=118 time=24.4 ms
64 bytes from ams15s21-in-f14.1e100.net (216.58.212.142): icmp_seq=2 ttl=118 time=33.9 ms
64 bytes from ams15s21-in-f14.1e100.net (216.58.212.142): icmp_seq=3 ttl=118 time=22.6 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 22.625/26.951/33.854/4.933 ms
I guess that any part of the bridge creation takes a wrong IP or getting confused by eth1. I'm not sure on this one, as I have no knowledge about the underlying functions. But apparently the connection works now.
I'll try to setup my complete installation with Traefik etc. tomorrow and keep y'all updated!