Transfert de fichiers et connexion directe sur le réseau local

L’Agent, Exchange, le CLI, la console Web et la console mobile prennent en charge le transfert de fichiers. Les appareils compatibles déclarent la capacité files.

Transfert de fichiers

remote-cli file i5m ls /tmp
remote-cli file i5m upload ./example.zip /tmp/example.zip
remote-cli file i5m download /tmp/example.zip ./downloaded.zip
remote-cli file i5m fetch https://example.com/example.zip ./example.zip

Par défaut, les fichiers existants ne sont pas écrasés ; ajoutez --overwrite au téléversement ou au téléchargement pour l'autoriser. Ctrl+C annule dans le CLI ; les consoles Web et mobile proposent un bouton d'annulation. Sur le Web, utilisez l'onglet « Fichiers » des détails de l'appareil ; sur mobile, ouvrez « Transfert de fichiers » depuis ces détails.

Le transfert utilise des blocs de 64 Kio, chacun acquitté avant le suivant. La limite est de 1 Gio par fichier, et de 128 Mio pour les téléchargements Web ; utilisez le CLI ou la console mobile pour les fichiers plus volumineux. Un répertoire renvoie au plus 1000 entrées ; le téléversement récursif de répertoires n'est pas pris en charge. Le téléversement écrit un fichier temporaire dans le répertoire cible, puis le remplace atomiquement après réception complète. Annulation, déconnexion ou expiration nettoient les fichiers temporaires incomplets. Le téléchargement CLI utilise aussi un fichier temporaire ; le mobile télécharge dans son cache puis appelle le partage ou l'enregistrement du système.

L'accès aux fichiers utilise les droits système du processus Agent et n'est pas limité à un répertoire partagé. Les comptes en lecture seule ne peuvent ni lister les répertoires, ni téléverser, ni télécharger. Exchange applique toujours le cloisonnement par espace de travail de l’appareil, l’isolation des sessions et l’audit des opérations, sans enregistrer le contenu des fichiers. Sous Android, . désigne le répertoire de fichiers de l'application Agent ; l'accès aux autres répertoires dépend des autorisations Android et ne contourne pas le bac à sable système.

Télécharger depuis Internet via l’Agent

Saisissez une URL HTTP/HTTPS dans les fichiers de la console Web, ou lancez file DEVICE fetch URL LOCAL. L’Agent télécharge avec son propre réseau et transmet le fichier à l’ordinateur Console sans le stocker sur l’Agent. Limites : 128 MiB sur le Web, 1 GiB en CLI. Une annulation, déconnexion ou erreur élimine les fichiers incomplets ; remplacer une destination CLI exige --overwrite. Les Agents natifs pour ordinateur, Linux, Android et OpenWrt sont compatibles ; l’extension ne transfère pas de fichiers. Les certificats sont vérifiés. Les identifiants dans l’URL et les passages de HTTPS à HTTP sont refusés ; cinq redirections au maximum.

Le téléchargement ne reprend pas --insecure du serveur de gestion.

Requêtes HTTP au format curl

Collez une commande curl dans l’onglet HTTP de l’appareil. La Console envoie une requête scellée à l’Agent et affiche le statut, la durée, les en-têtes et le corps. Options : -X/--request, -H/--header, -d/--data, --data-raw, --data-binary en ligne, --json, -I/--head, -L/--location, -m/--max-time, --url. Aucun shell n’est exécuté et aucun @file n’est lu. Les Agents natifs ne nécessitent pas curl. L’extension exige les autorisations du site, n’envoie pas les cookies du navigateur et refuse les en-têtes interdits. Utilisez l’URL finale si Chromium masque une redirection. Les droits de lecture seule ne permettent pas l’envoi. Corps limité à 256 KiB et délai à 120 secondes ; réponse tronquée et signalée à 1 MiB sur les Agents natifs ou 128 KiB dans l’extension. Utilisez le téléchargement de fichiers pour les données binaires ou volumineuses.

Le message scellé est net_req. Capacité du navigateur: net. Équivalent CLI : remote-cli net DEVICE http URL -X POST -H 'Content-Type: application/json' -d '{"message":"hello"}'

curl -X POST 'https://example.com/api' -H 'Content-Type: application/json' --data-raw '{"message":"hello"}'

Port de contrôle du réseau local

Le contrôle LAN est désactivé par défaut ; son port TCP par défaut est 7277. Activez-le uniquement sur un réseau local de confiance. Avant l'activation, l'appareil doit avoir fixé la racine de l'espace de travail (remote-agent seal root, ou connexion préalable à Exchange pour effectuer le TOFU). Il n'existe aucun jeton d'accès LAN. Ne redirigez pas ce port vers Internet.

Ajoutez à la configuration JSON existante de l'Agent :

{
  "lan_enabled": true,
  "lan_port": 7277
}

Conservez les champs server, device_id et token existants. Vous pouvez aussi utiliser --lan-enabled, --lan-port, ou REMOTE_LAN_ENABLED, REMOTE_LAN_PORT. Sans racine d'espace de travail fixée, l'activation LAN empêche le démarrage.

Les pages de configuration du bureau et de LuCI proposent un interrupteur. Redémarrez l'Agent après modification ; la page du bureau exige d'abord l'arrêt de la connexion. Après désactivation et redémarrage, ce port n'est plus écouté. Le programme ne crée pas automatiquement de règle d'autorisation du pare-feu.

Créez une configuration distincte pour la connexion directe CLI, sans login (qui exige un jeton non vide). Définissez server sur http://IP:7277 de l'appareil et laissez token vide ; les requêtes n'incluent pas Authorization :

server = "http://192.168.1.20:7277"
token = ""

Pointez REMOTE_CLI_CONFIG vers ce fichier pour conserver séparément votre connexion cloud. L'identité scellée et le cache d'autorisations résident dans le même répertoire : autorisations hors ligne dans seal-grants.json, chaînes de certificats avec émission racine en premier dans seal-chains.json. Toutes les opérations sur les appareils ouvrent exclusivement des sessions scellées, y compris pour les appareils en connexion directe dont la carte porte local ou dont /api/auth/me à l’adresse LAN renvoie 401. L'Agent n'émet ni ne renouvelle ces autorisations. Lorsque le cloud est hors ligne, seules les autorisations de chaîne racine encore valides dans le cache sont utilisables. sessions et session-kill sont indisponibles : le LAN n'a pas d'annuaire de sessions, les sessions de l'appareil restant gérées par Exchange.

La connexion directe expose uniquement l'appareil local. La couche externe accepte seulement les adresses privées, locales au lien ou de boucle locale et vérifie Origin. Après ces contrôles, GET /api/devices ne renvoie que l'identifiant de l'appareil et seal_key / seal_mode, nécessaires à la négociation scellée. GET /api/auth/me ne renvoie aucune identité d'opérateur avant cette négociation. GET /ws/operator accepte uniquement des sessions scellées et ne propose aucun chemin de compatibilité en clair.

Dans le hello d'open_sealed, le client joint la preuve de clé publique opérateur, l'autorisation hors ligne en cache (hello.grant) et la chaîne de certificats facultative (hello.chain, émission racine en premier). L'appareil vérifie la racine locale, le périmètre des appareils et view/manage selon les mêmes règles que le chemin Exchange ; le contenu des sessions reste scellé. La console Web continue de se connecter aux appareils via Exchange. L'écoute utilise par défaut toutes les interfaces IPv4 et reste utilisable hors ligne du cloud. Un échec de liaison LAN est journalisé et les reconnexions cloud continuent.

Vérification de non-régression

python scripts/file-transfer-smoke.py --agent target/debug/remote-agent --cli target/debug/remote-cli
python scripts/agent-ui-smoke.py --agent target/debug/remote-agent --platform linux

Python 3.11+ et websockets sont nécessaires. Sous Windows, utilisez les chemins .exe et --platform windows. Les tests utilisent des configurations et fichiers temporaires sans modifier les connexions ni les appareils existants.