Compartir una estación de trabajo plantea una pregunta que un portátil de un solo usuario nunca tiene que responder: una vez que una persona autentica el túnel, ¿quién más puede usarlo? El inicio de sesión identifica a un sujeto y la ruta que instala describe un ámbito, y esas dos cosas no son el mismo objeto. Entre ellas están el sistema operativo, la configuración del cliente y lo que el servicio privado exige por su cuenta. Comparar los puntos de aplicación es la única forma de responder sin adivinar.

Un inicio de sesión, varios ámbitos

La autenticación responde quién fue admitido. La ruta responde qué paquetes pueden salir por el túnel. La autorización responde qué servicio aceptará la conexión resultante, y ninguna de las tres implica la siguiente.

Un túnel para todo el equipo es el valor predeterminado habitual y hace evidente la brecha. La ruta está en la tabla del núcleo, así que cualquier proceso que use esa tabla puede llegar a la red privada, incluido uno iniciado por un usuario que nunca vio el diálogo de VPN. No es un defecto del túnel; es lo que significa una ruta de todo el sistema. El servicio privado aún puede rechazar la conexión, y por eso la alcanzabilidad y el permiso necesitan respuestas separadas.

Escribir las cuatro preguntas antes de probar evita que la revisión se reduzca a una de ellas.

Dónde está realmente la frontera

Cuatro disposiciones cubren la mayoría de las máquinas: un túnel para todo el equipo, una conexión por usuario, una lista de aplicaciones permitidas y un espacio de nombres de red o una máquina virtual aparte.

Cada una sitúa el punto de aplicación en otro lugar, y las diferencias importan más que las etiquetas. Una conexión por usuario se aplica con los permisos del perfil, no con la pantalla de inicio de sesión del escritorio. Una lista de aplicaciones permitidas se aplica dentro del cliente, que decide qué transportará. Un espacio de nombres o una VM se aplica en la frontera de la interfaz, así que un proceso de dentro no puede ver en absoluto la ruta del equipo. El número de pantallas de inicio de sesión de la máquina no dice nada de ninguna de ellas.

ArrangementEnforced byWho can use the path
Host-wide tunnelThe routing tableAny local process using that table
Per-user connectionProfile permission listOnly the listed accounts
Per-app allowlistThe VPN client itselfOnly the selected applications
Namespace or VMThe interface boundaryOnly processes inside it

Leer la tabla fila por fila muestra que la pregunta real no es si existe aislamiento, sino dónde se implementa.

Compare cuatro puntos de aplicación

En Linux la tabla de rutas es lo primero que hay que inspeccionar, porque un túnel para todo el equipo aparece allí y un espacio de nombres no. Ejecutar la consulta como el segundo usuario es el paso que la gente omite; la respuesta difiere de la que obtuvieron como ellos mismos, y eso explica el informe.

Las dos comprobaciones siguientes miran la política, no el enrutamiento. Una regla de cortafuegos que coincide con un UID se aplica al tráfico generado localmente, así que puede separar a dos usuarios en un equipo aunque ambos compartan la ruta. Un perfil de conexión con una lista explícita de permisos lo aplica el gestor de red al activarse. Ninguna de las comprobaciones requiere cambiar el túnel, y por eso vale la pena hacerlas antes de rediseñar nada.

ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid

Si la segunda consulta muestra la ruta del túnel, la frontera no está donde el diseño suponía.

Las reglas de sesiones concurrentes son un control aparte

Las pasarelas a menudo limitan cuántas sesiones puede mantener una cuenta, y ese límite no tiene nada que ver con los usuarios locales. Restringe la cuenta, así que una segunda persona que entre con la misma credencial puede terminar con el túnel de la primera.

Lea el fallo antes de suponer un problema local de aislamiento. Un límite de sesiones produce una desconexión en la pasarela, mientras que un problema de ámbito produce un túnel que funciona pero que simplemente no lleva el tráfico del otro usuario. Esos dos síntomas llevan a correcciones completamente distintas. Guarde el mensaje exacto del cliente, porque normalmente nombra la regla. Pida al propietario del perfil el flujo de trabajo aprobado en lugar de sortear el límite.

Una máquina virtual no exime a nadie de esa regla y añade su propio diseño de red y de credenciales.

Pruebe el contexto que le importa

Pruebe el usuario y la aplicación previstos y luego pruebe un contexto que debería denegarse. Una revisión que solo demuestra que la contraseña original funciona ha probado la autenticación y nada más.

sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'

Anote el punto de aplicación junto a cada resultado: la tabla de rutas, una regla de UID, un permiso de perfil o la política de sesiones de la pasarela. Ese registro hace revisable el siguiente cambio. También impide que la misma pregunta se reabra cada vez que alguien nota una segunda pantalla de inicio de sesión. La alcanzabilidad no es autorización, y ninguna de las dos es aislamiento.

Artículos relacionados