Client VPN portable sans droits d’administrateur : ce qui casse encore

Portable décrit l’installateur, pas le noyau. Un client peut arriver sous la forme d’un seul exécutable sur une clé USB et tout de même exiger un périphérique tunnel, une entrée dans la table de routage et une écriture dans le résolveur avant que le premier paquet ne bouge. Lequel de ces trois la machine cible vous laissera toucher décide si cette compilation fonctionne là-bas tout court. Les sondes ci-dessous répondent à la question dans l’ordre où le client les rencontrera.

Portable couvre trois promesses différentes, et une seule est gratuite

Pas d’installateur signifie que l’éditeur n’a enregistré aucun service, n’a livré aucun désinstalleur et n’a ajouté aucune entrée de menu. Pas d’administrateur signifie qu’un compte ordinaire peut démarrer le client et terminer une connexion. Aucune modification de l’hôte signifie que la machine semble identique après votre sortie. Les pages de téléchargement qui disent portable ne promettent généralement que la première de ces choses, et les deux autres sont là où les déploiements échouent. Une compilation peut aussi être portable au sens étroit : elle s’exécute depuis un support en lecture seule sans aucune écriture de fichier point, ce qui ne dit toujours rien de la pile réseau.

Les promesses coûteuses sont la deuxième et la troisième. Un seul exécutable qui a besoin d’un adaptateur, d’une route ou d’une écriture dans le résolveur demande au système d’exploitation une autorité que l’étiquette portable n’a jamais couverte.

Trouvez l’assistant privilégié que le client appellera

Presque aucun client VPN ne déplace les paquets par lui-même. Sous Windows, le chemin des données passe par les filtres WFP et le Base Filtering Engine, sous macOS par un fournisseur NetworkExtension que l’utilisateur approuve dans Réglages du système, et sous Linux par un périphérique tun plus la pile de routage. Le binaire que vous avez copié est une surface de contrôle pour ces composants, pas un substitut. Demandez quel composant le client attend, puis confirmez qu’il est installé, en cours d’exécution et utilisable par votre compte.

Linux est l’endroit le plus simple pour le prouver, car la vérification tient en un appel système. Ouvrir /dev/net/tun et demander un périphérique au noyau exige CAP_NET_ADMIN, et la documentation du noyau sur TUN/TAP énonce à la fois la règle de propriété et la capacité. Lancez la sonde avec le compte qui démarrera le client, pas en root.

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

Une erreur de permission sur la ligne du milieu est la réponse que vous cherchiez : ce compte ne peut pas créer d’interface tunnel, donc tout client en espace utilisateur qui en a besoin échoue à la connexion plutôt qu’au téléchargement. La dernière ligne supprime le périphérique de test et n’affiche rien lorsqu’elle fonctionne. Si les deux lignes réussissent, l’hôte n’a rien changé de permanent.

Testez les changements de route et de résolveur avant la première connexion

Le tunnel scindé transforme une connexion en décision de routage, tandis qu’un tunnel complet la transforme en remplacement de la route par défaut. Les deux sont des écritures dans la pile réseau de l’hôte, et les deux échouent pour un compte non privilégié même lorsque le client démarre proprement. Le résolveur est la troisième écriture, et sur les hôtes systemd c’est généralement celle qui casse en dernier. Cet ordre compte quand vous décidez où dépenser une installation élevée.

Une sonde de route a besoin d’une destination qui vous importe vraiment, alors remplacez l’espace réservé ci-dessous par un sous-réseau de votre propre profil. Le nom du périphérique doit exister pour que la route puisse s’accrocher à quelque chose.

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 première ligne renvoie RTNETLINK answers: Operation not permitted, le compte ne peut pas installer la route privée qu’exige le profil. La seconde ligne prouve le même droit à l’envers, ce qui compte parce qu’un client qui peut ajouter des routes mais pas les retirer laisse une table cassée derrière lui. La requête au résolveur montre ensuite si les noms privés se résolvent via le tunnel ou fuient vers le résolveur auquel l’hôte fait déjà confiance.

Lancez les trois pendant que le périphérique de test existe encore, puis supprimez-le. Une route qui pointe vers un périphérique disparu est la raison la plus courante pour laquelle un portable perd la connectivité après une connexion échouée.

Décidez ce qui doit survivre à la session

Supprimer le dossier n’est pas un plan de nettoyage. Les adaptateurs, les routes, les paramètres du résolveur, les certificats de confiance et les identifiants stockés peuvent chacun survivre au processus, et un service au démarrage peut en restaurer certains sans demander. Notez ce que le client a le droit de laisser derrière lui avant de le lancer, pas après la première déconnexion échouée.

La règle pratique est de photographier les trois surfaces que vous allez changer et de les comparer ensuite. Enregistrez les interfaces, la table de routage principale et l’état du résolveur avant la première connexion, puis répétez les trois mêmes lectures une fois le client sorti.

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

Tout ce qui est présent dans la seconde capture et absent de la première a besoin d’un propriétaire. Soit le client le retire à la sortie, soit vous le retirez avec les mêmes commandes qui l’ont créé, et ce retrait appartient aux notes de déploiement plutôt qu’à la mémoire de quelqu’un sur ce qui s’est passé. Sous Windows, les lectures équivalentes sont Get-NetAdapter, Get-NetRoute et Get-DnsClientServerAddress, qui n’exigent aucune élévation mais montrent les mêmes restes.