Dous VPN á vez? Definir primeiro a fronteira do extremo

Dous clientes VPN conectados á vez sitúan un extremo en dous dominios de recursos, e iso é unha cuestión de autorización antes que unha cuestión de encamiñamento. Que os túneles estean cifrados non di nada sobre se as aplicacións dese portátil deberían poder chegar a ambas as redes, nin sobre se un par dunha rede debería poder chegar á outra a través del. Percorra as comprobacións seguintes en orde e detéñase na primeira que ninguén poida responder. Aprobar o solapamento sen esas respostas é a forma en que un arranxo cómodo se converte, sen ruído, nunha ponte.

Comece polo traballo real: que recursos de cada rede necesita a persoa e se ambos os propietarios das redes permiten o acceso simultáneo desde un só dispositivo.

Comprobe quen permite o solapamento

Dúas redes que autentican o mesmo usuario seguen tendo propietarios distintos, e eses propietarios poden ter suposicións incompatibles sobre dispositivos que tamén están conectados noutro lugar. Pregunte a ambos antes de deseñar nada. Unha política de acceso remoto escrita para portátiles illados a miúdo non ten ningunha resposta para unha máquina que está simultaneamente dentro dunha rede asociada.

Obteña a resposta por escrito e gárdea co rexistro do cambio. Se un lado di que non, o resto desta lista é académico, e aforrou unha revisión de deseño.

Non trate dúas interfaces como un encamiñador

Dúas interfaces activas non converten automaticamente o dispositivo nun encamiñador nin nunha ponte Ethernet. Comprobe a configuración admitida de reenvío, ponte, NAT e proxy antes de describir nada como unha ruta de tránsito, e conserve as tarefas de encamiñamento autorizadas e non relacionadas que o dispositivo xa teña. Un portátil que executa unha rede de contedores local ou un host de virtualización non é aquí un observador neutral.

Se o requisito é realmente un tránsito de A a B, iso corresponde a un dispositivo de rede con propietario, un conxunto de regras auditable e un proceso de cambio. Facelo por accidente a través dunha estación de traballo é o resultado que esta comprobación existe para evitar.

Trate o extremo tamén como un punto de acceso

O dispositivo non é só un cliente de ambas as redes; é un host que ofrece servizos. Un servizo permitido nesa máquina pode ser alcanzable desde un par de VPN segundo o cortafuegos do host e a política do cliente, así que un porto de administración exposto no portátil forma agora parte da superficie de ataque da rede remota. Enumere que escoita antes de discutir sobre rutas, porque un porto de depuración ligado pesa máis que calquera política de túnel. Manteña os servizos do host limitados ás súas fontes e propósitos previstos.

Trate cada rede remota como un dominio de recursos con permisos explícitos en lugar de conceder unha confianza ampla porque o tráfico chegou cifrado. A arquitectura de confianza cero de NIST separa a autorización de recursos da confianza implícita na localización de rede, e esa é exactamente a distinción que un portátil con dous túneles difumina.

Faga unha pregunta máis mentres está aquí: se un servizo local ou unha aplicación autorizada fosen comprometidos, que recursos e credenciais serían alcanzables desde ese punto de apoio? Escriba a resposta, porque é a declaración de risco real para todo o deseño.

Escolla a fronteira de traballo que encaixe co modelo de ameazas

O encamiñamento por aplicación pode asignar programas aos túneles previstos, e os perfís de traballo, usuarios ou espazos de traballo virtuais compatibles poden engadir fronteiras de identidade e de datos segundo a plataforma. Axuste a fronteira ao modelo de ameazas e non á demostración: unha separación de encamiñamento sen separación de identidade segue deixando un só perfil de navegador con ambas as sesións.

Un espazo de nomes de rede illa o encamiñamento e o estado de rede; non illa cada ruta do sistema de ficheiros, o portapapeis nin o axente de credenciais. Unha máquina virtual ou un perfil xestionado tamén necesitan unha política deliberada de compartición e administración do host. Anote que cartafoles, asistentes de autenticación e rutas de copiar e pegar seguen dispoñibles, porque esas son as canles que de verdade levan datos entre os dous dominios.

Para traballo secuencial, un cambio intencionado adoita ser máis sinxelo que manter o acceso simultáneo. Remate a operación dependente e despois verifique a identidade e a ruta do seguinte espazo de traballo en lugar de deixar ferramentas en segundo plano ligadas a un contexto ambiguo.

Escriba a aprobación como unha tarefa, non como un eslogan

Un rexistro de aprobación debería lerse como unha tarefa: o espazo de traballo de soporte pode alcanzar a consola de servizos da Rede A e o portal de incidencias da Rede B, sen reenvío autorizado de A a B, sen axente de credenciais compartido e sen sincronización automática de ficheiros. Cada cláusula desa frase corresponde a algo que se pode configurar e probar.

Despois verifique os casos negativos, non só os positivos. Intente alcanzar un recurso que debería quedar fóra da fronteira, confirme que o servizo do host non responde desde o outro lado e comprobe que o asistente de credenciais non serve en silencio a ambos os dominios.

Garde o rexistro co dispositivo, non só no ticket, para que a seguinte persoa que herde o arranxo saiba que fronteira era deliberada. Un portátil con dous túneles e sen fronteira escrita é indistinguible dunha configuración errónea.