Cliente VPN portátil sin derechos de administrador: qué sigue rompiéndose

Portátil describe el instalador, no el núcleo. Un cliente puede llegar como un solo ejecutable en una memoria USB y aun así necesitar un dispositivo de túnel, una entrada en la tabla de rutas y una escritura en el resolutor antes de que se mueva el primer paquete. Cuál de esos tres le dejará tocar la máquina de destino decide si esa compilación funciona allí siquiera. Las pruebas de abajo responden la pregunta en el orden en que el cliente se las encontrará.

Portátil cubre tres promesas distintas, y solo una es gratuita

Sin instalador significa que el proveedor no registró un servicio, no envió un desinstalador ni añadió una entrada de menú. Sin administrador significa que una cuenta normal puede iniciar el cliente y completar una conexión. Sin cambios en el host significa que la máquina se ve idéntica después de salir. Las páginas de descarga que dicen portátil suelen prometer solo la primera de ellas, y las otras dos son donde fallan los despliegues. Una compilación también puede ser portátil en el sentido estricto de que se ejecuta desde medios de solo lectura sin ninguna escritura de archivos de punto, lo que todavía no dice nada sobre la pila de red.

Las promesas caras son la segunda y la tercera. Un solo ejecutable que necesita un adaptador, una ruta o una escritura en el resolutor pide al sistema operativo una autoridad que la etiqueta portátil nunca cubrió.

Encuentre el ayudante privilegiado que llamará el cliente

Casi ningún cliente VPN mueve paquetes por sí solo. En Windows la ruta de datos pasa por filtros WFP y el Base Filtering Engine, en macOS por un proveedor NetworkExtension que el usuario aprueba en Ajustes del sistema, y en Linux por un dispositivo tun más la pila de enrutamiento. El binario que copió es una superficie de control para esos componentes, no un sustituto de ellos. Pregunte qué componente espera el cliente y luego confirme que está instalado, en ejecución y que su cuenta puede usarlo.

Linux es el lugar más fácil para demostrarlo, porque la comprobación es una sola llamada al sistema. Abrir /dev/net/tun y pedir un dispositivo al núcleo requiere CAP_NET_ADMIN, y la documentación del núcleo sobre TUN/TAP indica tanto la regla de propiedad como la capacidad. Ejecute la prueba con la cuenta que lanzará el cliente, no como root.

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

Un error de permisos en la línea del medio es la respuesta que buscaba: esta cuenta no puede crear una interfaz de túnel, así que cualquier cliente de espacio de usuario que necesite una falla al conectar, no al descargar. La última línea elimina el dispositivo de prueba y no imprime nada cuando funciona. Si ambas líneas tienen éxito, el host no ha cambiado nada de forma permanente.

Pruebe los cambios de ruta y de resolutor antes de la primera conexión

El túnel dividido convierte una conexión en una decisión de enrutamiento, mientras que un túnel completo la convierte en una sustitución de la ruta predeterminada. Ambas son escrituras en la pila de red del host, y ambas fallan para una cuenta sin privilegios incluso cuando el cliente arranca limpio. El resolutor es la tercera escritura, y en hosts con systemd suele ser la que se rompe al final. Ese orden importa cuando decide dónde gastar una instalación con privilegios elevados.

Una prueba de ruta necesita un destino que de verdad le importe, así que sustituya el marcador de abajo por una subred de su propio perfil. El nombre del dispositivo tiene que existir para que la ruta se pueda enganchar a algo.

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

Si la primera línea devuelve RTNETLINK answers: Operation not permitted, significa que la cuenta no puede instalar la ruta privada que exige el perfil. La segunda línea demuestra el mismo derecho a la inversa, lo que importa porque un cliente que puede añadir rutas pero no quitarlas deja una tabla rota detrás. La consulta al resolutor muestra después si los nombres privados se resuelven a través del túnel o se filtran al resolutor en el que el host ya confía.

Ejecute las tres mientras el dispositivo de prueba todavía exista y luego bórrelo. Una ruta que apunta a un dispositivo que ya no está es la razón más común por la que un portátil pierde conectividad tras una conexión fallida.

Decida qué tiene que sobrevivir a la sesión

Borrar la carpeta no es un plan de limpieza. Los adaptadores, las rutas, la configuración del resolutor, los certificados de confianza y las credenciales guardadas pueden sobrevivir cada uno al proceso, y un servicio de arranque puede restaurar algunos sin preguntar. Anote qué se le permite dejar al cliente antes de ejecutarlo, no después de la primera desconexión fallida.

La regla práctica es tomar una instantánea de las tres superficies que va a cambiar y compararlas después. Registre las interfaces, la tabla de enrutamiento principal y el estado del resolutor antes de la primera conexión, y luego repita las mismas tres lecturas cuando el cliente haya salido.

ip -brief addr show
ip route show table main
resolvectl status

Todo lo que aparece en la segunda captura y falta en la primera necesita un dueño. O el cliente lo elimina al salir, o lo elimina usted con los mismos comandos que lo crearon, y esa eliminación pertenece a las notas de despliegue y no a la memoria de alguien sobre lo que pasó. En Windows las lecturas equivalentes son Get-NetAdapter, Get-NetRoute y Get-DnsClientServerAddress, que no necesitan elevación pero muestran los mismos restos.