Dateiübertragung und direkte LAN-Verbindung

Agent, Exchange, CLI, Webkonsole und mobile Konsole unterstützen Dateiübertragung. Unterstützte Geräte melden die Fähigkeit files.

Dateiübertragung

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

Vorhandene Dateien werden standardmäßig nicht überschrieben. Erlauben Sie dies beim Upload oder Download ausdrücklich mit --overwrite. In der CLI bricht Strg+C ab; Web- und Mobilkonsole bieten eine Abbrechen-Schaltfläche. Im Web erfolgt die Bedienung unter „Dateien“ in den Gerätedetails, mobil unter „Dateiübertragung“ in den Gerätedetails.

Übertragen wird in bestätigten Blöcken von 64 KiB. Die Obergrenze je Datei beträgt 1 GiB, für Webdownloads 128 MiB; größere Dateien übertragen Sie per CLI oder mobiler Konsole. Verzeichnislisten enthalten höchstens 1000 Einträge; rekursive Verzeichnisuploads werden nicht unterstützt. Uploads schreiben eine temporäre Datei im Zielverzeichnis und ersetzen das Ziel nach vollständigem Empfang atomar. Abbruch, Verbindungsverlust oder Timeout entfernt unvollständige temporäre Dateien. Auch CLI-Downloads verwenden temporäre Dateien. Die mobile App lädt in den Cache und ruft danach die Systemfunktion zum Teilen/Speichern auf.

Dateizugriffe verwenden die Systemrechte des Agent-Prozesses und sind nicht auf ein Freigabeverzeichnis beschränkt. Schreibgeschützte Konten dürfen weder Verzeichnisse auflisten noch hoch- oder herunterladen. Exchange behält Workspace-Zugehörigkeit, Sitzungsisolation und Auditprotokollierung bei und protokolliert keine Dateiinhalte. Unter Android bezeichnet . das Dateiverzeichnis der Agent-App. Andere Verzeichnisse unterliegen Android-Berechtigungen; die Systemsandbox lässt sich nicht umgehen.

Internetdateien über den Agent herunterladen

Im Web-Dateibereich eine HTTP/HTTPS-URL eingeben oder file DEVICE fetch URL LOCAL ausführen. Der Agent lädt über sein eigenes Netzwerk und überträgt direkt zum Console-Rechner, ohne die Datei auf dem Agent zu speichern. Web: maximal 128 MiB; CLI: 1 GiB. Abbruch, Verbindungsfehler und andere Fehler verwerfen unvollständige Dateien. Vorhandene CLI-Zieldateien erfordern --overwrite. Native Agents für Desktop, Linux, Android und OpenWrt unterstützen dies; die Browser-Erweiterung bietet keine Dateiübertragung. Zertifikate werden geprüft. Zugangsdaten in URLs und HTTPS-Downgrades werden abgelehnt; höchstens fünf Weiterleitungen.

Der Download übernimmt kein --insecure des Verwaltungsservers.

HTTP-Anfragen im curl-Format

Einen curl-Befehl im HTTP-Bereich des Geräts einfügen. Die Console sendet eine versiegelte Anfrage an den Agent und zeigt Status, Dauer, Header und Inhalt. Unterstützt werden -X/--request, -H/--header, -d/--data, --data-raw, Inline---data-binary, --json, -I/--head, -L/--location, -m/--max-time und --url. Shell-Ausdrücke und @file werden nicht ausgeführt oder gelesen. Native Agents benötigen kein installiertes curl. Die Erweiterung benötigt Website-Berechtigungen, sendet keine Browser-Cookies und lehnt verbotene Header ab. Bei von Chromium verborgenen Weiterleitungen die endgültige URL verwenden. Lesezugriff allein reicht nicht aus. Anfrageinhalt: maximal 256 KiB; Zeitlimit: 120 Sekunden. Antworten werden bei nativen Agents auf 1 MiB und in der Erweiterung auf 128 KiB gekürzt und entsprechend markiert. Binärdateien und größere Downloads über den Dateiabruf übertragen.

Die versiegelte Nachricht heißt net_req. Browser-Funktion: net. Entsprechender CLI-Befehl: 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"}'

LAN-Steuerport

Die LAN-Steuerung ist standardmäßig deaktiviert; der Standard-TCP-Port ist 7277. Aktivieren Sie sie ausschließlich in vertrauenswürdigen LANs. Vorher muss das Gerät die Workspace-Wurzel fest gespeichert haben (remote-agent seal root oder TOFU bei einer vorherigen Exchange-Verbindung). Es gibt kein LAN-Zugriffstoken. Leiten Sie den Port nicht ins öffentliche Internet weiter.

Ergänzen Sie die vorhandene Agent-JSON-Konfiguration:

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

Behalten Sie server, device_id und token bei. Alternativ stehen --lan-enabled, --lan-port oder REMOTE_LAN_ENABLED, REMOTE_LAN_PORT zur Verfügung. Ohne fest gespeicherte Workspace-Wurzel verweigert der Agent bei aktiviertem LAN den Start.

Desktop-Konfigurationsseite und LuCI-Einstellungen bieten einen Schalter. Starten Sie den Agent nach Änderungen neu; auf der Desktop-Seite muss zuvor die Verbindung gestoppt werden. Nach Deaktivierung und Neustart lauscht der Port nicht mehr. Das Programm legt keine Firewall-Freigaben automatisch an.

Schreiben Sie für CLI-Direktverbindungen eine separate Konfiguration. Verwenden Sie nicht login, da dieses ein nicht leeres Token verlangt. Setzen Sie server auf http://IP:7277 des Geräts und lassen Sie token leer; Anfragen senden kein Authorization:

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

Mit REMOTE_CLI_CONFIG können Sie diese Datei auswählen und eine getrennte Cloudanmeldung behalten. Versiegelte Identität und Berechtigungscache liegen im Verzeichnis dieser Konfiguration: Offline-Grants in seal-grants.json, Zertifikatsketten mit dem von der Wurzel signierten Zertifikat zuerst in seal-chains.json. Alle Geräteoperationen öffnen ausschließlich versiegelte Sitzungen, auch bei direkt verbundenen Geräten, deren Gerätekarte local trägt oder deren LAN-Adresse unter /api/auth/me 401 zurückgibt. Der Agent stellt diese Berechtigungen weder aus noch verlängert er sie. Ohne Cloud funktionieren nur noch gültige gecachte Berechtigungen mit Root-Kette. sessions und session-kill sind nicht verfügbar: Das LAN bietet kein Sitzungsverzeichnis; Gerätesitzungen werden weiter von Exchange verwaltet.

Die Direktverbindung stellt nur das lokale Gerät bereit. Die äußere Zugriffsschicht akzeptiert ausschließlich private, linklokale oder Loopback-Adressen und prüft Origin. GET /api/devices liefert nach diesen Prüfungen nur Geräte-ID und die für den versiegelten Handshake nötigen Werte seal_key / seal_mode. GET /api/auth/me liefert vor diesem Handshake keine Operatoridentität. GET /ws/operator akzeptiert ausschließlich versiegelte Sitzungen und bietet keinen Kompatibilitätspfad für Klartext.

In der Hello-Nachricht von open_sealed übermittelt der Client eingebettet den Nachweis seines öffentlichen Operator-Schlüssels, den genannten Offline-Grant (hello.grant) und optional die Zertifikatskette (hello.chain, Root-Signatur zuerst). Das Gerät prüft die lokale Wurzel, den Gerätebereich und die Berechtigungsstufe view/manage nach denselben Regeln wie über Exchange; Sitzungsinhalte bleiben versiegelt. Die Webkonsole verbindet Geräte weiterhin über Exchange. Standardmäßig wird an allen IPv4-Schnittstellen gelauscht; die Funktion bleibt ohne Cloud verfügbar. Fehler beim LAN-Binden werden protokolliert, während die Cloud-Wiederverbindung weiterläuft.

Regressionstests

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

Benötigt werden Python 3.11+ und websockets. Verwenden Sie unter Windows .exe-Pfade und --platform windows. Die Tests nutzen temporäre Konfigurationen und Dateien und verändern weder bestehende Anmeldungen noch Geräte.