¿Dos VPN a la vez? Definir primero la frontera del extremo

Dos clientes VPN conectados a la vez sitúan un extremo en dos dominios de recursos, y eso es una cuestión de autorización antes que una cuestión de enrutamiento. Que los túneles estén cifrados no dice nada sobre si las aplicaciones de ese portátil deberían poder alcanzar ambas redes, ni sobre si un par de una red debería poder alcanzar la otra a través de él. Recorra las comprobaciones siguientes en orden y deténgase en la primera que nadie pueda responder. Aprobar el solapamiento sin esas respuestas es la forma en que un arreglo cómodo se convierte, sin ruido, en un puente.

Empiece por el trabajo real: qué recursos de cada red necesita la persona y si ambos propietarios de las redes permiten el acceso simultáneo desde un solo dispositivo.

Compruebe quién permite el solapamiento

Dos redes que autentican al mismo usuario siguen teniendo propietarios distintos, y esos propietarios pueden tener supuestos incompatibles sobre dispositivos que también están conectados en otro lugar. Pregunte a ambos antes de diseñar nada. Una política de acceso remoto escrita para portátiles aislados a menudo no tiene ninguna respuesta para una máquina que está simultáneamente dentro de una red asociada.

Obtenga la respuesta por escrito y guárdela con el registro del cambio. Si un lado dice que no, el resto de esta lista es académico, y se habrá ahorrado una revisión de diseño.

No trate dos interfaces como un enrutador

Dos interfaces activas no convierten automáticamente el dispositivo en un enrutador ni en un puente Ethernet. Compruebe la configuración admitida de reenvío, puente, NAT y proxy antes de describir nada como una ruta de tránsito, y conserve las tareas de enrutamiento autorizadas y no relacionadas que el dispositivo ya tenga. Un portátil que ejecuta una red de contenedores local o un host de virtualización no es aquí un observador neutral.

Si el requisito es realmente un tránsito de A a B, eso corresponde a un dispositivo de red con propietario, un conjunto de reglas auditable y un proceso de cambio. Hacerlo por accidente a través de una estación de trabajo es el resultado que esta comprobación existe para evitar.

Trate el extremo también como un punto de acceso

El dispositivo no es solo un cliente de ambas redes; es un host que ofrece servicios. Un servicio permitido en esa máquina puede ser alcanzable desde un par de VPN según el cortafuegos del host y la política del cliente, así que un puerto de administración expuesto en el portátil forma ahora parte de la superficie de ataque de la red remota. Enumere qué escucha antes de discutir sobre rutas, porque un puerto de depuración enlazado pesa más que cualquier política de túnel. Mantenga los servicios del host limitados a sus fuentes y propósitos previstos.

Trate cada red remota como un dominio de recursos con permisos explícitos en lugar de conceder una confianza amplia porque el tráfico llegó cifrado. La arquitectura de confianza cero de NIST separa la autorización de recursos de la confianza implícita en la ubicación de red, y esa es exactamente la distinción que un portátil con dos túneles difumina.

Haga una pregunta más mientras está aquí: si un servicio local o una aplicación autorizada se vieran comprometidos, qué recursos y credenciales serían alcanzables desde ese punto de apoyo. Escriba la respuesta, porque es la declaración de riesgo real para todo el diseño.

Elija la frontera de trabajo que encaje con el modelo de amenazas

El enrutamiento por aplicación puede asignar programas a los túneles previstos, y los perfiles de trabajo, usuarios o espacios de trabajo virtuales compatibles pueden añadir fronteras de identidad y de datos según la plataforma. Ajuste la frontera al modelo de amenazas y no a la demostración: una separación de enrutamiento sin separación de identidad sigue dejando un solo perfil de navegador con ambas sesiones.

Un espacio de nombres de red aísla el enrutamiento y el estado de red; no aísla cada ruta del sistema de archivos, el portapapeles ni el agente de credenciales. Una máquina virtual o un perfil gestionado también necesitan una política deliberada de compartición y administración del host. Anote qué carpetas, asistentes de autenticación y rutas de copiar y pegar siguen disponibles, porque esos son los canales que de verdad llevan datos entre los dos dominios.

Para trabajo secuencial, un cambio intencionado suele ser más sencillo que mantener el acceso simultáneo. Termine la operación dependiente y luego verifique la identidad y la ruta del siguiente espacio de trabajo en lugar de dejar herramientas en segundo plano ligadas a un contexto ambiguo.

Escriba la aprobación como una tarea, no como un eslogan

Un registro de aprobación debería leerse como una tarea: el espacio de trabajo de soporte puede alcanzar la consola de servicios de la Red A y el portal de incidencias de la Red B, sin reenvío autorizado de A a B, sin agente de credenciales compartido y sin sincronización automática de archivos. Cada cláusula de esa frase corresponde a algo que se puede configurar y probar.

Después verifique los casos negativos, no solo los positivos. Intente alcanzar un recurso que debería quedar fuera de la frontera, confirme que el servicio del host no responde desde el otro lado y compruebe que el asistente de credenciales no sirve en silencio a ambos dominios.

Guarde el registro con el dispositivo, no solo en el ticket, para que la siguiente persona que herede el arreglo sepa qué frontera era deliberada. Un portátil con dos túneles y sin frontera escrita es indistinguible de una configuración errónea.