Un inicio de sesión VPN en un PC compartido: ¿quién más recibe la ruta?
Un inicio de sesión VPN autentica a una persona; la ruta que instala es un ámbito distinto. Compare túneles para todo el equipo, por usuario y por aplicación en una máquina compartida.
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.
| Arrangement | Enforced by | Who can use the path |
|---|---|---|
| Host-wide tunnel | The routing table | Any local process using that table |
| Per-user connection | Profile permission list | Only the listed accounts |
| Per-app allowlist | The VPN client itself | Only the selected applications |
| Namespace or VM | The interface boundary | Only 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.