Tenemos una configuración en la que tenemos un contenedor acoplable que necesita comunicarse con dispositivos en una VPN (openvpn) a través de ipv6. Esto se hace construyendo un puente entre las redes acoplables y la interfaz tap0 en el host.
Los dispositivos finales envían un mensaje al contenedor acoplable y esperan recibir un mensaje de confirmación. Sin embargo, estos están en subredes diferentes, con el contenedor y el host en la bbbb::/64subred y los dispositivos en la abcd::/64(a modo de ilustración). Hay una puerta de enlace bbbb::abcd:2que enruta el tráfico de una subred a la otra, y el host de la ventana acoplable tiene una configuración de puerta de enlace para esto.
Para ser claro:
bbbb::4001 <--> bbbb::2105 <--> bbbb::abcd:2 <--> abcd::/64
¿Dónde bbbb::4001está la dirección del contenedor? bbbb::2105es la dirección del anfitrión; bbbb::abcd2es la dirección del dispositivo de puerta de enlace; abcd::/64es la subred en la que se encuentran los dispositivos finales.
Usando tsharken el host y la puerta de enlace, observamos lo siguiente:
- El host puede hablar directamente con los dispositivos finales en la subred abcd (verificado con traceroute, podría ver paquetes en el host y la puerta de enlace);
- El contenedor acoplable puede comunicarse con la puerta de enlace (verificado con ping, podría ver paquetes en el host y la puerta de enlace);
- el contenedor acoplableno pudohablar directamente con los dispositivos finales en la subred abcd: pudimos ver los paquetes en el host, de la misma manera que los vimos para la comunicación del host, pero no vimos que llegara nada a la puerta de enlace.
Hemos intentado modificar iptableslas reglas para permitir paquetes reenviados (por ejemplo, estableciendo la política predeterminada de la FORWARDcadena en ACCEPT) pero fue en vano.
No tenemos claro dónde buscar con este problema, porque parece que los paquetes del contenedor acoplable destinados a la subred en la que no se encuentra se descartan.en algún lugaren el host, O tal vez se envíen al lugar equivocado, pero los vemos en la br0interfaz del host, simplemente nunca llegan a la puerta de enlace. Cuando el contenedor acoplable intenta comunicarse con cosas en la misma subred, entonces funciona.
¿Por dónde empiezo a buscar esto?
Respuesta1
El problema tenía que ver con la red de Docker. Teníamos una configuración de red acoplable para usar un puente de red para conectarnos a la VPN. Ese puente se configuró (a través de /etc/network/interfaces.d/br0.cfg) con una dirección de puerta de enlace bbbb::2105y la red acoplable se creó después de la interfaz del puente. Cuando se creó la red de Docker, no se especificó la dirección de la puerta de enlace y Docker la usó de forma predeterminada bbbb::1como dirección de puerta de enlace, que obligó br0a usar. Esa dirección es la misma dirección que el servidor VPN. El resultado fue que los paquetes en realidad no se descartaban en el host, sino que se reenviaban a la tapinterfaz del servidor VPN, y el servidor VPN no tenía las tablas de enrutamiento configuradas de modo que supiera qué hacer con esos paquetes, por lo que efectivamente fueron bloqueados una vez que llegaron al servidor VPN.
Esto quedó claro al usar tshark para monitorear la tapinterfaz del servidor VPN, así como las tapinterfaces en las puertas de enlace y la máquina host de la ventana acoplable. Luego intentamos hacer ping a un dispositivo final desde el interior del contenedor de la ventana acoplable y vimos paquetes en el host de la ventana acoplable y en el servidor VPN, pero no en las puertas de enlace. Si intentamos lo mismo en el host de la ventana acoplable, vimos paquetes en el host de la ventana acoplable y en las puertas de enlace, pero no en el servidor VPN, lo que demuestra que los contenedores de la ventana acoplable estaban configurados para enviar tráfico al servidor VPN en lugar de a las interfaces de red del host. .
El problema se solucionó introduciendo la --gatewayopción en la creación de la red acoplable.
La parte no resuelta de esto espor quéDe repente, esto comenzó a comportarse de esta manera, dado que la configuración ha funcionado desde 2016 y dejó de funcionar aleatoriamente un día de junio de 2022.