Client VPN portatile senza diritti di amministratore: cosa si rompe ancora

Portatile descrive l’installer, non il kernel. Un client può arrivare come un singolo eseguibile su una chiavetta USB e richiedere comunque un dispositivo tunnel, una voce nella tabella delle rotte e una scrittura nel resolver prima che il primo pacchetto si muova. Quale di questi tre la macchina di destinazione vi lascerà toccare decide se quella build funziona lì del tutto. Le verifiche sotto rispondono alla domanda nell’ordine in cui il client le incontrerà.

Portatile copre tre promesse diverse, e solo una è gratuita

Nessun installer significa che il fornitore non ha registrato un servizio, non ha fornito un disinstallatore e non ha aggiunto una voce di menu. Nessun amministratore significa che un account ordinario può avviare il client e completare una connessione. Nessuna modifica all’host significa che la macchina appare identica dopo che uscite. Le pagine di download che dicono portatile di solito promettono solo la prima di queste, e le altre due sono il punto in cui i deployment falliscono. Una build può essere portatile anche in senso stretto: gira da supporti di sola lettura senza alcuna scrittura di file punto, il che non dice ancora nulla sullo stack di rete.

Le promesse costose sono la seconda e la terza. Un singolo eseguibile che ha bisogno di un adattatore, di una rotta o di una scrittura nel resolver chiede al sistema operativo un’autorità che l’etichetta portatile non ha mai coperto.

Trovate l’helper privilegiato che il client chiamerà

Quasi nessun client VPN sposta i pacchetti da solo. Su Windows il percorso dei dati passa per i filtri WFP e il Base Filtering Engine, su macOS per un provider NetworkExtension che l’utente approva in Impostazioni di Sistema, e su Linux per un dispositivo tun più lo stack di routing. Il binario che avete copiato è una superficie di controllo per quei componenti, non un loro sostituto. Chiedete quale componente si aspetta il client, poi confermate che è installato, in esecuzione e utilizzabile dal vostro account.

Linux è il posto più facile per dimostrarlo, perché il controllo è una sola chiamata di sistema. Aprire /dev/net/tun e chiedere un dispositivo al kernel richiede CAP_NET_ADMIN, e la documentazione del kernel su TUN/TAP indica sia la regola di proprietà sia la capacità. Eseguite la verifica con l’account che avvierà il client, non come root.

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

Un errore di permessi sulla riga di mezzo è la risposta che cercavate: questo account non può creare un’interfaccia tunnel, quindi qualsiasi client nello spazio utente che ne abbia bisogno fallisce al collegamento, non al download. L’ultima riga rimuove il dispositivo di prova e non stampa nulla quando funziona. Se entrambe le righe riescono, l’host non ha cambiato nulla in modo permanente.

Provate le modifiche di rotta e resolver prima della prima connessione

Il tunnel diviso trasforma una connessione in una decisione di routing, mentre un tunnel completo la trasforma in una sostituzione della rotta predefinita. Entrambe sono scritture nello stack di rete dell’host, ed entrambe falliscono per un account senza privilegi anche quando il client stesso parte pulito. Il resolver è la terza scrittura, e sugli host con systemd di solito è quella che si rompe per ultima. Quest’ordine conta quando decidete dove spendere un’installazione elevata.

Una prova di rotta ha bisogno di una destinazione che vi importi davvero, quindi sostituite il segnaposto sotto con una sottorete del vostro profilo. Il nome del dispositivo deve esistere perché la rotta possa attaccarsi a qualcosa.

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

Se la prima riga restituisce RTNETLINK answers: Operation not permitted, l’account non può installare la rotta privata che il profilo richiede. La seconda riga dimostra lo stesso diritto al contrario, il che conta perché un client che può aggiungere rotte ma non rimuoverle lascia una tabella rotta dietro di sé. La query al resolver mostra poi se i nomi privati si risolvono attraverso il tunnel o trapelano verso il resolver di cui l’host si fida già.

Eseguite tutte e tre mentre il dispositivo di prova esiste ancora, poi cancellatelo. Una rotta che punta a un dispositivo sparito è la ragione più comune per cui un portatile perde la connettività dopo una connessione fallita.

Decidete cosa deve sopravvivere alla sessione

Cancellare la cartella non è un piano di pulizia. Adattatori, rotte, impostazioni del resolver, certificati attendibili e credenziali salvate possono ciascuno sopravvivere al processo, e un servizio all’avvio può ripristinarne alcuni senza chiedere. Annotate cosa il client può lasciare dietro di sé prima di eseguirlo, non dopo la prima disconnessione fallita.

La regola pratica è scattare un’istantanea delle tre superfici che state per modificare e confrontarle dopo. Registrate le interfacce, la tabella di routing principale e lo stato del resolver prima della prima connessione, poi ripetete le stesse tre letture quando il client è uscito.

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

Tutto ciò che è presente nella seconda cattura e assente nella prima ha bisogno di un proprietario. O il client lo rimuove all’uscita, o lo rimuovete voi con gli stessi comandi che l’hanno creato, e quella rimozione appartiene alle note di deployment e non alla memoria di qualcuno su cosa è successo. Su Windows le letture equivalenti sono Get-NetAdapter, Get-NetRoute e Get-DnsClientServerAddress, che non richiedono elevazione ma mostrano gli stessi residui.