Concentrador y radios o malla completa: qué topología VPN encaja con sus sedes

Dos oficinas sucursales hablan entre sí todo el día, y el túnel entre ellas desvía su ruta por un centro de datos de otra región. Cada petición paga ese desvío dos veces, y nadie lo nota hasta que la sincronización de archivos empieza a sentirse mal. Ahí es donde empieza de verdad la pregunta de la topología: no con qué diagrama parece más resistente, sino con qué patrón de tráfico está pagando. Ambos diseños funcionan, y fallan de formas distintas con costes distintos.

Cuente las relaciones entre pares antes que nada

Con N sedes, una malla completa necesita N por N menos uno, dividido entre dos, túneles; un concentrador necesita N. Con cinco sedes son diez frente a cinco, lo que aún suena manejable. Con quince son 105 frente a quince, y la diferencia ya no es aritmética sino de personal.

Cada una de esas relaciones lleva estado del que usted debe ser dueño. En IPsec eso significa una asociación de seguridad, una identidad, una clave o certificado, detección de par muerto y al menos una ruta por cada prefijo remoto. En WireGuard significa una clave pública y un AllowedIPs bloque por par, que sale más barato por par pero llega sin ningún descubrimiento: una sede nueva es un cambio de configuración en cada una de las existentes de todos modos.

Deje que decida la mezcla de tráfico, no el dibujo

Si el tráfico de las sucursales son sobre todo peticiones a un ERP central o a un clúster de archivos, un concentrador no es un compromiso, es la forma correcta: el tráfico ya quería ir allí, y un solo punto de política es más fácil de auditar que una malla de reglas por pares. Una malla se gana su complejidad cuando las sucursales intercambian datos entre sí — replicación entre dos oficinas, voz entre sedes, un recurso CAD compartido que una docena de ingenieros abren todo el día.

Los casos incómodos están en medio, y son la mayoría. Mida antes de discutir en lugar de adivinar a partir de un organigrama.

Lea la tabla como un desempate, no como una regla. Tres de cada cuatro filas en una dirección suelen resolver el diseño; una división significa híbrido, que es con lo que acaban la mayoría de las redes maduras de todos modos.

Hay que decirle al concentrador que reenvíe

Dos túneles de radio a concentrador que funcionan no crean acceso de radio a radio. El concentrador necesita el reenvío IP activado, una ruta a cada red de radio, una regla de cortafuegos que permita el tránsito y el camino de vuelta resuelto; cada radio necesita una ruta para los prefijos de la otra sede. En un concentrador Linux eso es net.ipv4.ip_forward=1 más FORWARD una cadena que no descarte el par en silencio, y en IPsec basado en políticas son selectores de tráfico que listan la subred de radio remota en ambos extremos. En strongSwan, las notas de reenvío cubren la parte del núcleo y del cortafuegos cuando esa es la capa que le falta. Una prueba barata es enviar tráfico de una radio a un servicio de la otra mientras observa los contadores del concentrador; una regla que nunca sube significa que el orden está mal, no la ruta.

La política central también es la parte útil. Se puede permitir que las sucursales lleguen a servicios compartidos sin llegar entre ellas, y esa matriz de acceso merece escribirse de forma explícita. Las rutas que faltan son un mal sustituto de una regla que alguien pueda leer.

Ojo con la versión a medias: la radio A enruta hacia la radio B por el concentrador, el concentrador enruta en ambos sentidos, y el cortafuegos del concentrador permite conexiones nuevas desde A pero no desde B. La primera dirección se prueba bien y la segunda se cuelga, lo que parece un fallo de encaminamiento y no lo es.

Diseñe el fallo, después el camino normal

Un solo concentrador es una dependencia compartida y un cuello de botella de tránsito, y la redundancia es donde los diseños con concentrador suelen salir mal. Dos concentradores significan que cada radio mantiene dos túneles, y el camino de vuelta tiene que concordar con el de ida; cuando no lo hace, un cortafuegos con estado descarta las respuestas y el síntoma es una conexión que se abre y luego muere. Los despliegues grandes lo resuelven con un protocolo de encaminamiento sobre los túneles en lugar de prefijos estáticos, que es más maquinaria pero elimina las conjeturas. Elija lo que elija, escriba el camino de vuelta junto al de ida, porque la mitad de vuelta es la que nadie prueba.

Una malla reparte ese riesgo: que caiga el enlace de una sede no aísla a las demás. También multiplica los lugares donde la selección de camino puede sorprenderle, y las sesiones de aplicación siguen sin sobrevivir a un cambio de camino sin ayuda.

Ninguno de los dos diseños mantiene viva una sesión TCP a través de una conmutación por sí solo. Si la aplicación no puede reconectar, la topología no es su problema.

Elija por coste de cambio y luego verifique las rutas

Empiece por el concentrador, porque es lo más barato en lo que equivocarse, y añada túneles directos para los pares cuyo tráfico lo justifique. Ese híbrido no es una falta de decisión; es el diseño al que la mayoría de las organizaciones convergen en un año. Lo importante es que cada enlace directo tenga una razón declarada y un responsable.

Luego verifique los dos dibujos en lugar de uno. Para el camino normal, traceroute desde cada sede hasta cada prefijo de servicio y confirme que los saltos coinciden con el diagrama. Para el camino de fallo, apague un túnel y repítalo, porque una ruta que solo funciona mientras todo está en marcha no se ha diseñado, solo se ha configurado.

Guarde ambos dibujos con la matriz de acceso, y revíselos cuando se añada una sede; el coste que gestiona es el coste del próximo cambio, no la elegancia de la imagen actual.