Límite de sesiones de una cuenta VPN compartida: por qué se cae un dispositivo
Un inicio de sesión compartido llega a su tope de sesiones simultáneas y un dispositivo se cae. Lee el mensaje del cliente, cuenta las sesiones en el servidor y luego corrige el modelo de identidad.
Añades un segundo portátil a la cuenta que ya funciona en tu teléfono, y el túnel del teléfono se cae en menos de un minuto. O el dispositivo nuevo nunca termina de conectarse, y el cliente acaba en un mensaje de política en lugar de un tiempo de espera. La red está bien en ambos casos; la decisión se tomó por encima de ella. Un inicio de sesión compartido es una identidad, y la mayoría de los servicios VPN cuentan esa identidad en lugar del número de dispositivos que posees. Yo trabajo desde la pantalla del cliente hacia fuera, porque suele mostrar qué capa te rechazó.
Lee el mensaje del cliente antes de tocar la red
Tres fallos se parecen y no lo son. Un tiempo de espera significa que tus paquetes no llegaron a nada. Un error de TLS o de certificado significa que el extremo respondió pero el apretón de manos falló. Un rechazo de autenticación o de política significa que la puerta de enlace leyó tus credenciales y luego las rechazó. Solo el tercero pertenece a una historia de límite de sesiones, así que fíjalo primero.
Los clientes de OpenVPN guardan las líneas interesantes en su panel de registro. Desplázate hasta el último intento de conexión y no hasta el bucle de reintentos que lo sigue, y busca AUTH_FAILED o una cadena de motivo enviada. El cliente a menudo informa de un rechazo genérico sin explicación, así que el siguiente paso es el servidor, no la configuración del cliente. Las aplicaciones del proveedor son peores: un mensaje de límite de dispositivos es útil, pero una conexión que se derrumba a los dos segundos es una decisión de política, no una contraseña incorrecta. Anota el nombre del dispositivo y la hora exacta en cualquier caso; un operador puede emparejar ese par con un registro de acceso en segundos.
Cuenta las sesiones donde las cuenta el servidor
El contador que importa vive en la puerta de enlace. OpenVPN escribe un archivo de estado cuando el servidor se inicia con --status, listando cada cliente conectado con su nombre común, su dirección real y sus contadores de tráfico.
cat /var/log/openvpn-status.log
# or query the management socket directly
echo "status 2" | socat - UNIX-CONNECT:/run/openvpn/server.sock
Dos filas con el mismo nombre común son dos sesiones vivas bajo un solo certificado. Por defecto OpenVPN no las mantiene ambas: sin --duplicate-cn, una segunda conexión con el mismo certificado sustituye a la primera, y el dispositivo más antiguo pierde su túnel. Esa sustitución es la firma de un límite de identidad. Una pérdida de paquetes aleatoria no desconecta con educación exactamente un dispositivo en el momento en que aparece otro.
WireGuard no tiene tabla de sesiones que inspeccionar. wg show wg0 imprime los pares y su último apretón de manos, y cada dispositivo inscrito es un par con su propia clave. Una cuenta compartida allí es un archivo de configuración copiado a varias máquinas, y el límite viene de lo que reparta esas configuraciones: un portal del proveedor, un recuento de asientos o una regla ligada a tu dirección pública. El manual de OpenVPN 2.6 documenta las opciones del lado del servidor si mantienes tu propia puerta de enlace.
Separa los cuatro límites que se esconden tras un solo mensaje
La mayoría de los tickets de cuenta compartida son una de cuatro decisiones de admisión. El cliente no puede distinguirlas, pero el patrón de qué dispositivo falla sí.
Misma identidad, segunda conexión. El dispositivo nuevo funciona y el viejo muere en el mismo instante. Es una regla de concurrencia por identidad que aplica la puerta de enlace o el sistema de cuentas. Nada está roto; el servicio hace lo que dice su política.
Recuento de asientos o dispositivos en el plan. Los primeros dispositivos siguen conectados y el siguiente es rechazado mientras los demás siguen funcionando. Revisa la lista de dispositivos del proveedor antes de cambiar un cliente, porque un límite de licencia no se puede arreglar desde el lado del cliente.
Un tope ligado a tu dirección pública. Dos portátiles tras un solo router doméstico fallan mientras el mismo inicio de sesión funciona desde un punto de acceso del teléfono. Mueve el segundo dispositivo a otra red para probarlo. Si ahí se conecta, estás viendo una regla por dirección o una regla NAT, no el recuento de la cuenta.
Un máximo de todo el servidor. Todos en la puerta de enlace fallan en la misma hora punta, incluidas cuentas que ayer estaban bien. El --max-clients de OpenVPN se comporta así, y no tiene nada que ver con los dispositivos que hayas inscrito.
Limpia las sesiones obsoletas antes de comprar más asientos
Una sesión que terminó mal puede seguir ocupando una plaza. La contabilidad RADIUS escribe un registro cuando empieza una sesión y lo cierra cuando la sesión se detiene; cuando un cliente desaparece, la parada nunca llega y el servidor mantiene la sesión hasta que caduca una actualización intermedia o un tiempo de espera. En una puerta de enlace FreeRADIUS puedes ver los registros abiertos:
SELECT username, acctsessionid, acctstarttime
FROM radacct WHERE acctstoptime IS NULL;
Un registro abierto con una hora de inicio antigua y sin tráfico pertenece a un dispositivo que ya no está. Ciérralo desde la consola del operador o con una solicitud de desconexión, antes de suponer que el límite era real. Los teléfonos se reconectan cuando el Wi-Fi pasa a la red móvil, y un portátil puede llevar un túnel en el sistema operativo y otro dentro de una aplicación del proveedor, lo que cuenta como dos sesiones de una sola máquina.
Deja de compartir una identidad entre dispositivos que funcionan juntos
La solución duradera es estructural. Da a cada dispositivo su propio certificado con un nombre común único, o su propia cuenta, y registra qué persona y qué máquina lo tiene. En OpenVPN eso significa un certificado de cliente por dispositivo, con --duplicate-cn desactivado salvo que quieras comportamiento de toma de control; en WireGuard, un par de claves por dispositivo, generado allí y nunca copiado.
Clonar un perfil para saltarse un límite de dispositivos rompe la revocación: revocar una copia corta cada dispositivo que la comparte, y el registro ya no puede decir qué máquina hizo qué. Si el límite es comercial, la solución honesta es un asiento añadido; si es política interna, pide una segunda identidad con los mismos derechos de acceso.
Verifica en un orden fijo
Prueba la reparación de la misma manera cada vez, para que el resultado signifique algo.
- Cierra la sesión en cada dispositivo y confirma que la lista activa del servidor está vacía; una entrada que no se limpia es una sesión obsoleta, no un error del cliente.
- Conecta los dispositivos de uno en uno y observa la lista entre conexiones.
- Si dos deben funcionar juntos, confirma que ambas filas llevan identidades distintas y que las dos mantienen su apretón de manos fresco.
- Repítelo tras un traspaso de Wi-Fi a móvil, ya que una reconexión puede crear un segundo registro.
Si el dispositivo viejo sigue cayendo cuando se conecta el nuevo, la puerta de enlace aplica una regla por identidad para la que no te han concedido excepción. Lleva al operador los nombres de los dispositivos, las marcas de tiempo y la lista de sesiones activas; eso convierte una queja vaga en una pregunta de política que pueden responder.