Какова связь между docker0 и eth0?

Question

Я знаю, что докеры по умолчанию создают виртуальный мост docker0, и вся контейнерная сеть связана с docker0.

Как показано выше:

• контейнер eth0 в паре с vethXXX
• vethXXX связана с docker0 же, как машина связана с переключения

Но что такое соотношение между docker0 и хост eth0? Более конкретно:

1. Когда пакет поступает из контейнера в docker0, как он знает, что будет перенаправлен на eth0, а затем с внешним миром?
2. Когда внешний пакет поступает в eth0, почему он пересылается в docker0, тогда контейнер? вместо того, чтобы обрабатывать его или бросать?

Вопрос 2 может быть немного запутанным, я буду держать его там и объяснил немного больше:

• Это возврат пакета, который визируется контейнера (в вопросе 1): с внешней стороны не знает контейнерную сеть, пакет отправляется на хост eth0. Как он отправляется в контейнер? Я имею в виду, должно быть место для хранения информации, как я могу ее проверить?

Заранее благодарен!

---

После прочтения ответа и официальные сетевые статьи, я нахожу следующую диаграмму более точной, что docker0 и eth0 не имеет прямой связи, вместо этого они не могут передавать пакеты:

http://dockerone.com/uploads/article/20150527/e84946a8e9df0ac6d109c35786ac4833.png

Answer 1

Существует нет прямая связь между мостом по умолчанию docker0 и узлами ethernet-устройств. Если вы используете опцию --net=host для контейнера, то сетевой стек хоста и контейнеров будет связан.

Когда пакет перетекает из контейнера в docker0, как он узнает, что он будет перенаправлен на eth0, а затем во внешний мир?

Мост имеет .1 адрес, назначенный ему.

$ ip address show dev docker0 
8: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:03:47:33:c1 brd ff:ff:ff:ff:ff:ff 
    inet 172.17.0.1/16 scope global docker0 
     valid_lft forever preferred_lft forever 

назначаются контейнеры интерфейс Veth, прикрепленный к docker0.

$ bridge link 
10: vethcece7e5 state UP @(null): <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0 state forwarding priority 32 cost 2 

Контейнеры по сети по умолчанию получить .1 адрес в качестве маршрута по умолчанию.

$ docker run busybox ip route show 
default via 172.17.0.1 dev eth0 
172.17.0.0/16 dev eth0 src 172.17.0.3 

Docker использует NAT Маскарад для исходящего трафика там, и он будет следовать стандартной исходящей маршрутизации на хосте, который может или не может по умолчанию eth0.

$ iptables -t nat -vnL POSTROUTING 
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target  prot opt in  out  source    destination   
    0  0 MASQUERADE all -- *  !docker0 172.17.0.0/16  0.0.0.0/0 

iptables обрабатывает отслеживание трафика и обратный трафик.

Когда внешний пакет поступает в eth0, почему он перенаправляется в docker0, тогда контейнер? вместо того, чтобы обрабатывать его или бросать?

Если вы говорите об обратном исходящем трафике, см. Iptables выше.

Если вы имеете в виду новый входящий трафик, пакеты не пересылаются в контейнер по умолчанию. Стандартный способ достичь этого - установить a port mapping. Docker запускает демон, который слушает хост на порту X и переходит в контейнер на порт Y.

Я не уверен, почему NAT не использовался для входящего трафика. Я столкнулся с некоторыми проблемами, пытаясь сопоставить большое количество портов в контейнерах, что привело к тому, что mapping real world interfaces полностью вместили в контейнеры.

Answer 2

Вы можете определить отношение по сетевому интерфейсу iflink от контейнера и ifindex на главной машине.

Получить iflink из контейнера:

$ docker exec ID cat /sys/class/net/eth0/iflink 

17253 

Затем найдите этот ifindex среди интерфейсов на хост-машине:

$ grep -l 17253 /sys/class/net/veth*/ifindex 

/sys/class/net/veth02455a1/ifindex