Portátil de trabajo en una VPN personal: qué cruza realmente

Conectar un portátil de empresa a una VPN doméstica lo sitúa en dos lugares a la vez, y la pregunta interesante es más pequeña y más útil que la alarmante. Nadie tendió un cable Ethernet entre la oficina y la casa, y ninguna ruta convierte la red doméstica en una extensión de la subred corporativa. Lo que existe es un único extremo con acceso a ambos entornos, y tres mecanismos separados deciden qué puede moverse realmente entre ellos. Recorrer esos tres desde el extremo hacia fuera da una respuesta sobre la que un administrador puede actuar en lugar de un debate sobre etiquetas.

Empiece por el extremo, no por el diagrama de red

El extremo es donde se encuentran ambas conexiones, así que es donde empieza la revisión: qué procesos se ejecutan, qué pueden alcanzar y quién los controla. Un diagrama que muestra dos nubes conectadas a un portátil es exacto e inútil, porque implica un enlace que puede no existir. Sustitúyalo por una lista de las aplicaciones que pueden hablar con cada entorno y anote bajo qué cuenta se ejecuta cada una. Ese enfoque también mantiene la revisión proporcionada, ya que un portátil con dos túneles no es el mismo objeto que dos redes unidas.

Esa lista es el inventario del que trabaja el resto de la revisión. Si contiene un cliente de sincronización, un perfil de navegador con sesión iniciada en ambos entornos y un agente de compilación con credenciales, la revisión ya tiene sus sujetos.

Tres puntos de cruce, revisados por separado

El acceso de aplicaciones es el primer punto de cruce y no requiere ningún reenvío. Una pestaña del navegador, un cliente de sincronización o un agente de compilación en el extremo pueden leer de un recurso en un entorno y enviar datos a un recurso en el otro. Esa capacidad existe tanto si el sistema operativo reenvía paquetes entre interfaces como si no, y es el mecanismo que la gente pasa por alto cuando concluye que sin puente no hay riesgo. Por eso leer la lista de aplicaciones es más informativo que leer la lista de interfaces.

La identidad y los datos forman el segundo punto de cruce. Las credenciales corporativas, las cookies de sesión, los documentos descargados y los derechos de administración viven en el extremo, y unirse a otra red no los revela por sí solo. Lo que cambia es el conjunto de partes que podrían influir en el extremo mientras este conserva esas credenciales, y eso es una cuestión sobre la fiabilidad de la red personal, no sobre el enrutamiento. Es un juicio que el propietario del extremo no puede hacer solo, y no lo responde la ausencia de una regla de reenvío.

El reenvío de red es el tercero, y el único que puede convertir el portátil en un dispositivo de tránsito. El reenvío de IP, el uso compartido de conexión a Internet, un proxy o una función de puente pueden hacerlo, y cada uno es una configuración que está activada o no. Inspeccione ese estado directamente en lugar de inferirlo de la presencia de un cliente VPN. En una máquina gestionada la respuesta suele ser no, y verificarlo convierte una suposición en un hecho que merece registrarse.

Pida un recurso, no dos redes

La mayoría de los requisitos reales son más estrechos de lo que parecen al principio: una consola, un recurso compartido, una aplicación web interna. Formule el requisito así y deje que el propietario del recurso decida si corresponde siquiera a este extremo. Una solicitud planteada como la unión de dos redes es difícil de aprobar y fácil de denegar; una solicitud para un servicio concreto tiene respuesta.

Si la respuesta es sí, prefiera la ruta admitida más estrecha y manténgala dentro de los controles existentes de la organización. Un segundo perfil gestionado o una entrada de aplicación de alcance limitado preservan la monitorización y la política; una configuración personal competidora las sustituye en silencio, y nadie sabe cuál gana tras la siguiente actualización.

Incluya los efectos de DNS y de rutas

La resolución de nombres cambia en el momento en que un segundo perfil está activo. Un cliente personal puede imponer su propio resolutor, un navegador puede usar su propio DNS cifrado y una tabla de políticas puede encaminar nombres internos a un servidor distinto del que espera la configuración corporativa. Ninguno de esos casos requiere reenvío, y cualquiera de ellos puede enviar un nombre de host interno al lugar equivocado.

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

Capture esas tres salidas antes y después de que se conecte el segundo perfil. La diferencia entre ellas es el efecto que llega realmente al usuario, y a menudo es mayor que el cambio de enrutamiento que describe el ticket. Conserve ambas capturas para que un revisor posterior vea qué cambió y no qué se pretendía.

Verifique y mantenga una salida

Pruebe la aplicación aprobada desde el proceso y el contexto de usuario reales, no desde un shell de administrador en la misma máquina. Después confirme que los destinos no relacionados siguen siendo inalcanzables donde el diseño lo exige: una frontera que nadie probó es una frontera que nadie puede reclamar. Desconectar el túnel personal debería restaurar el estado anterior, y esa restauración merece comprobarse mientras alguien aún mira.

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

La guía del NIST sobre arquitectura de confianza cero es útil aquí porque elimina la ubicación en la red como fuente automática de confianza, que es exactamente la suposición en cuestión. La pregunta no es si la red doméstica es fiable por naturaleza; es quién puede llegar a qué recurso, desde qué extremo y a través de qué punto de aplicación. Responda esas tres y guarde las pruebas junto con la decisión.