# Dateiübertragung und direkte LAN-Verbindung > HTML: https://remote.ivjn.us/docs/de/files-and-lan/ Agent, Exchange, CLI, Webkonsole und mobile Konsole unterstützen Dateiübertragung. Unterstützte Geräte melden die Fähigkeit `files`. ## Dateiübertragung ```sh 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"}'` ```sh 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: ```json { "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`: ```toml 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 ```sh 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.