Una VPN no confiable son tres fronteras separadas, no una

«No confío en esta VPN» suelen ser tres afirmaciones vestidas con una sola frase. Los pares remotos de esa red podrían alcanzar servicios en su host, el operador que ejecuta el túnel podría observar el tráfico que lo atraviesa, y el software cliente que instaló podría cambiar la política de red de su máquina. La creencia que merece corrección es que una regla de cortafuegos, una máquina virtual o una elección cuidadosa del sistema operativo responden a las tres. Cada medida responde exactamente a una de ellas.

El mito: un solo control cubre todo el riesgo

La suposición común es que unirse a una red no confiable es una sola decisión con una sola mitigación. La gente elige el control en el que ya confía, lo aplica y considera el riesgo resuelto: el cortafuegos está activo, el espacio de trabajo es desechable, el cliente proviene de un proveedor respetable.

Esos controles no se solapan como la suposición implica. Un cortafuegos de host limita a qué puede llegar un par remoto, y no hace nada contra un operador que termina su TLS. Una máquina virtual separa un espacio de trabajo de los archivos de su host, y no hace nada contra un componente cliente al que se permite reconfigurar la pila de red debajo de ambos. Nombrar la frontera que cada control crea realmente es todo el ejercicio.

Separarlas también le dice qué riesgo ha elegido aceptar. La mayoría de las decisiones reales mitigan una frontera y toleran otra, lo cual está bien siempre que el registro del cambio diga cuál es cuál.

A qué puede llegar realmente el par remoto

Empiece por los servicios que escuchan. La interfaz de túnel tratada como ampliamente confiable porque sus paquetes llegaron cifrados es el error habitual, y convierte cada escucha local en un objetivo candidato para cualquiera que esté en esa red. El cifrado protege el cable entre dos extremos; no dice nada sobre la intención del par al otro lado.

ss -tulpn
sudo nft list ruleset
ip -br addr

Ate los servicios a la dirección que necesitan en lugar de a cada interfaz, y permita solo las operaciones que la tarea aprobada requiere. Mantenga explícitos el reenvío, el puente y el proxy de aplicaciones, porque dos conexiones de red no crean una ruta de tránsito por sí solas, pero una regla de proxy sí puede.

Un espacio de trabajo desechable aprobado reduce a qué puede llegar la red remota, pero solo cuando su configuración de compartición coincide con la afirmación. Las carpetas compartidas, la integración del portapapeles, los agentes de credenciales y los canales de gestión cruzan todos la frontera que el espacio de trabajo debía crear. La etiqueta del espacio de trabajo no prueba nada sobre cuáles de ellos están abiertos.

La arquitectura de confianza cero de NIST enuncia el principio que hay detrás de todo esto: la ubicación de red por sí sola no otorga confianza implícita. La autenticación de recursos aún tiene trabajo después de que se admita el túnel, y también lo tiene la pregunta de quién más comparte esa red.

Qué puede ver el operador en la ruta

Una VPN mueve su tráfico a otro lugar de la ruta; no añade cifrado de aplicaciones. Si el proveedor termina su TLS, el proveedor puede leer lo que su navegador habría protegido de otro modo, y ninguna regla de cortafuegos local lo cambia.

Mantenga la validación normal de certificados para el destino real y comprenda la ruta del resolutor y de los metadatos, porque una consulta DNS puede revelar más que la carga útil que la precede. Solo los metadatos, es decir, a qué direcciones contactó y cuándo, a menudo responden la pregunta que el operador hacía sin necesidad alguna de leer contenido. Por eso «el tráfico está cifrado» y «el tráfico es privado» son afirmaciones distintas.

Si esa visibilidad es inaceptable para la tarea, la respuesta es otra arquitectura aprobada en lugar de más filtrado local. El filtrado local no puede quitar un observador de una ruta en la que todavía se sienta.

Qué puede cambiar el cliente local

Esta es la frontera que la gente pasa por alto, y es la que deja sin sentido las otras dos. En Linux, CAP_NET_ADMIN cubre la configuración de interfaces, la administración del cortafuegos y los cambios de rutas dentro de su contexto de red. El software que posee esa capacidad puede reescribir la política que acaba de escribir.

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

Un espacio de nombres de red es una frontera real para el estado de red y una mala para todo lo demás: no aísla el sistema de archivos ni el almacén de credenciales. Trátelo como una capa y no como un contenedor de todo el problema.

Obtenga el cliente y su configuración de una fuente mantenida, revise la autoridad que solicita y mantenga los componentes privilegiados bajo control de administrador. Una máquina virtual puede formar parte de una frontera de evaluación cualificada sin convertirse en permiso para ejecutar un instalador inexplicado junto a credenciales valiosas. El instalador se ejecuta con la autoridad que usted le dé, y esa autoridad es la frontera.

Escriba qué frontera aceptó

Termine con una frase que nombre cuatro cosas: el código local confiable, el acceso remoto permitido, los datos de aplicación protegidos y la relación con el operador que queda. Esa frase vale más que una afirmación general de que una VM, un sistema operativo o un producto antivirus hicieron segura una red hostil.

Luego confirme que la operación estrecha funciona y que la denegación requerida sigue vigente, incluso después de que caiga el túnel. Una frontera que solo existe mientras el túnel está activo no es la frontera que documentó.

Ninguna prueba demuestra que toda vulnerabilidad esté ausente, y una revisión que afirme lo contrario exagera. La salida honesta nombra el riesgo residual y a la persona que lo aceptó.