Cuenta VPN compartida: un límite de dispositivos no es aislamiento de clientes

Ocho conexiones simultáneas es un número de una página de licencia y no dice nada sobre lo que esos ocho dispositivos pueden hacerse entre sí. Un inicio de sesión compartido puede convivir con claves por sesión, y también puede convivir con una puerta de enlace que reenvía tan contenta el tráfico de un cliente a otro. El error es tratar la cuenta como una frontera de seguridad. Haga más bien cuatro preguntas separadas: qué se compró, qué protege el túnel, qué puede cruzar entre pares y qué puede tumbar el enlace local.

Qué promete realmente un permiso de conexiones

Un límite de dispositivos cuenta cuántas sesiones aceptará el proveedor por una suscripción. Es un control comercial y operativo, no una declaración sobre identidad o aislamiento. Algunos proveedores emiten un certificado distinto por dispositivo bajo una sola cuenta; otros reutilizan una única credencial en cada conexión. La diferencia aparece al revocar, porque las credenciales separadas permiten cortar un dispositivo y una compartida no le deja esa opción.

Lea cómo emite el proveedor las credenciales antes de suponer nada sobre la separación de claves. El nombre de la cuenta no revela nada de eso.

Compruebe si la puerta de enlace reenvía entre clientes

El alcance entre pares es una decisión del lado del servidor. En OpenVPN el interruptor pertinente está ausente salvo que aparezca en la configuración, pero la descarga moderna del plano de datos cambia dónde se aplica la regla.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Una configuración sin esa directiva deja el tráfico entre pares al cortafuegos del anfitrión, que aún puede permitirlo. Cuando la descarga está activa, el núcleo se ocupa de la interfaz del túnel en lugar del proceso de espacio de usuario, así que verifique los contadores de reglas en vez de confiar en el archivo. Bloquear el tráfico reenviado entre direcciones del túnel aísla a los clientes sin tocar su acceso a la puerta de enlace. Confírmelo con una prueba de un cliente a un servicio en otro, tanto antes como después de la regla.

Proteja la sesión antes que a los pares

La protección del túnel y el acceso entre pares son propiedades distintas, y un cifrado fuerte no implica aislamiento. En modo TLS cada cliente deriva sus propias claves de sesión, así que un cliente no puede leer el tráfico de otro aunque la puerta de enlace lo retransmita. El antiguo esquema de clave estática comparte una sola clave entre todos, por eso reutilizar allí un inicio de sesión tiene consecuencias mucho peores. Inspeccione el modo configurado y no la página de marketing, y luego juzgue si compartir la cuenta encaja con los datos en juego.

La autenticación del servicio en cada anfitrión sigue importando, porque el túnel solo demuestra que un cliente llegó a la red, no que deba llegar a un demonio concreto.

Los fallos del Wi-Fi local no son compromisos del VPN

Una conexión caída demuestra que falló el enlace local, no que alguien haya roto el túnel. Las interferencias, una concesión DHCP perdida y un traspaso de itinerancia terminan una sesión sin tocar credenciales ni texto cifrado. Trate la desconexión como un hallazgo de disponibilidad y manténgala aparte de los hallazgos de confidencialidad y acceso entre pares. Donde la red local no es fiable, proteja el tráfico de extremo a extremo en lugar de apoyarse solo en el túnel.

Anote las cuatro respuestas: permiso, modelo de claves, política entre pares y dependencia del enlace local. Ese registro convierte una preocupación vaga sobre una cuenta compartida en controles concretos.