Portátil de traballo nunha VPN persoal: que cruza realmente
Un segundo túnel nun portátil de traballo non é unha ponte, pero o extremo aínda pode retransmitir datos. Revise tres puntos de cruce antes de aprobar nada.
Conectar un portátil de empresa a unha VPN doméstica sitúao en dous lugares á vez, e a pregunta interesante é máis pequena e máis útil ca a alarmante. Ninguén tendeu un cable Ethernet entre a oficina e a casa, e ningunha ruta converte a rede doméstica nunha extensión da subrede corporativa. O que existe é un único extremo con acceso a ambos os dous ambientes, e tres mecanismos separados deciden que pode moverse realmente entre eles. Percorrer eses tres desde o extremo cara a fóra dá unha resposta sobre a que un administrador pode actuar en lugar dun debate sobre etiquetas.
Comece polo extremo, non polo diagrama de rede
O extremo é onde se encontran ambas as dúas conexións, así que é onde comeza a revisión: que procesos se executan, que poden alcanzar e quen os controla. Un diagrama que mostra dúas nubes conectadas a un portátil é exacto e inútil, porque implica unha ligazón que pode non existir. Substitúa por unha lista das aplicacións que poden falar con cada ambiente e anote baixo que conta se executa cada unha. Ese enfoque tamén mantén a revisión proporcionada, xa que un portátil con dous túneles non é o mesmo obxecto ca dúas redes unidas.
Esa lista é o inventario do que traballa o resto da revisión. Se contén un cliente de sincronización, un perfil de navegador con sesión iniciada en ambos os dous ambientes e un axente de compilación con credenciais, a revisión xa ten os seus suxeitos.
Tres puntos de cruce, revisados por separado
O acceso de aplicacións é o primeiro punto de cruce e non require ningún reenvío. Unha lapela do navegador, un cliente de sincronización ou un axente de compilación no extremo poden ler dun recurso nun ambiente e enviar datos a un recurso no outro. Esa capacidade existe tanto se o sistema operativo reenvía paquetes entre interfaces como se non, e é o mecanismo que a xente pasa por alto cando conclúe que sen ponte non hai risco. Por iso ler a lista de aplicacións é máis informativo ca ler a lista de interfaces.
A identidade e os datos forman o segundo punto de cruce. As credenciais corporativas, as cookies de sesión, os documentos descargados e os dereitos de administración viven no extremo, e unirse a outra rede non os revela por si só. O que cambia é o conxunto de partes que poderían influír no extremo mentres este conserva esas credenciais, e iso é unha cuestión sobre a fiabilidade da rede persoal, non sobre o encamiñamento. É un xuízo que o propietario do extremo non pode facer só, e non o responde a ausencia dunha regra de reenvío.
O reenvío de rede é o terceiro, e o único que pode converter o portátil nun dispositivo de tránsito. O reenvío de IP, a compartición de conexión a Internet, un proxy ou unha función de ponte poden facelo, e cada un é unha configuración que está activada ou non. Inspeccione ese estado directamente en lugar de inferilo da presenza dun cliente VPN. Nunha máquina xestionada a resposta adoita ser non, e verificalo converte unha suposición nun feito que merece rexistrarse.
Pida un recurso, non dúas redes
A maioría dos requisitos reais son máis estreitos do que parecen ao principio: unha consola, un recurso compartido, unha aplicación web interna. Formule o requisito así e deixe que o propietario do recurso decida se corresponde a este extremo. Unha solicitude formulada como a unión de dúas redes é difícil de aprobar e fácil de denegar; unha solicitude para un servizo concreto ten resposta.
Se a resposta é si, prefira a ruta admitida máis estreita e mantéña dentro dos controis existentes da organización. Un segundo perfil xestionado ou unha entrada de aplicación de alcance limitado preservan a monitorización e a política; unha configuración persoal competidora substitúeas en silencio, e ninguén sabe cal gaña tras a seguinte actualización.
Inclúa os efectos de DNS e de rutas
A resolución de nomes cambia no momento en que un segundo perfil está activo. Un cliente persoal pode impoñer o seu propio resolvedor, un navegador pode usar o seu propio DNS cifrado e unha táboa de políticas pode encamiñar nomes internos a un servidor distinto do que espera a configuración corporativa. Ningún deses casos require reenvío, e calquera deles pode enviar un nome de host interno ao lugar equivocado.
Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0
Capture esas tres saídas antes e despois de que se conecte o segundo perfil. A diferenza entre elas é o efecto que chega realmente ao usuario, e a miúdo é maior có cambio de encamiñamento que describe o ticket. Conserve ambas as capturas para que un revisor posterior vexa que cambiou e non que se pretendía.
Verifique e manteña unha saída
Probe a aplicación aprobada desde o proceso e o contexto de usuario reais, non desde un shell de administrador na mesma máquina. Despois confirme que os destinos non relacionados seguen sendo inalcanzables onde o deseño o esixe: unha fronteira que ninguén probou é unha fronteira que ninguén pode reclamar. Desconectar o túnel persoal debería restaurar o estado anterior, e esa restauración merece comprobarse mentres alguén aínda mira.
Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile
A guía do NIST sobre arquitectura de confianza cero é útil aquí porque elimina a localización na rede como fonte automática de confianza, que é exactamente a suposición en cuestión. A pregunta non é se a rede doméstica é fiable por natureza; é quen pode chegar a que recurso, desde que extremo e a través de que punto de aplicación. Responda esas tres e garde as probas xunto coa decisión.