Escale las sesiones VPN por rol y luego compruebe el margen de fallo

Añade una segunda puerta de enlace, la consola muestra dos miembros sanos y el techo de sesiones apenas se mueve, porque nada dijo a los clientes cómo llegar al nuevo equipo. Escalar un servicio VPN son dos decisiones en secuencia: qué mecanismo distribuye clientes para este tipo de conexión y cuánta capacidad queda tras la peor pérdida individual. Si las tomas en el orden inverso, obtienes un diseño que parece redundante y falla justo cuando hace falta. Empieza por la consola y luego haz la aritmética.

Encaja el mecanismo con el tipo de sesión

Los usuarios remotos, los pares entre sedes y los túneles de dispositivo siempre activos no son sesiones intercambiables. Una función de distribución creada para una de ellas normalmente redirige a un cliente durante la negociación, lo que no significa nada para un par que ya tiene una dirección fija y una configuración estática.

La guía de alta disponibilidad de ASA de Cisco mantiene tres capacidades separadas: el equilibrio de carga de VPN de acceso remoto, el failover con estado y el clúster entre sedes. Solo la primera mueve a un cliente elegible de una entrada de grupo a un miembro, y las conexiones LAN a LAN quedan fuera de esa distribución. Un equilibrador TCP genérico no puede sustituir el paso de redirección propio del protocolo, porque el handshake del túnel no es HTTP simple que un proxy pueda reescribir. El resultado práctico es un equilibrador que acepta la conexión y aun así deja al cliente sin poder crear el túnel.

Lee la lista de funciones frente a tu tipo de sesión antes de pedir un segundo dispositivo. La línea de licencia y la línea de mecanismo son entradas separadas, y una no implica la otra.

Trabaja el ejemplo en lugar de adivinar

Supón que tres puertas de enlace están validadas cada una a 800 túneles concurrentes con la carga que aprobaste, lo que suma 2,400. Un objetivo de hora punta de 1,650 parece cómodo hasta que se pierde una unidad, y entonces la pareja superviviente debe sostener 1,650 contra un 1,600 duro. El diseño ya ha fallado, y ningún ajuste de failover repara la aritmética.

Fija el objetivo de modo que el conjunto superviviente aún lo cumpla, lo que para un grupo de tres miembros significa quedarse por debajo de dos tercios del total. Esa proporción es una propiedad de la aritmética y no de ningún producto, así que recalcúlala cuando cambie la cifra validada de un miembro. Mantén el recuento licenciado, el máximo documentado y tu propia cifra medida en tres columnas, porque rara vez coinciden y la más pequeña manda. Una cuarta columna para el pico de hora punta observado mantiene el plan honesto tras el primer mes.

Presupuesta la ráfaga de reconexión, no solo el estado estable

Las sesiones de un miembro fallido no reaparecen en silencio en otro sitio. Según el mecanismo, conmutan con estado, renegocian desde cero o esperan a que la aplicación reintente según su propio calendario.

Unos miles de clientes reintentando en un minuto son un evento distinto de un 1,650 estable, y los servidores de autenticación lo notan primero. Comprueba también el espacio del pool, ya que la redirección no lo consulta: un miembro que no puede asignar una dirección sigue aceptando al cliente y luego descarta su tráfico.

Verifica la capacidad con el pool y la ruta a mano

La verificación es un ejercicio de solo lectura que atrapa la mayoría de errores de diseño antes de que se abra una ventana de mantenimiento. Recoge el pool por miembro, el recuento de sesiones activas y la ruta de vuelta a la subred del cliente, y luego compara cada uno con el plan. El agotamiento del pool y una ruta de retorno ausente aparecen ambos como un cliente que se autentica y luego pierde tráfico.

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

Ejecuta esas lecturas en cada miembro durante una hora punta normal y no una tranquila. Un miembro que informa de sesiones pero no tiene direcciones libres ya está en su límite práctico, diga lo que diga la licencia. Anota la versión del firmware junto a cada salida, ya que los nombres de los comandos cambian entre versiones.

Ensaya la pérdida una vez a propósito, fuera del horario laboral, y registra qué informan los miembros supervivientes mientras ocurre. Un miembro que acepta la redirección pero no tiene espacio en el pool aparece como asignación fallida, algo que el ancho de banda extra nunca arregla. Guarda las cifras validadas con la fecha junto al plan, para que la siguiente revisión de capacidad empiece con pruebas y no con una hoja de cálculo de licencias. Añade el resultado de ese ensayo a la misma página, incluso cuando las cifras coincidan con el plan.