Puente TAP aislado entre dos placas mediante OpenVPN

Dos placas de desarrollo necesitan compartir un único segmento Ethernet mientras sus bancos están en edificios distintos. El túnel ya existe y ya transporta Ethernet, así que el trabajo restante parece tres comandos y no lo es. Qué hace el host con una trama puenteada, dónde pertenece la dirección propia del equipo y qué frontera no crea el puente son tres hechos separados, y equivocarse en el segundo es la razón habitual de que un laboratorio funcione de forma intermitente y su acceso de gestión se degrade en silencio. Ninguno de esos tres hechos es visible en un diagrama de topología.

La ruta de abajo supone una conexión TAP autenticada entre dos equipos Linux, un puerto cableado dedicado por banco y una interfaz de gestión que no forma parte del experimento. El orden importa: primero las tramas, después las direcciones, por último la frontera.

Qué mueve realmente el puente

Un puente es un conmutador implementado en software. Aprende qué dirección MAC aparece detrás de qué puerto miembro y reenvía tramas entre miembros sin consultar una tabla de enrutamiento IP. Nada en esa descripción incluye una subred, una puerta de enlace ni una ruta por defecto, por eso habilitar el reenvío IP no produce esta conexión y por eso un ping puede tener éxito mientras otro tráfico sigue fallando. Una placa puede alcanzar a su compañera sin ninguna ruta por defecto configurada, algo que sorprende a quienes esperan que la capa dos se comporte como la capa tres.

Cada equipo aporta un puerto cableado al puente y el dispositivo TAP al mismo puente, así que una trama de una placa entra por el puerto local, se reenvía al dispositivo TAP, cruza el túnel, llega al dispositivo TAP del compañero y se reenvía hacia la placa del compañero. El túnel es un puerto miembro como cualquier otro, y al puente no le consta ni le importa que detrás haya una VPN. Esa simetría es lo que hace fácil razonar sobre el ejemplo: cada lado tiene un puerto orientado al laboratorio y un puerto de túnel, y ninguno es especial.

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

Los nombres idénticos en ambos equipos son nombres locales, no objetos compartidos. Hay un solo camino Ethernet entre los bancos, sin un segundo cable y sin un segundo túnel que cierre un bucle; un puente que ve la misma MAC llegar por dos puertos reenviará encantado en círculos.

Direccione el puente, no sus puertos miembros

La identidad del equipo en el segmento del laboratorio pertenece al dispositivo puente. Los puertos miembros quedan sin numerar, porque un puerto es un miembro de reenvío y una dirección sobre él crearía un segundo propietario competidor del mismo segmento. Esta es la corrección que la mayoría de las recetas hechas a mano hacen mal: direccionan el dispositivo TAP y el puente, y luego se preguntan a cuál de los dos llega realmente el compañero.

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

El compañero usa la misma forma con otra dirección de host, y las placas toman direcciones del mismo rango con la dirección del puente del equipo como su siguiente salto si necesitan uno. Use rangos de documentación hasta que se acuerde el plan, y reserve el rango para que no choque con nada que la oficina ya enrute. Antes de ejecutar cualquier parte, confirme que los puertos miembros no llevan ninguna dirección sobrante, ningún cliente DHCP y ninguna pertenencia a otro puente, y concilie el direccionamiento del dispositivo TAP a través de lo que posea la configuración del túnel para que no restaure una dirección más tarde.

Por qué un puerto dedicado por banco

Un puerto cableado dedicado es lo que evita que el experimento se convierta en un cambio para toda la oficina. La interfaz de gestión lleva SSH, la ruta por defecto y la conexión VPN exterior, y nada de eso pertenece a un puente cuyo propósito es mover tramas de laboratorio.

Conectar un adaptador de gestión pone la LAN de la oficina a una decisión de reenvío de distancia de una placa de desarrollo, y una placa que se porta mal en la capa dos es exactamente el tipo de dispositivo que no quiere en ese segmento. Un adaptador Wi-Fi es peor: puentear una interfaz inalámbrica en modo infraestructura no se comporta como puentear Ethernet, y el fallo resulta confuso en lugar de limpio.

Mantenga el rango del laboratorio fuera de cualquier ámbito DHCP de producción. Si las placas necesitan más adelante direccionamiento dinámico, un único asignador autorizado con un único grupo es la única disposición que sigue siendo predecible; los routers corrientes de dos sedes que responden en el mismo segmento producen direcciones que nadie puede explicar.

La frontera que el puente no crea

Puentear no es enrutar, y tampoco es aislar. Las tramas que cruzan el puente pueden seguir llegando a los ganchos de filtrado del host, según la ruta de bridge-netfilter instalada, así que la política efectiva debe inspeccionarse en lugar de suponerse. Desactivar el cortafuegos porque se perdió una trama cambia un fallo concreto por uno general.

El reenvío IP entre el puente y cada interfaz de gestión o de enlace ascendente debería permanecer desactivado o denegarse explícitamente, y ese es un control separado de la pertenencia al puente. Una placa que elige la dirección de laboratorio del equipo como su puerta de enlace prueba exactamente esto: si el tránsito de gestión tiene éxito, la frontera que pretendía nunca estuvo ahí.

Dos familias más merecen una decisión explícita. El plan de direccionamiento no hace que el puente sea solo IPv4, así que IPv6 y otros EtherTypes necesitan su propio plan o filtro. Y un ping correcto no dice nada sobre si las difusiones de descubrimiento de la placa, los grupos multicast o las tramas jumbo atravesarán el camino, porque son clases de tráfico distintas con valores por defecto distintos.

Por último, transporte y confidencialidad son dos compras distintas. TAP transporta Ethernet; el servicio OpenVPN aporta la protección alrededor. Una superposición VXLAN también transporta Ethernet y no aporta confidencialidad por sí sola, así que sustituir una por otra cambia las propiedades de seguridad incluso cuando el diagrama de topología parece idéntico.

Persistencia y las pruebas que la demuestran

Un comando escrito una vez tras conectarse no es una configuración. Haga persistentes el puente, la pertenencia de puertos y la única dirección de host a través del gestor de red existente del equipo, y ligue la conexión a la aparición del dispositivo TAP para que una reconexión no deje un puente con un miembro desaparecido.

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

Después pruebe qué necesitan realmente las placas en ambos sentidos, reconecte el túnel y reinicie un equipo según el plan de recuperación aprobado. Confirme tres cosas después: el acceso de gestión sigue funcionando de forma independiente, no aparece ninguna dirección de laboratorio duplicada y ninguna interfaz de producción inesperada se ha unido al puente. Esa combinación es la prueba de que el experimento se quedó dentro de su banco.