Cliente VPN portátil sen dereitos de administrador: que segue a romperse

Portátil describe o instalador, non o núcleo. Un cliente pode chegar como un só executable nunha memoria USB e aínda necesitar un dispositivo de túnel, unha entrada na táboa de rutas e unha escritura no resolutor antes de que se mova o primeiro paquete. Cal deses tres lle deixará tocar a máquina de destino decide se esa compilación funciona alí sequera. As probas de abaixo responden a pregunta na orde en que o cliente as atopará.

Portátil cobre tres promesas distintas, e só unha é gratuíta

Sen instalador significa que o provedor non rexistrou un servizo, non enviou un desinstalador nin engadiu unha entrada de menú. Sen administrador significa que unha conta normal pode iniciar o cliente e completar unha conexión. Sen cambios no host significa que a máquina se ve idéntica despois de saír. As páxinas de descarga que din portátil adoitan prometer só a primeira delas, e as outras dúas son onde fallan os despregamentos. Unha compilación tamén pode ser portátil no sentido estrito de que se executa desde medios de só lectura sen ningunha escritura de ficheiros de punto, o que aínda non di nada sobre a pila de rede.

As promesas caras son a segunda e a terceira. Un só executable que necesita un adaptador, unha ruta ou unha escritura no resolutor pide ao sistema operativo unha autoridade que a etiqueta portátil nunca cubriu.

Atope o axudante privilexiado que chamará o cliente

Case ningún cliente VPN move paquetes por si mesmo. En Windows a ruta de datos pasa por filtros WFP e o Base Filtering Engine, en macOS por un provedor NetworkExtension que o usuario aproba en Axustes do sistema, e en Linux por un dispositivo tun máis a pila de encamiñamento. O binario que copiou é unha superficie de control para eses compoñentes, non un substituto deles. Pregunte que compoñente espera o cliente e despois confirme que está instalado, en execución e que a súa conta pode usalo.

Linux é o lugar máis doado para demostralo, porque a comprobación é unha soa chamada ao sistema. Abrir /dev/net/tun e pedir un dispositivo ao núcleo require CAP_NET_ADMIN, e a documentación do núcleo sobre TUN/TAP indica tanto a regra de propiedade como a capacidade. Execute a proba coa conta que lanzará o cliente, non como root.

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

Un erro de permisos na liña do medio é a resposta que buscaba: esta conta non pode crear unha interface de túnel, así que calquera cliente de espazo de usuario que necesite unha falla ao conectar, non ao descargar. A última liña elimina o dispositivo de proba e non imprime nada cando funciona. Se ambas as liñas teñen éxito, o host non cambiou nada de forma permanente.

Probe os cambios de ruta e de resolutor antes da primeira conexión

O túnel dividido converte unha conexión nunha decisión de encamiñamento, mentres que un túnel completo convértea nunha substitución da ruta predeterminada. Ambas son escrituras na pila de rede do host, e ambas fallan para unha conta sen privilexios incluso cando o cliente arranca limpo. O resolutor é a terceira escritura, e en hosts con systemd adoita ser a que se rompe ao final. Esa orde importa cando decide onde gastar unha instalación con privilexios elevados.

Unha proba de ruta necesita un destino que de verdade lle importe, así que substitúa o marcador de abaixo por unha subrede do seu propio perfil. O nome do dispositivo ten que existir para que a ruta se poida 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

Se a primeira liña devolve RTNETLINK answers: Operation not permitted, significa que a conta non pode instalar a ruta privada que esixe o perfil. A segunda liña demostra o mesmo dereito ao revés, o que importa porque un cliente que pode engadir rutas pero non quitalas deixa unha táboa rota detrás. A consulta ao resolutor mostra despois se os nomes privados se resolven a través do túnel ou se filtran ao resolutor no que o host xa confía.

Execute as tres mentres o dispositivo de proba aínda exista e logo bórreo. Unha ruta que apunta a un dispositivo que xa non está é a razón máis común pola que un portátil perde a conectividade tras unha conexión fallida.

Decida que ten que sobrevivir á sesión

Borrar o cartafol non é un plan de limpeza. Os adaptadores, as rutas, a configuración do resolutor, os certificados de confianza e as credenciais gardadas poden sobrevivir cada un ao proceso, e un servizo de arranque pode restaurar algúns sen preguntar. Anote que se lle permite deixar ao cliente antes de executalo, non despois da primeira desconexión fallida.

A regra práctica é tomar unha instantánea das tres superficies que vai cambiar e comparalas despois. Rexistre as interfaces, a táboa de encamiñamento principal e o estado do resolutor antes da primeira conexión, e logo repita as mesmas tres lecturas cando o cliente saíse.

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

Todo o que aparece na segunda captura e falta na primeira necesita un dono. Ou o cliente o elimina ao saír, ou o elimina vostede cos mesmos comandos que o crearon, e esa eliminación pertence ás notas de despregamento e non á memoria de alguén sobre o que pasou. En Windows as lecturas equivalentes son Get-NetAdapter, Get-NetRoute e Get-DnsClientServerAddress, que non necesitan elevación pero mostran os mesmos restos.