2

Я работаю внутри контейнера, пытаюсь продемонстрировать Linux-мост и соединение 2-го уровня.

Я начал новый контейнер: 

host$ docker run -it --rm --name c1 --privileged networking sh

На контейнере я использовал следующее, чтобы создать интерфейс моста и нажать интерфейс 

c1$ ip link add br0 type bridge
c1$ ip link set eth0 master br0
c1$ ip tuntap add tap0 mode tap
c1$ ip link set tap0 master br0
c1$ ip link set tap0 up
c1$ ip link set br0 up
c1$ ping -I tap0 172.17.0.2

Последняя команда ping не работает. Что я делаю неправильно ? интерфейс тапа правильный для использования? Как я могу показать соединение уровня 2 на контейнере с linux bridge?

Следуя ответу @grawity, я попробовал следующее: 

ip link add dev veth1 type veth peer name veth2
ip link set dev veth1 up
ip link add br0 type bridge
ip link set veth1 master br0
ip link set eth0 master br0
ip link set br0 up
ip link set veth1 up
ip link set veth2 up
ip addr add 10.0.0.3/24 dev veth1
ip addr add 10.0.0.4/24 dev veth2
ip addr add 10.0.0.2/24 dev br0


/ # brctl show
bridge name bridge id       STP enabled interfaces
br0     8000.0242ac110002   no      veth1
                                    eth0

пинг до всех интерфейсов работает

/ # ping -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: seq=0 ttl=64 time=0.068 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.068/0.068/0.068 ms
/ # ping -c1 10.0.0.3
PING 10.0.0.3 (10.0.0.3): 56 data bytes
64 bytes from 10.0.0.3: seq=0 ttl=64 time=0.072 ms

--- 10.0.0.3 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.072/0.072/0.072 ms
/ # ping -c1 10.0.0.4
PING 10.0.0.4 (10.0.0.4): 56 data bytes
64 bytes from 10.0.0.4: seq=0 ttl=64 time=0.095 ms

--- 10.0.0.4 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.095/0.095/0.095 ms

и пинг и арпинг не работают с veth2 до eth0. 

ping -I veth2 -c1 172.17.0.2

выход ip-ссылки

10: veth2@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000\    link/ether f2:8e:e4:f7:fc:7c brd ff:ff:ff:ff:ff:ff
11: veth1@veth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT group default qlen 1000\    link/ether 1a:3a:26:02:8a:a1 brd ff:ff:ff:ff:ff:ff
12: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000\    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
21: eth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT group default \    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0

и ip выход

/ # ip -o a
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
10: veth2    inet 10.0.0.4/24 scope global veth2\       valid_lft forever preferred_lft forever
10: veth2    inet6 fe80::f08e:e4ff:fef7:fc7c/64 scope link \       valid_lft forever preferred_lft forever
11: veth1    inet 10.0.0.3/24 scope global veth1\       valid_lft forever preferred_lft forever
11: veth1    inet6 fe80::183a:26ff:fe02:8aa1/64 scope link \       valid_lft forever preferred_lft forever
12: br0    inet 10.0.0.2/24 scope global br0\       valid_lft forever preferred_lft forever
12: br0    inet6 fe80::42:acff:fe11:2/64 scope link \       valid_lft forever preferred_lft forever
21: eth0    inet 172.17.0.2/16 scope global eth0\       valid_lft forever preferred_lft forever
21: eth0    inet6 fe80::42:acff:fe11:2/64 scope link \       valid_lft forever preferred_lft forever

tcpdump имеет следующее 

09:29:31.253321 ARP, Request who-has 6e2b9b27d81b (Broadcast) tell 10.0.0.4, length 28
09:29:31.253509 ARP, Request who-has 172.17.0.1 tell 6e2b9b27d81b, length 28
09:29:31.253541 ARP, Reply 172.17.0.1 is-at 02:42:be:d6:a7:81 (oui Unknown), length 28
09:29:31.253541 ARP, Reply 172.17.0.1 is-at 02:42:be:d6:a7:81 (oui Unknown), length 28
09:29:36.263281 ARP, Request who-has 172.17.0.1 tell 6e2b9b27d81b, length 28
09:29:36.263313 ARP, Reply 172.17.0.1 is-at 02:42:be:d6:a7:81 (oui Unknown), length 28
09:29:36.263313 ARP, Reply 172.17.0.1 is-at 02:42:be:d6:a7:81 (oui Unknown), length 28
09:29:36.268142 ARP, Request who-has 6e2b9b27d81b (Broadcast) tell 10.0.0.4, length 28
09:29:41.284187 ARP, Request who-has 6e2b9b27d81b (Broadcast) tell 10.0.0.4, length 28
09:29:41.284196 ARP, Request who-has 6e2b9b27d81b (Broadcast) tell 10.0.0.4, length 28

Что мне не хватает? что такое 6e2b9b27d81b ?

|источник

1 ответ1

1

Во-первых: у вашего интерфейса не настроен IP-адрес, поэтому вы не можете отправлять и получать IP-пакеты через него, не имея адреса. (ping использует ICMP, протокол IP.)

Второе: это не то, как работают интерфейсы отводов - они не будут "отражать" ping пакеты обратно в мост; вместо этого они ожидают подключения к программе, например, OpenVPN или другому программному обеспечению VPN.

Таким образом, ваш подход сработает, если вы попытаетесь, например, настроить OpenVPN, который соединен с хост-сетью (разделяя одну подсеть). Но если вы просто хотите посмотреть, как работают мосты Linux, вам повезет больше с интерфейсами veth .

И если все, что вам нужно, это подключение L2 к внешней локальной сети, то вы создаете мост не в том месте - такие вещи обычно выполняются на хосте, а не в контейнере.

Представьте, что сетевой интерфейс имеет два конца: конец «хоста» отображается в ОС и используется всем программным обеспечением; другой конец подключен к фактической сети (например, физический порт Ethernet). Если пакеты приходят через один конец, они проходят через другой конец. (Разумеется, мосты могут иметь несколько портов, а не только два, но применяется один и тот же общий принцип.)

Когда вы соединяете интерфейс, мост переходит на сторону хоста этого интерфейса, поэтому он видит только пакеты, пришедшие из сети. Но если вы используете ping -I eth0 или ping -I tap0 , вы обходите мост и отправляете все в реальную сеть.

ping ──› [eth0 ──› NIC] ──› network

ping ──› [tap0 ──› VPN software] ──› ???

               ┌─› [eth0 ──› NIC] ──› network
ping ──› br0 ──┤
               └─› [tap0 ──› VPN software] ──› ???
                     ∧
     ping -I tap0 ───┘

Таким образом, в вашей ситуации интерфейс крана бесполезен - все пакеты, которые вы пытаетесь отправить через него, просто отбрасываются, так как на другом конце нет никакой программы. (Если вы проверите ip link вы, вероятно, увидите ее с флагом NO-CARRIER .)

Вместо этого вы можете использовать, например, интерфейс veth (того же типа, который часто используют контейнеры) - они всегда создаются парами, соединенными друг с другом. Поэтому, если вы скажете ping отправлять пакеты через veth0 , они будут возвращаться назад и проходить через сторону хоста veth1 , где мост сможет их принимать и, если необходимо, пересылать через eth0.

      ┌── [eth0 ──› NIC] ──› network
br0 ──┤
      └── [veth1 ‹───› veth0] ‹── ping -I veth0
|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .