VPN enrutada o LAN puenteada para un enlace entre sucursal y laboratorio

Hay dos formas de hacer que una sucursal llegue a un laboratorio doméstico, y la diferencia no es un ajuste. Puedes enrutar entre prefijos distintos, de modo que cada sede conserve su propio dominio de difusión, o puedes puentear las dos LAN en una sola, de modo que las difusiones y el tráfico de descubrimiento se comporten como si todos estuvieran en la misma sala. El enrutamiento es el diseño que sobrevive al contacto con una red real. El puenteo es el diseño que hace fácil la primera semana e interesante la primera caída. La comparación siguiente trata de lo que cada uno te da y lo que cuesta, y después de cómo hacer comprobable la versión enrutada.

Dos formas de conectar, un compromiso evidente

Un enlace enrutado trata el laboratorio doméstico como una red remota con su propio direccionamiento. La sucursal pide el prefijo del laboratorio, el túnel transporta esos paquetes y la puerta de enlace del laboratorio responde desde su propia subred. Nada de la tabla ARP de la sucursal cambia, y nada del ámbito DHCP del laboratorio llega a la sucursal.

Un enlace puenteado extiende un solo dominio de capa 2 por ambas sedes. Los protocolos de descubrimiento funcionan, los dispositivos aparecen solos, y cada difusión, cada solicitud ARP y cada paquete multicast es ahora un candidato a cruzar el túnel, es decir, una gran cantidad de tráfico transportada por protocolos diseñados para un segmento local y no para una WAN con otra MTU y un tiempo de ida y vuelta variable.

Lo que te da el enrutamiento

El primer beneficio es el radio de daño. Un bucle, un servidor DHCP no deseado o una inundación de difusiones se queda en la sede que lo produjo, porque un enrutador no reenvía difusiones. El segundo es la claridad del direccionamiento: el prefijo de la sucursal y el del laboratorio son distintos, así que el destino de un paquete te dice qué sede debe responder, y una regla de cortafuegos puede decir «sucursal a subred del laboratorio» en lugar de «cualquier sitio a cualquier sitio».

El tercero es que encaja con lo que el túnel transporta de verdad. Una política IPsec es un par de prefijos, y la ruta de reenvío en cada lado es enrutamiento IP corriente con el reenvío activado en la puerta de enlace:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

Lo que cedes es el descubrimiento por difusión. Es una pérdida real, y debe reemplazarse a propósito en lugar de sortearse puenteando todo.

Lo que cuesta el puenteo

El puenteo tiene que llevar tramas de capa 2 por un túnel, lo que implica una encapsulación como GRE o VXLAN sobre IPsec en vez de un túnel simple basado en políticas. Una vez que existe, las dos sedes comparten un dominio de fallo. El árbol de expansión ve el túnel como un enlace, el tráfico de difusión consume ancho de banda del túnel, y cualquier dispositivo que supone un segmento de baja latencia se comporta mal de formas difíciles de atribuir desde cualquiera de los dos extremos.

También elimina la comprobación de direccionamiento que te mantiene honesto. Con un prefijo plano, una dirección duplicada no es un error de enrutamiento sino dos hosts que se roban el tráfico en silencio, y los prefijos solapados entre una sucursal y un laboratorio son habituales en montajes de laboratorio doméstico, así que el puenteo no resuelve ese conflicto; lo reparte.

El argumento de seguridad es el que suele decidirlo. Un puente extiende el segmento en el que operan los protocolos de enlace local, así que un dispositivo de la sucursal puede hablar con dispositivos del laboratorio que nunca debieron ser accesibles desde fuera. Si el laboratorio tiene un hipervisor, una consola de almacenamiento y una interfaz de gestión en la misma red plana, ahora eso es un solo segmento junto con la sucursal.

Nombres sin difusión

La razón por la que la gente puentea suele ser el descubrimiento: una impresora, un reproductor multimedia o un host del laboratorio que nunca aparece en una lista. La respuesta enrutada es un servicio de nombres. Publica los hosts del laboratorio en una zona que el resolutor de la sucursal pueda alcanzar, y luego deja que los usuarios se conecten por nombre en lugar de escanear la red. Eso es más trabajo al principio y bastante menos trabajo en cada cambio futuro.

El descubrimiento multicast es el caso más difícil, y merece precisión. Protocolos como mDNS usan multicast de enlace local, que los enrutadores no reenvían de forma predeterminada, así que un host del laboratorio ausente de una lista de descubrimiento puede seguir siendo accesible en su dirección documentada. Si un servicio concreto exige de verdad multicast, planifica ese solo protocolo, con un reflector o una regla de reenvío dirigida, en lugar de puentear toda la LAN como reparación general.

Un reflector tampoco es una victoria gratis. Importa el mismo tráfico charlatán que intentabas evitar, un servicio cada vez, y necesita un dueño que note cuándo un dispositivo empieza a anunciar más que antes. Elígelo servicio por servicio, y escribe por qué. Anota qué servicio lo necesitaba y qué anuncia, porque una actualización de firmware puede cambiar esa lista sin avisar a nadie.

Haz comprobable el diseño enrutado

Elige un objetivo, por ejemplo una interfaz web del laboratorio en su propia subred de servidores, y demuéstralo en ambos sentidos. Desde un host de la sucursal, confirma la dirección y el servicio a la escucha en local, luego conéctate por el túnel y repite. Un túnel que está levantado demuestra que las puertas de enlace se ponen de acuerdo; no demuestra nada sobre el cortafuegos del host ni sobre la ruta de retorno.

La puerta de enlace normal del laboratorio necesita una ruta de vuelta al prefijo de la sucursal, salvo que el diseño traduzca la fuente a propósito, y el cortafuegos del propio servidor tiene que aceptar el rango remoto permitido. Ninguna de las dos cosas la configura un túnel correcto. Las notas de reenvío de strongSwan describen la ruta de los paquetes que debe funcionar en cada lado.

Después prueba también un destino denegado. Un usuario de la sucursal que necesita una aplicación no necesita la consola del hipervisor, y la única manera de saber que la política es real es probar justo lo que debería rechazar. Anota los prefijos, la dependencia del resolutor y los resultados de las pruebas, y un cambio futuro en cualquiera de las dos sedes se puede revisar en minutos en lugar de reconstruirse de memoria.