![¿Cómo configurar el puente de Linux dentro de un contenedor?](https://rvso.com/image/1520686/%C2%BFC%C3%B3mo%20configurar%20el%20puente%20de%20Linux%20dentro%20de%20un%20contenedor%3F.png)
Estoy trabajando dentro de un contenedor, intentando demostrar el puente de Linux y la conexión de Capa 2.
Comencé un nuevo contenedor:
host$ docker run -it --rm --name c1 --privileged networking sh
En el contenedor utilicé lo siguiente para crear la interfaz puente y la interfaz de toque
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
El último comando ping no funciona. Qué estoy haciendo mal ? ¿Es la interfaz tap la correcta para usar? ¿Cómo puedo mostrar la conexión de capa 2 en un contenedor con puente Linux?
siguiente respuesta de @grawity, intenté lo siguiente:
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
hacer ping a todas las interfaces funciona
/ # 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
Tanto ping como arping no funcionan de veth2 a eth0.
ping -I veth2 -c1 172.17.0.2
salida de enlace 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
e ip una salida
/ # 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 tiene lo siguiente
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
¿Qué me falta? qué es 6e2b9b27d81b
?
Respuesta1
Primero: su interfaz no tiene una dirección IP configurada, por lo que realmente no puede enviar ni recibir paquetes IP a través de ella sin tener una dirección. ( ping
utiliza ICMP, un protocolo IP).
Segundo: así no es como funcionan las interfaces tap: no "reflejarán" los ping
paquetes nuevamente en el puente; en lugar de eso, esperan estar conectados a unprograma, por ejemplo, OpenVPN u otro software VPN.
Por lo tanto, su enfoque funcionaría si intentara, por ejemplo, configurar OpenVPN que esté conectado a la red del host (compartiendo una única subred). Pero si sólo quiere ver cómo funcionan los puentes de Linux, tendrá más suerte con veth
las interfaces.
Y si lo único que desea es una conexión L2 a la LAN exterior, entonces está creando el puente en el lugar equivocado; estas cosas generalmente se hacen en elanfitrión, no en un contenedor.
Piense en una interfaz de red como si tuviera dos extremos: el extremo 'host' se muestra en el sistema operativo y lo utiliza todo el software; el otro extremo está conectado a la red real (por ejemplo, un puerto Ethernet físico). Si los paquetes entran por un extremo, pasan por elotrofin. (Por supuesto, los puentes pueden tener varios puertos, no sólo dos, pero se aplica el mismo principio general).
Cuando puenteas una interfaz, el puente se hace cargo de laanfitriónlado de esa interfaz, por lo que solo ve los paquetes que vinierondela red. Pero si usas ping -I eth0
o ping -I tap0
, estás evitando el puente y enviando todo hacia la red real.
ping ──› [eth0 ──› NIC] ──› network
ping ──› [tap0 ──› VPN software] ──› ???
┌─› [eth0 ──› NIC] ──› network
ping ──› br0 ──┤
└─› [tap0 ──› VPN software] ──› ???
∧
ping -I tap0 ───┘
Entonces, en su situación, la interfaz tap es inútil: todos los paquetes que intente enviar a través de ella simplemente serán descartados, ya que no hay ningún programa adjunto en el otro extremo. (Si marca, ip link
probablemente lo verá con la NO-CARRIER
bandera).
En su lugar, podría utilizar, por ejemplo, una veth
interfaz (del mismo tipo que suelen utilizar los contenedores): siempre se crean en pares conectados entre sí. Entonces, si le indica ping
que envíe paquetes a través de veth0
, retrocederán y pasarán por el lado del host de veth1
, donde el puente puede recibirlos y reenviarlos a través de eth0 si es necesario.
┌── [eth0 ──› NIC] ──› network
br0 ──┤
└── [veth1 ‹───› veth0] ‹── ping -I veth0