Un inicio de sesión VPN nun PC compartido: quen máis recibe a ruta?

Compartir unha estación de traballo expón unha pregunta que un portátil dun só usuario nunca ten que responder: unha vez que unha persoa autentica o túnel, quen máis pode usalo? O inicio de sesión identifica un suxeito e a ruta que instala describe un ámbito, e esas dúas cousas non son o mesmo obxecto. Entre elas están o sistema operativo, a configuración do cliente e o que o servizo privado esixe pola súa conta. Comparar os puntos de aplicación é a única forma de responder sen adiviñar.

Un inicio de sesión, varios ámbitos

A autenticación responde quen foi admitido. A ruta responde que paquetes poden saír polo túnel. A autorización responde que servizo aceptará a conexión resultante, e ningunha das tres implica a seguinte.

Un túnel para todo o equipo é o valor predeterminado habitual e fai evidente a fenda. A ruta está na táboa do núcleo, así que calquera proceso que use esa táboa pode chegar á rede privada, incluído un iniciado por un usuario que nunca viu o diálogo de VPN. Non é un defecto do túnel; é o que significa unha ruta de todo o sistema. O servizo privado aínda pode rexeitar a conexión, e por iso a alcanzabilidade e o permiso necesitan respostas separadas.

Escribir as catro preguntas antes de probar evita que a revisión se reduza a unha delas.

Onde está realmente a fronteira

Catro disposicións cobren a maioría das máquinas: un túnel para todo o equipo, unha conexión por usuario, unha lista de aplicacións permitidas e un espazo de nomes de rede ou unha máquina virtual á parte.

Cada unha sitúa o punto de aplicación noutro lugar, e as diferenzas importan máis que as etiquetas. Unha conexión por usuario aplícase cos permisos do perfil, non coa pantalla de inicio de sesión do escritorio. Unha lista de aplicacións permitidas aplícase dentro do cliente, que decide que transportará. Un espazo de nomes ou unha VM aplícase na fronteira da interface, así que un proceso de dentro non pode ver en absoluto a ruta do equipo. O número de pantallas de inicio de sesión da máquina non di nada de ningunha delas.

Ler a táboa fila por fila mostra que a pregunta real non é se existe illamento, senón onde se implementa.

Compare catro puntos de aplicación

En Linux a táboa de rutas é o primeiro que hai que inspeccionar, porque un túnel para todo o equipo aparece alí e un espazo de nomes non. Executar a consulta como o segundo usuario é o paso que a xente omite; a resposta difire da que obtiveron como eles mesmos, e iso explica o informe.

As dúas comprobacións seguintes miran a política, non o encamiñamento. Unha regra de devasas que coincide cun UID aplícase ao tráfico xerado localmente, así que pode separar dous usuarios nun equipo aínda que ambos compartan a ruta. Un perfil de conexión cunha lista explícita de permisos aplícao o xestor de rede ao activarse. Ningunha das comprobacións require cambiar o túnel, e por iso paga a pena facelas antes de redeseñ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

Se a segunda consulta mostra a ruta do túnel, a fronteira non está onde o deseño supoñía.

As regras de sesións simultáneas son un control á parte

As pasarelas a miúdo limitan cantas sesións pode manter unha conta, e ese límite non ten nada que ver cos usuarios locais. Restrinxe a conta, así que unha segunda persoa que entre coa mesma credencial pode rematar co túnel da primeira.

Lea o fallo antes de supoñer un problema local de illamento. Un límite de sesións produce unha desconexión na pasarela, mentres que un problema de ámbito produce un túnel que funciona pero que simplemente non leva o tráfico do outro usuario. Eses dous síntomas levan a correccións completamente distintas. Garde a mensaxe exacta do cliente, porque normalmente nomea a regra. Pida ao propietario do perfil o fluxo de traballo aprobado en lugar de evitar o límite.

Unha máquina virtual non exime a ninguén desa regra e engade o seu propio deseño de rede e de credenciais.

Probe o contexto que lle importa

Probe o usuario e a aplicación previstos e despois probe un contexto que debería ser denegado. Unha revisión que só demostra que o contrasinal orixinal funciona probou a autenticación e nada máis.

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

Anote o punto de aplicación xunto a cada resultado: a táboa de rutas, unha regra de UID, un permiso de perfil ou a política de sesións da pasarela. Ese rexistro fai revisable o seguinte cambio. Tamén impide que a mesma pregunta se reabra cada vez que alguén nota unha segunda pantalla de inicio de sesión. A alcanzabilidade non é autorización, e ningunha das dúas é illamento.