Puentear una sede porque una herramienta insiste en que debe estar en la misma red, y tres semanas después estás leyendo registros de conmutadores a las dos de la mañana. Ese tipo de intuición decide demasiados enlaces Ethernet sobre IP. Aquí solo importa de verdad una diferencia: si viajan tramas completas de extremo a extremo o solo paquetes IP. Ejecuta las cinco comprobaciones siguientes en orden y detente en la primera que falle.

Comprueba qué pone realmente la aplicación en el cable

Antes de que ningún nombre de producto entre en la conversación, captura un minuto del tráfico que tiene que cruzar el enlace: tcpdump -i eth0 -nn -e 'not ip'. El indicador -e imprime la cabecera de la capa de enlace, que es exactamente la parte que descarta un túnel enrutado. Si la captura queda vacía, tu aplicación habla IP y un túnel L3 la transporta sin cambios. Si aparecen tramas, anota el EtherType, porque 0x0806 es ARP, 0x88cc es LLDP, y un valor de fabricante suele significar un protocolo de descubrimiento sin alternativa IP. Es el punto en el que una tun interfaz normal deja de ser suficiente.

Repite la captura también en el extremo remoto. Una trama que solo existe dentro del conmutador virtual de un host no es motivo para estirar un dominio de difusión por una WAN.

Comprueba si el descubrimiento tiene que cruzar el enlace

Un túnel enrutado no tiene ningún segmento compartido, así que nada dirigido a un grupo llega al otro extremo. ARP, las difusiones DHCP, mDNS en 224.0.0.251, SSDP y las consultas de nombres NetBIOS suponen todos un enlace que varios hosts oyen a la vez.

Pregunta de cuáles de ellos depende realmente la aplicación y si ya existe un proxy para ello. El relé DHCP, la reflexión mDNS y las entradas ARP estáticas eliminan cada uno una dependencia, y cada uno es otro servicio que ejecutar y vigilar. Cuando quedan dos o tres, puentear es la respuesta honesta.

Comprueba cuánto te cuesta la cabecera extra

Las tramas necesitan un sitio donde vivir, así que todo lo que envías lleva una segunda pila de cabeceras alrededor. En una superposición VXLAN eso significa una cabecera IP exterior, una cabecera UDP y una cabecera VXLAN de 8 bytes, lo que empuja una carga completa de 1,500 bytes más allá de la MTU de ruta de un enlace de internet normal de 1,500 bytes. OpenVPN en modo tap añade su propia sobrecarga en la misma dirección. Sin una MTU más baja en el lado interno obtienes un enlace que responde a los ping y se atasca en la primera transferencia grande.

La factura no se detiene en los bytes de cabecera. La difusión y el multicast que un conmutador resuelve en hardware ahora viajan por la WAN, y cada sede puenteada hereda el mismo plan de direcciones, el mismo ámbito DHCP y el mismo comportamiento con direcciones duplicadas. Eso hace el enlace bastante más difícil de auditar que un grupo enrutado con un prefijo por sede.

Haz las cuentas antes de elegir. Un segmento ocupado replicado a tres sedes puede mover más tráfico de difusión que las transferencias de archivos para las que se construyó.

Comprueba qué tipo de VPN L2 te están ofreciendo

El propio término es ambiguo, y la ambigüedad decide quién transporta tu tráfico. A veces describe la carga: tramas Ethernet dentro de IP, enviadas por internet como cualquier otro túnel, como hacen VXLAN, ZeroTier y el modo tap de OpenVPN. A veces describe un servicio comprado: un circuito Ethernet de operador o un pseudocable MPLS que une dos sedes dentro de una sola red de proveedor.

Ambos te dan un segmento, así que la aplicación no puede distinguirlos, pero la diferencia operativa es grande. Una superposición te deja la responsabilidad de la MTU, el cifrado y la ruta subyacente. Un servicio de operador se hace cargo de eso y lo cobra, y no enrutará tus tramas por internet público en absoluto. Cuál quieres depende de si las dos sedes comparten operador o solo comparten empresa.

Comprueba la solución más barata antes de puentear

La mayoría de las peticiones de un enlace puenteado vienen de una sola consulta rota, no de un protocolo que realmente necesite tramas. Pasa primero el resolutor y el dominio de búsqueda por el túnel enrutado: dhcp-option DNS 10.8.0.1 junto con dhcp-option DOMAIN internal.example en una configuración de servidor OpenVPN resuelve una cantidad sorprendente de ellas. Un reenviador local en el extremo remoto hace el mismo trabajo sin mover ningún tráfico de difusión.

Si una herramienta antigua sigue fallando, pon esa herramienta detrás de un proxy o un host de salto en el segmento de destino. Un solo reenviador TCP es más barato de operar que una WAN puenteada.

Cierra la decisión en orden: ¿lleva el tráfico un EtherType que no es IP, tiene el descubrimiento que cruzar, puede la MTU absorber las cabeceras extra, hay realmente disponible un circuito de proveedor, y falló la solución enrutada por un motivo que puedas nombrar? Un no en cualquier paso termina el debate a favor del túnel que ya tienes. Archiva la captura y la lista de EtherType con el registro de cambios, porque la siguiente persona hará la misma pregunta y no querrá repetir la medición.

Artículos relacionados