Hiatus Remote

Administratorhandbuch

Relay-Server betreiben, Client verteilen, Host-Dienst einrichten, Installer-Parameter, Härtung, Grenzen einer Sitzung.

Für Administratoren, die den Relay-Server betreiben, den Client verteilen und den Host-Dienst für unbeaufsichtigten Zugriff einrichten. Die Bedienung beschreibt das Benutzerhandbuch; Bauen aus den Quellen die README.

1. Komponenten und Netz

Komponente	Programm	Aufgabe
Relay-Server	`hiatus-relay`	Vergibt IDs, vermittelt Verbindungen, leitet weiter, wenn keine Direktverbindung möglich ist. Sieht keine Inhalte (Ende-zu-Ende-Verschlüsselung).
Client	`hiatus-client`	Oberfläche für Supporter und Target.
Host-Dienst	`hiatus-service` + `hiatus-agent` (+ `hiatus-pty-host` unter Windows)	Optional: Erreichbarkeit ohne angemeldeten Benutzer, Anmeldebildschirm, Strg+Alt+Entf, Benutzerwechsel. Der Agent läuft in der jeweiligen Benutzer- bzw. Anmeldesitzung; `hiatus-pty-host` hält für die Remote Shell Terminal und Shell als der angemeldete Benutzer (nicht als SYSTEM).

Ports am Relay-Server: derselbe Port für TCP (TLS 1.3, Signalisierung) und UDP (Hole Punching und Weiterleitung), Standard 443. Dazu ein zweiter UDP-Port nur für Adressabfragen (Standard: UDP-Port + 1, also 444; --udp-probe-port, 0 = aus): Daran erkennen Clients, ob ihr NAT je Ziel neue Ports vergibt (symmetrische NAT, z. B. Firmen-Firewalls), und suchen dann gezielt einen Direktweg. Clients brauchen ausgehend TCP und UDP zu diesen Ports. Sie versuchen zuerst eine Direktverbindung (UDP Hole Punching, auch über IPv6) und nutzen sonst das Relay. Sind beide im selben lokalen Netz, hat dessen Adresse Vorrang vor dem Umweg über die öffentliche Adresse des Routers (NAT-Loopback läuft durch dessen Internet-Warteschlange und wird bei ausgelasteter Leitung sehr langsam); antwortet die lokale Adresse nicht binnen 200 ms (z. B. Gäste-WLAN mit Client-Isolation), geht es über die öffentliche. Das Relay läuft per UDP oder, wenn UDP gesperrt ist, über die TLS-Verbindung (TCP). Findet sich während einer Sitzung über das Relay doch ein Direktweg, wechselt die Sitzung ohne Unterbrechung dorthin (Audit-Log: „Weg gewechselt: direkt“). Die Portsuche schickt kurz bis zu ~1 200 kleine Pakete an verschiedene Ports; wo das unerwünscht ist (Angriffserkennung im Firmennetz), lässt sie sich unter Einstellungen → Netzwerk → Verbindungsaufbau → Portsuche bei symmetrischer NAT abschalten – im Dienstbetrieb nur als Administrator, mit Eintrag im Audit-Log. Solche Verbindungen laufen dann über das Relay.

Portweiterleitung mit anderen Ports außen als innen (Router „außen 18115 → intern 443“, NAS-Container, Docker): Die Clients nehmen den TCP-Port aus dem Zugangscode und rechnen die UDP-Ports selbst um – der Relay meldet seine lokalen Ports samt eigenem TCP-Port, der Client legt denselben Abstand an seinen eingetragenen Port an (UDP = TCP-Port, Adressabfrage = TCP-Port + 1 im Standard). Am Relay ist dafür nichts einzustellen; außen müssen nur dieselben Abstände gelten wie innen, also z. B. TCP 18115, UDP 18115 und UDP 18116 weiterleiten. Nur wenn außen andere Abstände nötig sind (etwa TCP 18115, aber UDP 20000), nennt man dem Relay die äußeren UDP-Ports fest: --public-udp-port <n> und --public-udp-probe-port <n> (Standard: öffentlicher UDP-Port + 1) – beim Relay als Programm, Windows-Dienst und unter systemd gleichermaßen; im Docker-Image HIATUS_RELAY_PUBLIC_UDP_PORT / HIATUS_RELAY_PUBLIC_PROBE_PORT. Das Log des Relays nennt beim Start, welche Abstände bzw. festen Ports gelten; das Client-Protokoll zeigt die umgerechneten Ports („Relay-Server: UDP … (gemeldet …, umgerechnet auf Port …)“).

Plattformen: Windows 10 (1809+)/11 und Linux mit X11. Wayland und macOS werden noch nicht unterstützt.

2. Relay-Server betreiben

Zertifikat und Pin

hiatus-relay --create-certificate server.crt server.key --common-name relay.example.org
hiatus-relay --print-pin server.crt

Der SPKI-Pin (sha256:…) ist der Fingerabdruck des öffentlichen Schlüssels. Clients und Dienste akzeptieren nur einen Server mit hinterlegtem Pin (TLS-Pinning, keine Zertifizierungsstelle nötig). Den privaten Schlüssel gut schützen: Wer ihn hat, kann sich als Ihr Server ausgeben.

Starten

hiatus-relay --cert server.crt --key server.key [--listen 0.0.0.0] [--port 443] [--database devices.db]

--database speichert die dauerhaften Geräte-IDs (ID ↔ öffentlicher Geräteschlüssel, keine Passwörter) in SQLite. Ohne die Option erhalten Geräte nach einem Neustart des Servers neue IDs.

Als Windows-Dienst

Als Administrator, mit virtuellem Dienstkonto:

sc.exe create HiatusRelay start= auto obj= "NT SERVICE\HiatusRelay" binPath= "\"C:\Program Files\Hiatus\hiatus-relay.exe\" --service --cert \"C:\ProgramData\Hiatus\server.crt\" --key \"C:\ProgramData\Hiatus\server.key\" --database \"C:\ProgramData\Hiatus\relay\devices.db\""
icacls C:\ProgramData\Hiatus\server.key /inheritance:r /grant:r "NT SERVICE\HiatusRelay:R" "BUILTIN\Administrators:F"
mkdir C:\ProgramData\Hiatus\relay
icacls C:\ProgramData\Hiatus\relay /inheritance:r /grant:r "NT SERVICE\HiatusRelay:(OI)(CI)M" "BUILTIN\Administrators:(OI)(CI)F"
sc.exe start HiatusRelay

Firewall: eingehend TCP und UDP auf den gewählten Port freigeben, dazu UDP auf den zweiten Port (Standard: Port + 1). Fehlt dieser, läuft alles weiter, nur ohne Portsuche hinter symmetrischer NAT.

Unter Linux (systemd)

packaging/linux/hiatus-relay.service nach /etc/systemd/system/ kopieren, Zertifikat und Schlüssel unter /etc/hiatus-relay/ ablegen (Schlüssel 0600, Besitzer root), dann:

systemctl daemon-reload
systemctl enable --now hiatus-relay
journalctl -u hiatus-relay

Die Geräte-Datenbank liegt unter /var/lib/hiatus-relay/devices.db.

In Docker (Linux)

Das Image hiatus-relay enthält das Relay für Linux-Docker-Hosts. Gebaut wird es unter Windows mit scripts\build-relay-image.cmd (aus dem Linux-Build); zum Mitnehmen liegen danach hiatus-relay-image-docker.tar (aktuelles Docker), hiatus-relay-image-qnap.tar (siehe unten) und compose.yaml in build\hiatus-relay-docker\. Auf dem Docker-Host:

docker load -i hiatus-relay-image-docker.tar
# compose.yaml anpassen: mindestens HIATUS_RELAY_PUBLIC_HOST
docker compose up -d
docker compose logs relay                    # Zugangscodes
docker compose cp relay:/data/hiatus.relay . # fertige Relay-Datei (Abschnitt 3)

hiatus-relay-image-qnap.tar enthält dasselbe Image als klassisches Docker-Archiv (größer, Schichten ungepackt) für ältere Docker-Versionen und NAS-Oberflächen (z. B. QNAP Container Station: Images → Importieren). Das Image ist für x86-64 gebaut; ARM-Geräte werden nicht unterstützt.

Beim ersten Start erzeugt der Container Zertifikat und Schlüssel im Volume /data, schreibt die Zugangscodes ins Log und legt die Relay-Datei /data/hiatus.relay an. Bei jedem weiteren Start bleiben Schlüssel und Geräte-IDs erhalten. Das Volume sichern: Ohne server.key brauchen alle Clients einen neuen Zugangscode, ohne devices.db bekommen die Geräte neue IDs. Beim Aktualisieren (neues Image) den Container mit demselben Volume neu anlegen – in der QNAP Container Station beim Neuanlegen unter Speicher das bestehende Volume für /data wählen, nicht ein neues. Erscheint im Log wieder „Erzeuge Zertifikat …“, wurde das Volume nicht übernommen.

Alle Parameter mit Erklärung stehen in packaging/docker/relay/compose.yaml:

Variable	Standard	Bedeutung
`HIATUS_RELAY_PUBLIC_HOST`	– (Pflicht)	Name/Adresse für die Clients, steht im Zugangscode; mehrere durch Komma
`HIATUS_RELAY_PORT`	443	TCP-Port (Anmeldung, Relay über TLS)
`HIATUS_RELAY_UDP_PORT`	wie TCP	UDP-Port (Adressabfrage, Relay)
`HIATUS_RELAY_PROBE_PORT`	UDP + 1	zweiter UDP-Port zum Erkennen symmetrischer NAT; `0` = aus
`HIATUS_RELAY_PUBLIC_PORT`	wie TCP	bei Portabbildung: TCP-Port von außen – nur für den Zugangscode im Log und in der Relay-Datei
`HIATUS_RELAY_PUBLIC_UDP_PORT`	–	nur bei anderen Abständen außen als innen: fester UDP-Port von außen (`--public-udp-port`)
`HIATUS_RELAY_PUBLIC_PROBE_PORT`	öffentl. UDP + 1	dasselbe für den zweiten UDP-Port (`--public-udp-probe-port`)
`HIATUS_RELAY_LISTEN`	0.0.0.0	Bind-Adresse im Container (`::` für IPv6)
`HIATUS_RELAY_CERT_NAME`	erster Host	Name im Zertifikat (nur beim ersten Start)
`HIATUS_RELAY_CERT_DAYS`	3650	Gültigkeit des Zertifikats (nur beim ersten Start)
`HIATUS_RELAY_EXTRA_PINS`	leer	weitere Pins im Zugangscode (Schlüsselwechsel)
`HIATUS_RELAY_VERBOSE`	0	`1` = ausführliches Log

Ports außen und innen gleich halten (443:443/tcp, 443:443/udp, 444:444/udp): Das Relay teilt den Clients seinen UDP-Port mit. Bildet der Docker-Host die Ports anders ab (z. B. QNAP Container Station: außen 18115/18116, im Container 443/444), rechnen die Clients die UDP-Ports selbst auf den Port im Zugangscode um (Kapitel 1, Portweiterleitung) – solange außen dieselben Abstände gelten. HIATUS_RELAY_PUBLIC_PORT=18115 sorgt nur dafür, dass Zugangscode und Relay-Datei den äußeren Port nennen. Am Router alle drei weiterleiten (TCP und UDP 18115, UDP 18116). Der Container läuft ohne root, ohne Zusatzrechte und mit schreibgeschütztem Dateisystem (außer /data).

Schlüsselwechsel

Clients akzeptieren bis zu vier Pins. Für einen geordneten Wechsel: neues Zertifikat erzeugen, den neuen Pin zusätzlich verteilen (Zugangscode mit zwei pin=), erst danach den Server umstellen und den alten Pin später entfernen.

3. Zugangscode erzeugen und verteilen

Benutzer richten den Client beim ersten Start mit einem Zugangscode ein:

hiatus://<server>:<port>?pin=<pin>[&pin=<zweiter pin>]

Beispiele:

hiatus://relay.example.org:443?pin=sha256:3f9a…c21e
hiatus://[2001:db8::10]:443?pin=sha256:3f9a…c21e

<server>: DNS-Name oder IP-Adresse (IPv6 in eckigen Klammern); ohne Port gilt 443.
<pin>: Ausgabe von hiatus-relay --print-pin; bis zu vier.
Andere Angaben sind nicht erlaubt; ein Code ohne Pin wird abgelehnt.

Verteilen Sie den Code über einen vertrauenswürdigen Weg (Intranet, signierte E-Mail, Ausdruck). Ein eingerichteter Client kann ihn unter Einstellungen → Netzwerk → Relay-Server → Zugangscode kopieren weitergeben.

Der Client prüft vor dem Speichern Erreichbarkeit, TLS 1.3, den Pin und die Protokollversion – ohne sich anzumelden.

Relay-Datei (`*.relay`)

Statt den Code jedem Benutzer zu geben, kann er als Datei mit der Endung .relay beiliegen (das Docker-Image legt sie als hiatus.relay an). Inhalt: der Zugangscode in einer Zeile; Leerzeilen und Zeilen, die mit # beginnen, zählen nicht; höchstens 4 KB.

# Hiatus Remote – Relay der Firma
hiatus://relay.example.org:443?pin=sha256:3f9a…c21e

Gesucht wird nur, solange kein Relay-Server eingerichtet ist. Liegen mehrere Dateien vor, gilt die neueste (Änderungszeit; bei Gleichstand der Name).

Client ohne Dienst: sucht im Datenverzeichnis des Benutzers und im Programmverzeichnis (C:\Program Files\Hiatus) und füllt den Einrichtungsdialog vor; der Benutzer bestätigt mit Prüfen und speichern. Mit Ohne Relay-Server fortfahren schließt er den Dialog (gemerkt; Direktverbindungen gehen weiter, einrichten später unter Einstellungen → Netzwerk → Relay-Server).
Host-Dienst (Windows): sucht nur in seinem Datenverzeichnis C:\ProgramData\Hiatus und übernimmt den Server ohne Rückfrage in service.conf – mit Eintrag im Audit-Log und in der Ereignisanzeige. Die Datei bleibt liegen; ist service.conf vorhanden, wird nicht mehr gesucht. Ein ungültiger Code steht als Fehler in der Ereignisanzeige.

Wer die Datei ablegen darf, bestimmt den Server. C:\ProgramData\Hiatus und C:\Program Files\Hiatus sind nur für Administratoren beschreibbar. Wer den Dienst mit einem eigenen --data-dir betreibt bzw. den Client außerhalb von C:\Program Files ablegt, muss diese Ordner ebenso schützen (nur SYSTEM und Administratoren schreiben) – Hiatus prüft das nicht. Eine Datei im eigenen Datenverzeichnis eines Benutzers betrifft nur diesen und wird von ihm im Dialog bestätigt.

4. Client verteilen und vorkonfigurieren

Windows: Installer HiatusRemote-<version>-x64.msi (für alle Benutzer nach C:\Program Files\Hiatus). Er enthält Client, hiatus-decoder, Qt, die Visual-C++-Laufzeit und THIRD-PARTY-NOTICES.txt, legt eine Verknüpfung im Startmenü an und erlaubt dem Client direkte Verbindungen in privaten Netzen und der Domäne (Firewall). Der Host-Dienst ist ein wählbares Feature (Abschnitt 5). Der Installer ist nicht signiert (interne Nutzung): Beim ersten Start fragt SmartScreen nach („Weitere Informationen → Trotzdem ausführen“), die Benutzerkontensteuerung zeigt „Unbekannter Herausgeber“. Der Installationsordner erhält eigene, nicht geerbte Rechte wie unter C:\Program Files (Vollzugriff nur SYSTEM und Administratoren, sonst Lesen und Ausführen) – auch wenn Sie im Installer einen anderen Ordner wählen, etwa auf einem zweiten Laufwerk.

msiexec /i HiatusRemote-<version>-x64.msi                 & rem mit Dialogen
msiexec /i HiatusRemote-<version>-x64.msi /qn             & rem still, nur Client
msiexec /i HiatusRemote-<version>-x64.msi /qn HIATUS_ACCESS_CODE="hiatus://relay.example.org:443?pin=sha256:…"

Installer-Parameter (MSI)

Eigenschaften werden als NAME=Wert an msiexec angehängt (Werte mit Leerzeichen oder & in Anführungszeichen).

Parameter	Werte	Wofür
`ADDLOCAL`	`Client` oder `Client,Service`	Welche Teile installiert werden. `Client` ist immer dabei; `Service` = Host-Dienst für unbeaufsichtigten Zugriff (Abschnitt 5). Ohne Angabe: neu nur der Client, bei einem Upgrade dieselben Teile wie bisher.
`REMOVE`	`Service`	Einen Teil entfernen, z. B. nur den Dienst: `msiexec /i … REMOVE=Service`. Die Daten in `C:\ProgramData\Hiatus` bleiben dabei.
`HIATUS_ACCESS_CODE`	`hiatus://host:port?pin=sha256:…`	Relay-Server vorgeben (Abschnitt 3). Mit Dienst: Der Dienst übernimmt ihn beim Start in `service.conf` und ersetzt einen vorhandenen Server. Ohne Dienst: Der Code steht unter `HKLM\SOFTWARE\Hiatus\Remote\RelayAccessCode` (nur Administratoren schreiben dort) und füllt beim ersten Start den Einrichtungsdialog vor („aus der Installation übernommen“, Vorrang vor Relay-Dateien); der Benutzer bestätigt mit Prüfen und speichern.
`HIATUS_KEEP_DATA`	`1`	Nur beim Deinstallieren: Daten und Einstellungen behalten (siehe unten). Jeder nicht leere Wert gilt – auch `0`.
`INSTALLFOLDER`	Pfad	Anderes Programmverzeichnis als `C:\Program Files\Hiatus` (nur über die Befehlszeile; im Dialog ist der Ordner nicht wählbar). Der Installer setzt dort eigene, nicht geerbte Rechte wie unter `Program Files`: Vollzugriff nur SYSTEM und Administratoren, Benutzer und App-Container nur Lesen/Ausführen. Nur einen neuen oder von Administratoren angelegten, leeren Ordner angeben: Dateien, die schon vorher darin liegen, behalten ihre Rechte – hat ein Benutzer den Ordner angelegt und z. B. eine DLL hineingelegt, bliebe sie für Benutzer änderbar und würde vom Dienst als SYSTEM geladen. Den Ordner im Zweifel vorher löschen.

Allgemeine Schalter von msiexec:

Schalter	Wofür
`/i <msi>`	installieren bzw. aktualisieren
`/x <msi>`	deinstallieren (auch mit dem Produktnamen über Einstellungen → Apps)
`/qn`	ganz still, ohne Dialoge (Softwareverteilung)
`/qb` bzw. `/passive`	nur Fortschrittsanzeige, keine Fragen
`/l*v <datei>`	ausführliches Protokoll – bei Fehlern mitschicken
`/norestart`	nie neu starten (Hiatus braucht keinen Neustart)

Typische Aufrufe:

rem Arbeitsplatz eines Supporters (nur Client, Relay vorgegeben)
msiexec /i HiatusRemote-<version>-x64.msi /qn HIATUS_ACCESS_CODE="hiatus://relay.example.org:443?pin=sha256:…"

rem Rechner mit unbeaufsichtigtem Zugriff (Client und Dienst, Relay vorgegeben, Protokoll)
msiexec /i HiatusRemote-<version>-x64.msi /qn ADDLOCAL=Client,Service HIATUS_ACCESS_CODE="hiatus://relay.example.org:443?pin=sha256:…" /l*v hiatus-install.log

rem Aktualisieren: einfach das neue MSI installieren (Teile und Daten bleiben)
msiexec /i HiatusRemote-<neue version>-x64.msi /qn

rem Deinstallieren und alles entfernen bzw. Daten behalten
msiexec /x HiatusRemote-<version>-x64.msi /qn
msiexec /x HiatusRemote-<version>-x64.msi /qn HIATUS_KEEP_DATA=1

Aktualisieren: Das neue MSI ersetzt die installierte Version – auch bei gleicher Versionsnummer (jeder Build ist ein eigenes Produkt; ein Release-Kandidat wie 1.0.0-rc1 und die endgültige 1.0.0 haben im Installer dieselbe Nummer 1.0.0, die Vorabkennung steht im Dateinamen, in den Dateieigenschaften und im Client); REINSTALL/REINSTALLMODE sind nicht nötig. Installierte Teile, C:\ProgramData\Hiatus (ID, Schlüssel, unbeaufsichtigter Zugriff, Audit-Log, service.conf) und die Einstellungen der Benutzer bleiben; der Dienst wird angehalten und neu gestartet. Eine ältere Version lässt sich über eine neuere nicht installieren. Dieselbe MSI-Datei ein zweites Mal aufgerufen bietet nur Ändern, Reparieren und Entfernen an.

Laufende Programme: Vor dem Ersetzen oder Löschen von Dateien (Aktualisieren, Ändern, Reparieren, Deinstallieren) beendet der Installer alle laufenden Hiatus-Programme – den Client (auch im Infobereich und in anderen Benutzersitzungen), Agent, Pty-Host und Decoder; der Dienst wird angehalten. Offene Sitzungen brechen dabei ab, auch eine, über die gerade aus der Ferne installiert wird. Einen Neustart braucht es nicht.

Deinstallieren (Einstellungen → Apps, Rechtsklick auf die MSI-Datei → Deinstallieren bzw. msiexec /x) entfernt alles – gleich, ob mit oder ohne Administratorrechte gestartet (den geschützten Ordner C:\ProgramData\Hiatus löscht der Installer als SYSTEM):

Programme samt Programmordner, Dienst, Firewall-Regeln, Startmenü, Ereignisquelle und die Richtlinie für Strg+Alt+Entf (nur, wenn der Installer sie gesetzt hat),
C:\ProgramData\Hiatus mit Geräteschlüssel und ID, unbeaufsichtigtem Zugriff, Allowlist, Audit-Log, service.conf und Relay-Dateien,
HKLM\SOFTWARE\Hiatus,
für das deinstallierende Konto %LOCALAPPDATA%\Hiatus (Geräteschlüssel des Clients) und HKCU\Software\Hiatus (Einstellungen).

Danach erhält der Rechner bei einer Neuinstallation eine neue ID; Partner sehen die Warnung „Schlüssel geändert“, der unbeaufsichtigte Zugriff ist neu einzurichten, und das Audit-Log ist weg – wer Zugriffe nachweisen muss, sichert C:\ProgramData\Hiatus\audit.log vorher oder deinstalliert mit HIATUS_KEEP_DATA=1. Daten anderer Benutzerkonten (deren %LOCALAPPDATA%\Hiatus und HKCU\Software\Hiatus) erreicht der Installer nicht; bei Bedarf im jeweiligen Konto löschen:

rmdir /s /q "%LOCALAPPDATA%\Hiatus"
reg delete "HKCU\Software\Hiatus" /f

Linux: Programm mit den Qt-Bibliotheken der Distribution (Abschnitt 6); Pakete sind zurückgestellt.

hiatus-decoder gehört dazu: Bild, Ton und Bilder der Zwischenablage von der Gegenseite dekodiert ein eigener Prozess (hiatus-decoder.exe bzw. hiatus-decoder), den der Client aus seinem eigenen Verzeichnis startet. Er hat keine Schlüssel und keine Verbindung ins Netz; ein Fehler in einem Decoder (H.264, Opus, PNG) erreicht so den Client nicht. Fehlt die Datei, zeigt eine Fernsteuerung kein Bild, spielt keinen Ton und übernimmt keine Bilder aus der Zwischenablage der Gegenseite (Text geht weiter).

Auch der Sitzungs-Agent des Dienstes nutzt ihn: Ein Bild, das der Supporter in die Zwischenablage legt, dekodiert der Decoder-Prozess, nicht der Agent mit seinen SYSTEM-Rechten; fehlt hiatus-decoder.exe neben dem Agenten, landet das Bild nur als PNG in der Zwischenablage (Programme ohne PNG-Unterstützung können es dann nicht einfügen). Unter Windows läuft hiatus-decoder.exe in einer Sandbox: AppContainer Hiatus.Decoder (ohne Netz, ohne Zugriff auf Dateien und Registry des Benutzers, niedrige Integrität), in einem Job (ein Prozess, höchstens 1 GiB, endet mit dem Client) und mit strengen Prozess-Mitigationen (z. B. keine Win32k-Aufrufe, nur Microsoft-signierte DLLs). Dafür muss die Gruppe „ALL APPLICATION PACKAGES“ die Datei lesen und ausführen dürfen. Unter C:\Program Files ist das Standard; liegt der Client woanders, ergänzt er diesen Eintrag beim ersten Start selbst (nur auf hiatus-decoder.exe). Darf er die Rechte dort nicht ändern, den Eintrag als Administrator setzen: icacls hiatus-decoder.exe /grant *S-1-15-2-1:RX.

Unter Linux schränkt sich hiatus-decoder beim Start selbst ein, bevor er Daten der Gegenseite liest: seccomp-Filter (kein Öffnen von Dateien, kein Netz, keine neuen Prozesse, kein ausführbarer Speicher), no_new_privs, nicht ausspähbar, höchstens 1 GiB Speicher, endet mit dem Client. Wo das System unprivilegierte Namensräume erlaubt, erhält er zusätzlich eigene Namensräume (Benutzer, Netz, Mount); sonst (z. B. in Containern oder mit kernel.apparmor_restrict_unprivileged_userns=1) läuft er ohne sie – der seccomp-Filter gilt immer. Einrichten muss man dafür nichts.

Datenverzeichnis

C:\ProgramData\Hiatus enthält Geräteschlüssel, den Verifier des permanenten Passworts, die Einstellungen zum unbeaufsichtigten Zugriff mit Allowlist, service.conf und Relay-Dateien. Der Dienst prüft das Verzeichnis bei jedem Start, bevor er etwas daraus liest: Besitzer nur SYSTEM oder Administratoren, Zugriff nur für SYSTEM, Administratoren und virtuelle Dienstkonten (NT SERVICE\…), keine Verknüpfungen (Junction, Symlink). Fehlt es, legt er es mit diesen Rechten an. Ist etwas anders, startet der Dienst nicht und nennt in der Ereignisanzeige (Anwendung, Quelle HiatusRemote) die Datei und den Grund – z. B. „Zugriff für S-1-1-0“ (Jeder) oder „fremder Besitzer“.

Das passiert, wenn das Verzeichnis vor der Installation von einem Benutzer angelegt wurde oder Rechte von Hand geändert wurden. Weil dann auch Dateien untergeschoben sein können, nicht nur die Rechte reparieren:

Dienst anhalten (sc.exe stop HiatusRemote).
Den Inhalt prüfen. Im Zweifel das Verzeichnis löschen (rmdir /s /q C:\ProgramData\Hiatus) – der Rechner erhält dann eine neue ID, der unbeaufsichtigte Zugriff ist neu einzurichten; vorher ggf. audit.log sichern.
Installer reparieren (Einstellungen → Apps → Hiatus Remote → Ändern → Reparieren) bzw. den Dienst starten – das Verzeichnis entsteht neu mit den richtigen Rechten.

Einstellungen

Der Client speichert seine Einstellungen benutzerbezogen (QSettings, Organisation „Hiatus“, Anwendung „Remote“):

Windows: Registry HKEY_CURRENT_USER\Software\Hiatus\Remote
Linux: ~/.config/Hiatus/Remote.conf

Schlüssel	Bedeutung
`server`, `port`, `pins`	Relay-Server (Pins als Liste) – vorbelegt erscheint kein Einrichtungsdialog. Mit Host-Dienst übernimmt der Client dessen Server und speichert ihn hier.
`language`	`system`, `de` oder `en`
`rotationMinutes`	Wechsel des Einmal-Passworts in Minuten (Standard 10)
`newKeyPolicy`	0 = vertrauen, als „nicht bestätigt“ markieren; 1 = unbeaufsichtigt nur nach Bestätigung; 2 = sofort bestätigt
`matchResolution`	Auflösung des Ziels anpassen (unbeaufsichtigt)
`trayHintShown`	`true` = der einmalige Hinweis „Hiatus Remote läuft weiter“ beim ersten Minimieren in den Infobereich wurde gezeigt
`TargetBanner/pinned`	`true` = Hinweisleiste beim Zugriff auf diesen Rechner angeheftet (fährt nicht an den Rand)
`relaySkipped`	`true` = „Ohne Relay-Server fortfahren“ gewählt: kein Einrichtungsdialog beim Start (entfällt, sobald ein Server eingerichtet wird)
`logcat/filters`	Eigene gespeicherte Filter des Logcat Viewers (Name, Abfrage, Stufen; höchstens 30)
`logcat/window/…`, `logcat/sidebar…`, `logcat/details/height`, `logcat/columns/…`, `logcat/timeFormat`	Fensterlage, Seitenleiste, Detailhöhe, Spalten und Zeitformat des Logcat Viewers

Kommandozeile

Option	Bedeutung
`--server <host>`, `--port <port>`, `--pin <sha256:…>` (mehrfach)	Relay-Server; hat Vorrang vor den gespeicherten Einstellungen
`--data-dir <pfad>`	Datenverzeichnis (Geräteschlüssel). Je Datenverzeichnis läuft eine Instanz.
`--no-service`	Ohne Host-Dienst arbeiten, auch wenn er läuft
`--service-pipe`, `--service-owner`	Nur für Entwicklung (Konsolenmodus des Dienstes)

Daten

Geräteschlüssel und Verifier liegen im Datenverzeichnis des Benutzers (Windows typischerweise %LOCALAPPDATA%\Hiatus\Hiatus Remote), geschützt über den Schlüsselspeicher des Systems. Der Geräteschlüssel bestimmt die ID: Wer das Verzeichnis löscht, erhält eine neue ID, und Partner sehen die Warnung „Schlüssel geändert“. Das Deinstallieren mit dem MSI löscht dieses Verzeichnis für das deinstallierende Konto (behalten mit HIATUS_KEEP_DATA=1, siehe Installer-Parameter).

5. Host-Dienst unter Windows

Der Dienst gibt dem Rechner eine eigene ID, nimmt alle eingehenden Verbindungen an und startet den Sitzungs-Agenten in der aktiven Konsolensitzung (folgt Anmeldebildschirm, Sperre, UAC und Benutzerwechsel). Der Client verbindet sich beim Start automatisch mit dem Dienst und zeigt dessen ID; ausgehende Verbindungen baut er selbst auf. Das Einmal-Passwort und eingehende Anfragen erscheinen nur im Client der Konsolensitzung (dem Bildschirm des Rechners); ein Client in einer weiteren Sitzung, etwa per Remotedesktop auf einem Terminalserver, zeigt stattdessen einen Hinweis. Einstellungen zum unbeaufsichtigten Zugriff, zur Direktverbindung, gemerkte Geräte und den Verlauf sieht nur die Konsole oder ein Administrator. Das permanente Passwort ist davon nicht betroffen.

Einrichten mit dem Installer

Im MSI das Feature „Unbeaufsichtigter Zugriff (Dienst)“ wählen (im Dialog unter Benutzerdefiniert) oder still:

msiexec /i HiatusRemote-<version>-x64.msi /qn ADDLOCAL=Client,Service HIATUS_ACCESS_CODE="hiatus://relay.example.org:443?pin=sha256:…"

Der Installer

legt den Dienst HiatusRemote an (automatischer Start, LocalSystem, Neustart nach Absturz) und startet ihn,
legt C:\ProgramData\Hiatus nur für SYSTEM und Administratoren an (ohne geerbte Rechte),
setzt die Richtlinie für Strg+Alt+Entf (SoftwareSASGeneration = 1, Dienste) – nur, wenn sie noch nicht gesetzt ist; eine vorhandene Einstellung bleibt unverändert,
registriert die Ereignisquelle „HiatusRemote“ (Meldungen mit Text in der Ereignisanzeige) und
erlaubt dem Dienst direkte Verbindungen in privaten Netzen und der Domäne.

Zugangscode: Mit HIATUS_ACCESS_CODE (alle Parameter: Abschnitt 4, Installer-Parameter) übernimmt der Dienst den Relay-Server beim ersten Start in service.conf (der Code liegt dafür kurz unter HKLM\SOFTWARE\Hiatus\Remote\AccessCode und wird danach gelöscht; ein ungültiger Code steht als Fehler in der Ereignisanzeige). Ohne Code übernimmt der Dienst eine Relay-Datei aus C:\ProgramData\Hiatus (Abschnitt 3); fehlt auch sie, startet er ohne Server – dann den Client als Administrator starten und den Server unter Einstellungen → Netzwerk → Relay-Server einrichten.

Umstieg von der Einrichtung von Hand: vorher den alten Dienst entfernen (sc.exe stop HiatusRemote und sc.exe delete HiatusRemote), C:\ProgramData\Hiatus behalten – dann bleiben ID, Passwort und Einstellungen erhalten.

Einrichten von Hand (ohne Installer)

Als Administrator; Programme unter C:\Program Files\Hiatus\ (hiatus-service.exe, hiatus-agent.exe, hiatus-pty-host.exe):

mkdir C:\ProgramData\Hiatus
icacls C:\ProgramData\Hiatus /inheritance:r /grant:r "NT AUTHORITY\SYSTEM:(OI)(CI)F" "BUILTIN\Administrators:(OI)(CI)F"
notepad C:\ProgramData\Hiatus\service.conf
sc.exe create HiatusRemote start= auto DisplayName= "Hiatus Remote" binPath= "\"C:\Program Files\Hiatus\hiatus-service.exe\" --service"
sc.exe description HiatusRemote "Hiatus Remote: unbeaufsichtigter Fernzugriff (nur mit permanentem Passwort und Allowlist)"
sc.exe failure HiatusRemote reset= 86400 actions= restart/5000/restart/30000//
sc.exe start HiatusRemote

service.conf:

server=relay.example.org
port=443
pin=sha256:…          # bis zu 4 Zeilen

Das Datenverzeichnis enthält Geräteschlüssel, Verifier, Einstellungen und das Audit-Log; nur SYSTEM und Administratoren haben Zugriff.

Strg+Alt+Entf

Der Installer setzt die Richtlinie, wenn sie noch nicht gesetzt ist. Von Hand bzw. per Gruppenrichtlinie: Damit der Supporter Strg+Alt+Entf senden kann, die Gruppenrichtlinie „Software-Secure Attention Sequence deaktivieren oder aktivieren“ (Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Windows-Anmeldeoptionen) auf „Dienste“ stellen.

Aktualisieren und entfernen

Mit dem Installer: neues MSI installieren (der Dienst wird dabei angehalten und wieder gestartet; Daten und Einstellungen bleiben) bzw. Hiatus Remote unter Einstellungen → Apps entfernen. Das Deinstallieren löscht auch C:\ProgramData\Hiatus (ID, Schlüssel, unbeaufsichtigter Zugriff, Audit-Log) – behalten mit msiexec /x … HIATUS_KEEP_DATA=1; nur den Dienst entfernen mit msiexec /i … REMOVE=Service (Daten bleiben). Einzelheiten in Abschnitt 4 unter Installer-Parameter. Die Richtlinie für Strg+Alt+Entf entfernt der Installer nur, wenn er sie selbst gesetzt hat.

Von Hand:

sc.exe stop HiatusRemote
copy /y hiatus-service.exe "C:\Program Files\Hiatus\"
copy /y hiatus-agent.exe "C:\Program Files\Hiatus\"
copy /y hiatus-pty-host.exe "C:\Program Files\Hiatus\"
sc.exe start HiatusRemote

sc.exe stop HiatusRemote
sc.exe delete HiatusRemote

Das Datenverzeichnis bei Bedarf von Hand löschen (danach neue ID).

Einstellungen ändern

Einstellungen des unbeaufsichtigten Zugriffs und den Relay-Server ändert der Client, wenn er als Administrator läuft; andere Benutzer sehen sie nur. Läuft er ohne, bietet die Einstellungsseite „Als Administrator neu starten“ an (UAC); die neue Instanz übernimmt, die alte beendet sich. Meldet sich dabei ein anderes Administratorkonto an, läuft der Client mit dessen Benutzerdaten (eigene ID für ausgehende Verbindungen). Jede Änderung (und jeder abgewiesene Versuch) steht im Audit-Log.

Relay-Server des Dienstes ändern

Der Client übernimmt den Server des Dienstes für seine eigene Verbindung (ein Server je Rechner). Ändern: Client als Administrator starten → Einstellungen → Netzwerk → Relay-Server → Ändern … → Zugangscode → Prüfen und speichern. Der Client prüft den Server, der Dienst schreibt service.conf neu und verbindet sofort neu; laufende Sitzungen enden. Im Audit-Log steht „Relay-Server: host:port“ mit Urheber. Beim Neuschreiben gehen Kommentare in service.conf verloren; die übrigen Angaben bleiben.

Alternativ service.conf von Hand ändern und den Dienst neu starten.

6. Host-Dienst unter Linux

Der Dienst folgt der aktiven X11-Sitzung von seat0 (systemd-logind; Anmeldebildschirm und Benutzer). Einstellungen (auch den Relay-Server, wie unter Windows) ändert, wer in der aktiven Sitzung das Passwort eines Administrators eingibt (polkit-Aktion de.hiatus.remote.manage). Dateien und Shell laufen mit den Rechten des angemeldeten Benutzers.

install -d /usr/lib/hiatus
install -m 0755 hiatus-service hiatus-agent /usr/lib/hiatus/
install -m 0644 packaging/linux/de.hiatus.remote.policy /usr/share/polkit-1/actions/
install -d -m 0755 /etc/hiatus
install -m 0644 /dev/null /etc/hiatus/service.conf   # server=, port=, pin= eintragen
install -m 0644 packaging/linux/hiatus-service.service /etc/systemd/system/
systemctl daemon-reload
systemctl enable --now hiatus-service

/etc/hiatus/service.conf muss root gehören und darf für Gruppe und andere nicht schreibbar sein – sonst startet der Dienst nicht (wer die Datei ändern kann, könnte den Dienst auf ein fremdes Relay lenken). Ändert ein Administrator den Relay-Server über den Client, schreibt der Dienst die Datei neu (root, 0644). Daten unter /var/lib/hiatus (nur root), Sockets unter /run/hiatus, Meldungen mit journalctl -u hiatus-service.

7. Unbeaufsichtigten Zugriff einrichten

Unbeaufsichtigter Zugriff ist aus, bis er eingerichtet ist. Empfohlenes Vorgehen:

Starten Sie den Client am Zielrechner (mit Dienst: als Administrator).
Permanentes Passwort setzen: mindestens 12 Zeichen ohne Leerzeichen, kein häufiges Passwort. Gespeichert wird nur ein Argon2id-Verifier; nach drei Fehlversuchen werden eingehende Verbindungen kurz gesperrt (die Sperre verdoppelt sich bis höchstens eine Stunde, fällt nach 24 Stunden ohne Fehlversuch auf 30 Sekunden zurück und gilt für Internet und Direktverbindung gemeinsam). Ein Versuch zählt, sobald die Gegenseite ihn prüfen kann; höchstens zwei Anmeldungen laufen gleichzeitig, eine dritte wird abgewiesen und kann gleich wiederholt werden.
Nur zugelassene Supporter (Voreinstellung) beibehalten – andere Supporter werden dann schon vor der Passwortprüfung abgewiesen und können das permanente Passwort nicht ausprobieren. Einen Supporter nehmen Sie auf, indem er sich einmal beaufsichtigt verbindet, Sie den Fingerprint abgleichen und unter Aktive Sitzungen → Zulassen bestätigen. Entfernen Sie einen Supporter wieder aus der Liste, enden auch seine laufenden Sitzungen an diesem Rechner sofort.
Berechtigungen auf das Nötige beschränken.
Je nach Umgebung:

Einstellung	Empfehlung
Angemeldeten Benutzer fragen	An, wo Benutzer am Rechner arbeiten (Datenschutz).
Ohne Antwort zulassen	Nur für Rechner ohne ständige Besetzung.
Nach der Sitzung sperren	An lassen (Voreinstellung): keine offene Sitzung bleibt zurück.
Dateien und Shell am Anmeldebildschirm (als SYSTEM)	Aus lassen, außer es wird wirklich gebraucht.
Berechtigung „Tunnel“	Nur, wenn Supporter Dienste dieses Rechners erreichen müssen (z. B. Remote Debugger, Serveranwendung).
Berechtigung „Remote-Debugging“	Nur für Entwickler-Support. Ein Debugger führt faktisch Code im Zielprozess aus; nur vertrauenswürdigen Supportern geben.

Tunnel: Mit der Berechtigung „Tunnel“ erreicht der Supporter Ports dieses Rechners – ausschließlich über localhost (127.0.0.1 bzw. ::1), nie andere Rechner im Netz, und nur Ports, die er für die Sitzung angemeldet hat. Die Verbindung zum Dienst baut der Hiatus-Dienst bzw. der Client auf diesem Rechner auf; damit sind auch Dienste erreichbar, die nur auf localhost lauschen. Die Firewall muss dafür nichts freigeben. Der Benutzer sieht die Ports in der Hinweisleiste und kann alle Tunnel dort schließen. Mit derselben Berechtigung darf der Supporter die Prozesse mit TCP-Listener dieses Rechners abfragen (Remote-Prozess …, für die Auswahl der Ports): Name, PID, Dienst, Benutzer, Pfad, Ports und Bindungsadresse – nur Prozesse mit Listener, keine vollständige Prozessliste und keine Kommandozeilen. Mit Hiatus-Dienst fragt der Dienst ab (alle Prozesse sichtbar), ohne Dienst der Client mit den Rechten des Benutzers. Ports von HTTP.sys (Besitzer System) ordnet Hiatus über netsh http show servicestate view=requestq den Programmen zu, die dort URLs angemeldet haben (Windows bietet dafür keine öffentliche Schnittstelle; netsh wird aus System32 gestartet, höchstens 5 s). Tunnel gehen weiterhin nur zu den angemeldeten Ports auf localhost; Listener, die nur an eine Netzwerkadresse gebunden sind, bleiben unerreichbar.

Remote-Debugging: Mit der Berechtigung „Remote-Debugging“ startet Hiatus den Visual Studio Remote Debugger (msvsmon) dieses Rechners – nur, wenn die Remote Tools für Visual Studio installiert sind. Er läuft je nach Wahl unter dem angemeldeten Benutzer, als Administrator oder unter einem angegebenen Konto (Passwort nur verschlüsselt, einmalig für den Start, nicht gespeichert, nicht protokolliert). Hiatus startet die 64-Bit- und die 32-Bit-Variante zugleich und erreicht sie nur über localhost; die Firewall muss nichts freigeben. Beenden durch den Supporter, Sitzungsende oder Entzug der Berechtigung. Da ein Debugger Code im Zielprozess ausführt, ist die Berechtigung bewusst nur für vertrauenswürdige Supporter gedacht. Symbole überträgt Hiatus nur, wenn der Supporter dies ausdrücklich wählt (optionales Extra, standardmäßig aus): Die PDBs landen in einem nur für den Zielbenutzer lesbaren, temporären Ordner der Sitzung, und _NT_SYMBOL_PATH wird nur in der Prozessumgebung von msvsmon gesetzt – es wird keine Systemvariable verändert und keine Administratorrechte gebraucht; der Ordner wird beim Beenden wieder gelöscht.

Am Anmeldebildschirm sind Dateien und Shell ohne diese Erlaubnis nicht verfügbar. Mit angemeldetem Benutzer laufen sie mit dessen Rechten; wechselt der Benutzer an der Konsole, folgen sie dem neuen Benutzer, und Shells des vorigen werden beendet. Das gilt auch mitten in einer Sitzung: Beginnt sie am Anmeldebildschirm und meldet sich jemand über die Fernsteuerung an, stehen Dateien und Shell nach wenigen Sekunden zur Verfügung; nach einer Abmeldung sind sie wieder gesperrt.

Hinweis: Ein permanentes Passwort ist an die ID gebunden. Nach einem Wechsel des Relay-Servers (neue ID) muss es neu gesetzt werden.

Direktverbindungen (ohne Relay-Server)

Für Rechner ohne Internet, die der Supporter über ein VPN erreicht (typisch: Windows-Server beim Kunden). Der Rechner nimmt Verbindungen dann selbst an – über ein eingebautes Relay auf einem eigenen Port. Anmeldung (Einmal- oder permanentes Passwort), Rückfrage, Allowlist, Berechtigungen, Audit-Log und Ende-zu-Ende-Verschlüsselung bleiben unverändert; die Sitzung läuft direkt über das VPN. Die Anmeldung beim Internet-Relay (falls erreichbar) bleibt daneben bestehen.

Einrichten unter Einstellungen → Netzwerk → Direktverbindungen (Standard aus; im Dienstbetrieb nur als Administrator, jede Änderung steht im Audit-Log):

Feld	Bedeutung
Direktverbindungen annehmen	Ein/aus. Aus beendet laufende Direktsitzungen.
Port (TCP und UDP)	Standard 47443; frei wählbar.
Nur an dieser Adresse annehmen	Leer = alle Schnittstellen; sonst eine Adresse dieses Rechners (z. B. die im VPN erreichbare). Fehlt sie (VPN-Adapter getrennt), versucht Hiatus es alle 10 Sekunden erneut.
Nur aus diesen Netzen	Erlaubte Absender, CIDR oder einzelne Adressen, getrennt durch Komma (z. B. `10.20.0.0/16, 192.168.5.7`). Leer = alle. Andere werden vor jeder Anmeldung getrennt.

Nach Übernehmen zeigt die Karte „Erreichbar unter 10.20.5.17:47443“ und den Fingerabdruck des Rechners (Zertifikat, einmal erzeugt). Geben Sie dem Supporter Adresse und Port; er gibt sie im Verbinden-Feld statt der Partner-ID ein (z. B. 10.20.5.17 oder 10.20.5.17:5000), sieht den Fingerabdruck bei der ersten Verbindung und sollte ihn mit Ihnen abgleichen. Sein Hiatus merkt sich Adresse und Fingerabdruck. Ist der Port belegt, nennt die Karte den Grund.

Firewall: Der Installer erlaubt dem Hiatus-Dienst eingehende Verbindungen in privaten Netzen und der Domäne – für jeden Port, ein geänderter Port braucht also keine neue Regel. Ist die Netzwerkverbindung, über die der Supporter kommt, als öffentlich eingestuft, geben Sie den Port (TCP und UDP) selbst frei oder stufen das Netz als privat ein. Ohne Dienst nimmt der Client die Verbindungen an; für ihn gilt dieselbe Freigabe.

IDs: Der Rechner behält auch ohne Internet seine Hiatus-ID; Supporter behalten ihre ebenfalls. Permanentes Passwort und Allowlist gelten daher unverändert. Hatte der Rechner nie Verbindung zu einem Internet-Relay, vergibt das eingebaute Relay die ID.

8. Protokolle und Nachvollziehbarkeit

Jede Sitzung auf einem Rechner wird festgehalten: Beginn, Dauer, Supporter-ID und Schlüssel, beaufsichtigt oder nicht, Berechtigungen, genutzte Funktionen (Dateien, Shell, …), Ende und Grund; dazu abgewiesene Versuche, falsche Passwörter, Sperren und Änderungen der Einstellungen mit Urheber. Ordner stehen mit einem Eintrag je Ordner im Audit-Log („Ordner auf diesen Rechner übertragen: C:\Ziel\Logs (12 Dateien, … Byte)“) – gezählt vom Rechner selbst, spätestens beim Sitzungsende; angehaltene Dateien zählen dabei nicht als fehlgeschlagen. Dateioperationen des Supporters im Dateibrowser stehen einzeln im Audit-Log: „Ordner angelegt: …“, „Umbenannt: … → …“, „Gelöscht: … (n Einträge)“, „Dupliziert: … → …“, „Verschoben: … → …“, „Kopiert: … → …“, „Archiv erstellt: … (n Einträge)“ und „Auf dem Zielrechner geöffnet: …“ – letzteres nur mit den Berechtigungen Dateien übertragen und Remote Shell, weil damit Programme gestartet werden können (z. B. eine hochgeladene .exe); am Anmeldebildschirm nie; das Anzeigen von Eigenschaften und die Suche in Unterordnern nicht (gelesen wird dabei nur, was auch das Öffnen der Ordner zeigt). Tunnel stehen mit Ziel beim Öffnen und Schließen im Audit-Log („Tunnel geöffnet: localhost:4026“), jede Abfrage der Listener als „Prozesse mit Netzwerk-Listenern abgefragt“. Der Remote Debugger steht mit Konto, Anmeldemodus und Ports im Audit-Log („Remote Debugger gestartet: … / beendet“), nie mit Passwort. Beim Supporter vermerkt das Programmprotokoll Start und Ende seiner Tunnel.

Ort	Inhalt
Windows-Ereignisanzeige, Anwendung, Quelle „HiatusRemote“	Meldungen des Dienstes (Text derzeit unter „Details“, siehe Kapitel 11)
`journalctl -u hiatus-service`	dto. unter Linux
`audit.log` im Datenverzeichnis des Dienstes bzw. Clients	Audit-Datensätze (binär, 1 MiB, eine Rotation `.1`)
Client: Einstellungen → Sicherheit → Verlauf der Zugriffe	Lesbare Übersicht der Sitzungen

Benutzer sehen nach unbeaufsichtigten Zugriffen beim nächsten Start den Hinweis „Zugriffe während Ihrer Abwesenheit“.

Leistungsmessung der Bildübertragung (Diagnose, standardmäßig aus)

Für die Analyse von Bildqualität und Bildrate (z. B. „ruckelt über Mobilfunk“) können Supporter und Zielrechner je Sekunde Messwerte in eine eigene Datei schreiben. Im normalen Betrieb ist das aus; eingeschaltet wird es nur über die Umgebungsvariable HIATUS_VIDEO_STATS. Die Datei enthält nur Messwerte (Bildrate, Datenrate, Laufzeit, Verzögerung, Aufnahme- und Kodierzeit, Stufe der Qualitätsregelung und ihre Gründe) – keine Bildinhalte, Dateinamen oder Eingaben.

Wert: Pfad der Messdatei, z. B. C:\Hiatus-Messung\ziel.log; der Ordner wird bei Bedarf angelegt, neue Zeilen werden angehängt (Datei bei Bedarf selbst löschen). Ein Wert ohne \ bzw. / (z. B. 1) schreibt nach hiatus-video-stats.log im Temp-Ordner des Prozesses. Das normale Protokoll nennt beim ersten Schreiben einmal die Datei.
Supporter (Client): Variable setzen und den Client aus derselben Eingabeaufforderung starten, z. B.
```
set HIATUS_VIDEO_STATS=C:\Hiatus-Messung\supporter.log
"C:\Program Files\Hiatus\hiatus-client.exe"
```
Ein bereits laufender Client muss vorher beendet werden.
Zielrechner mit Host-Dienst (unbeaufsichtigt) – als Administrator:
```
reg add HKLM\SYSTEM\CurrentControlSet\Services\HiatusRemote /v Environment /t REG_MULTI_SZ /d HIATUS_VIDEO_STATS=C:\Hiatus-Messung\ziel.log /f
sc stop HiatusRemote
sc start HiatusRemote
```
Wieder ausschalten: reg delete HKLM\SYSTEM\CurrentControlSet\Services\HiatusRemote /v Environment /f, dann den Dienst neu starten. (setx /M wirkt für Dienste erst nach einem Neustart des Rechners.) Unter Linux: Environment=HIATUS_VIDEO_STATS=/var/tmp/hiatus-ziel.log in einem Drop-in der systemd-Unit, dann systemctl restart hiatus-service. Ein Update (neues MSI) legt den Dienst neu an und entfernt dabei den Schalter – nach einem Update bei Bedarf neu setzen.
Zielrechner ohne Dienst: wie beim Supporter (Variable vor dem Start des Clients setzen).
Jede Zeile beginnt mit Datum und Uhrzeit; beide Dateien (Supporter und Ziel) lassen sich so nebeneinanderlegen. Die Messung kostet kaum Rechenzeit, die Datei wächst aber um etwa 300 Byte je Sekunde und Video – nach der Analyse wieder ausschalten.

9. Sicherheitshinweise

Relay-Schlüssel und Dienst-Datenverzeichnis nur für SYSTEM/root und Administratoren zugänglich halten.
Zugangscodes und Pins nur über vertrauenswürdige Wege verteilen.
Unbeaufsichtigten Zugriff nur mit Allowlist betreiben; Berechtigungen minimal halten.
Direktverbindungen nur einschalten, wo sie gebraucht werden, und auf das VPN-Netz beschränken (Nur aus diesen Netzen). Fremde Absender werden vor jeder Anmeldung getrennt; der Port ist exklusiv belegt.
Das Audit-Log regelmäßig prüfen.
Rechner mit mehreren Benutzern: Der Dienst nimmt je Anmeldesitzung höchstens zwei Oberflächen an und insgesamt acht; der letzte Platz bleibt der Konsolensitzung vorbehalten. Je Konto laufen höchstens zwei Anmeldungen am Dienst gleichzeitig. So kann ein anderer angemeldeter Benutzer die Oberfläche an der Konsole nicht aussperren.
Clients prüfen Partner über gepinnte Geräteschlüssel; die Warnung „Schlüssel geändert“ nie ohne Rückfrage übergehen.
Schlüssel liegen in gegen Auslagern gesperrtem Speicher. Erlaubt das System das nicht (Linux: RLIMIT_MEMLOCK unter 64 KiB), meldet das Protokoll „Schlüsselspeicher nicht gegen Auslagern gesperrt“; die Schlüssel werden dann nur beim Freigeben genullt. systemd erlaubt Diensten standardmäßig genug.

10. Fehlerbehebung

Symptom	Ursache / Lösung
Client: „Kein Relay-Server eingerichtet“	Zugangscode eingeben oder `server`/`port`/`pins` vorbelegen. Mit Host-Dienst: Läuft der Dienst und ist `service.conf` gültig?
„Der Hiatus-Dienst hat den Server nicht übernommen“	Grund steht dabei: keine Administratorrechte, ungültige Angaben oder `service.conf` nicht schreibbar.
Prüfung: „Der Pin passt nicht zu diesem Server“	Pin falsch oder ein anderer Server antwortet (Proxy, TLS-Inspektion). TLS-Inspektion für den Relay-Port ausnehmen.
Prüfung: „Server nicht erreichbar“	Firewall TCP/UDP, Port, Server läuft?
Relay-Protokoll: „an anderer Stelle angemeldet“ wiederholt	Zwei Clients mit demselben Datenverzeichnis (z. B. normal und als Administrator). Aktuelle Clients verhindern das; ältere beenden.
Client-Protokoll: „Server antwortet nicht per UDP (host:port) – Sitzungen über TLS“, auch von außerhalb	Der genannte Port ist der, den der Client nach der Umrechnung verwendet (Kapitel 1, Portweiterleitung). Fehlt dort die UDP-Freigabe (Router, Firewall) oder gelten außen andere Abstände als innen, die Freigabe ergänzen bzw. `--public-udp-port` / `HIATUS_RELAY_PUBLIC_UDP_PORT` setzen. Nur im eigenen Netz (Relay im selben LAN über den öffentlichen Namen): Der Router leitet UDP nicht intern zurück (Hairpinning) – von außen geht es trotzdem.
Sitzung läuft über das Relay statt direkt	Im Protokoll (Client bzw. Dienst) stehen je Verbindung Zeilen „Portsuche: …“ und „Direkter QUIC-Handshake …“: ob eine symmetrische NAT erkannt wurde, wann und nach wie vielen Proben ein Treffer kam, ob die Sitzung erst übers Relay begann und umzog („Umzug vom Relay auf …“). Ohne diese Zeilen: keine Portsuche nötig oder abgeschaltet; beide Seiten symmetrisch → bleibt Relay. Für die Portsuche muss der zweite UDP-Port des Relays offen sein (Kapitel 1).
Bild unscharf oder ruckelig, Hinweis „Langsame Verbindung beim Gegenüber“	Meist reicht der Upload des Zielrechners nicht (Mobilfunk, DSL): Die Regelung richtet die Bitrate nach dem, was die Leitung nachweislich trägt, und senkt bei Bewegung erst Bildrate bzw. Auflösung (je nach Modus im Menü Qualität). Im Protokoll des Supporters steht je Senkung „Videoqualität vom Target gesenkt (Grund): …“ – `rtt`/`queue`/`loss`/`throughput`: Leitung; `receiver-delay`/`receiver-drops`: Bilder kommen verspätet bzw. werden verworfen; `starvation`: Bilder werden zurückgehalten; `encoder`: der Inhalt (starke Bewegung) braucht mehr als das Ziel. Ein gleichzeitiger großer Dateitransfer teilt sich die Leitung mit dem Bild.
Skalierung des Zielrechners steht nach einer Sitzung anders (z. B. 125 % statt 100 %)	Hiatus ändert die Skalierung nie selbst, nur in unbeaufsichtigten Sitzungen mit „Auflösung des Ziels an meinen Bildschirm anpassen“ vorübergehend die Auflösung; Windows legt die Skalierung je Auflösung fest. In der Ereignisanzeige des Dienstes (bzw. im Protokoll des Clients ohne Dienst) stehen „Auflösung angepasst: 1920×1080, Skalierung 125 % (vorher 100 %) …“ und am Sitzungsende „Auflösung zurückgesetzt: …, Skalierung …“ bzw. „Auflösung nicht zurückgesetzt: …“. Fehlt die Zeile zum Zurücksetzen oder bleibt die Skalierung danach abweichend, diese Zeilen an die Entwickler geben; Abhilfe: Einstellung zur Auflösungsanpassung beim Supporter ausschalten.
Strg+Alt+Entf ohne Wirkung	Gruppenrichtlinie (Kapitel 5) oder kein Dienst.
Kein Bild nach Abmelden/Sperre	Kommt nach wenigen Sekunden von selbst; sonst Erneut starten in der Sitzung. Der Dienst hält das Display während einer Sitzung an.
Dienst startet nicht (Linux)	Rechte von `service.conf` prüfen (root, nicht gruppen-/weltschreibbar).
Ereignisanzeige: „Beschreibung … nicht gefunden“	Erwartet bis M8; der Text steht unter „Details“.
Ereignisanzeige: „Sitzungslogik reagiert seit … s nicht“	Ein interner Aufruf hängt; bis zum Neustart des Dienstes (`HiatusRemote`) sind keine neuen Verbindungen möglich. Dienst neu starten und die Meldungen davor (z. B. „Android (USB): …“) an die Entwickler geben. Kommt er von selbst zurück, folgt „reagiert wieder“.
Fernsteuerung ohne Bild, Supporter-Client meldet „Decoder-Prozess …“	`hiatus-decoder` fehlt neben `hiatus-client` oder darf nicht starten (z. B. Anwendungssteuerung/AppLocker; Regeln müssen auch AppContainer-Prozesse erlauben).
Supporter-Client meldet „… für die Sandbox nicht freigebbar“ oder „AppContainer nicht verfügbar“	Rechte auf `hiatus-decoder.exe` setzen (siehe Verteilung des Clients) bzw. Benutzerprofil prüfen (AppContainer-Profile liegen im Profil des Benutzers).
Linux: Fernsteuerung ohne Bild, auf stderr des Clients „hiatus-decoder: Systemaufruf N gesperrt (Sandbox)“	Der Decoder hat einen nicht vorgesehenen Systemaufruf versucht (andere Bibliotheksversion oder Angriff) und wurde beendet. Meldung samt Distribution und Version an die Entwickler.
Linux: „hiatus-decoder: Sandbox nicht möglich …“	Kernel ohne seccomp (sehr alt oder eigens gebaut) oder Architektur außer x86-64/ARM64. Ohne Sandbox dekodiert Hiatus bewusst nicht.

11. Bekannte Einschränkungen

Für Linux gibt es noch kein Paket (deb/rpm); Einrichtung nach diesem Handbuch. Unter Windows installiert das MSI (Abschnitt Installer-Parameter).
Ohne MSI eingerichtet, zeigt die Ereignisanzeige den Text nur unter „Details“ (Ereignisquelle nicht registriert).
Linux nur mit X11; Wayland und macOS folgen später.
Wird ein Upload angehalten und danach abgebrochen, bleibt die versteckte Teildatei (.hiatus-*.part) im Zielordner, bis dieselbe Datei erneut übertragen wird.
Die Auflösung des Zielrechners lässt sich nur auf Modi des Grafiktreibers einstellen (ein virtueller Monitor ist für M8 vorgemerkt).
Android-Geräte am Rechner des Kunden (USB-Brücke, Suche im WLAN) gibt es nur, wenn dort Windows läuft; der Entwickler kann unter Windows oder Linux arbeiten. WLAN-Debugging erst ab Android 11.
Windows PowerShell 5.1 verschiebt nach dem Verkleinern des Terminalfensters Zeilen, sobald eine Fortschrittsanzeige erscheint (Fehler von PowerShell im Konsolenpuffer, nicht von Hiatus); cls räumt auf, $ProgressPreference = 'SilentlyContinue' vermeidet es.
Video und Dateiübertragung teilen sich die Leitung ohne Vorrang; während eines großen Transfers sinkt die Bildqualität.
Der Logcat Viewer hält höchstens 50 000 Zeilen bzw. 64 MB je Gerät (Ringpuffer); ältere Zeilen fallen heraus. Die Warteschlange des Lese-Threads ist auf 50 000 Zeilen bzw. 32 MB begrenzt.

12. Android-Debugging und Logcat

Entwickler debuggen über eine Sitzung Android-Apps auf einem Gerät beim Kunden (Visual Studio/.NET MAUI, Xamarin, adb-Werkzeuge) und lesen dessen Logcat. Die Bedienung beschreibt das Benutzerhandbuch (Android-Geräte debuggen, Logcat Viewer).

Funktionsweise

Der Client des Entwicklers verwendet das adb seines eigenen Rechners; die ADB-Pakete laufen Ende-zu-Ende-verschlüsselt durch die Sitzung. Beim Kunden und auf dem Telefon wird nichts installiert. Logcat, Dateien der Apps und die ADB-Shell laufen ebenfalls über dieses adb – Log-Inhalte landen nur beim Entwickler und werden nur beim Export gespeichert.
USB (Kunde unter Windows): Hiatus öffnet die ADB-Schnittstelle des Telefons (WinUSB) erst beim Verbinden und gibt sie danach wieder frei, lauscht dafür nur auf 127.0.0.1 und nimmt nur Verbindungen des eigenen Prozesses an; jeder Paketkopf wird geprüft. Das Telefon wird an seiner Seriennummer erkannt (auch hinter dem Kindknoten eines Herstellertreibers), nach dem Umstecken verbindet es von selbst neu. Läuft der Hiatus-Dienst, übernimmt er die Brücke.
WLAN (Kabelloses Debugging): Hiatus beim Kunden findet Geräte im lokalen Netz per mDNS und verbindet sich nur mit Adressen im lokalen Netz (private IPv4-Bereiche, IPv6 ULA oder link-local); die Verbindung zum Telefon hat TCP-Keepalive (eine tote Verbindung ist nach etwa 8 s zu, Last nur bei Ruhe, ~50 Byte/s, nur im LAN).

Voraussetzungen

Entwickler: Android SDK mit adb (z. B. aus Visual Studio). Hiatus nimmt den laufenden adb-Server, sonst das SDK von Visual Studio, %ProgramFiles(x86)%\Android\android-sdk, ANDROID_HOME/ANDROID_SDK_ROOT, %LOCALAPPDATA%\Android\Sdk bzw. ~/Android/Sdk oder adb im Pfad.
Kunde: Windows 10/11; für USB ein Treiber mit ADB-Schnittstelle (Herstellertreiber bzw. Google USB Driver) und kein eigenes adb, das das Telefon belegt (Android Studio, Visual Studio mit Android-Werkzeugen, Platform-Tools: schließen bzw. adb kill-server). Für WLAN Android 11+ und das Telefon im selben Netz wie der Rechner (mDNS nicht von einer Firewall blockiert; sonst Gerät von Hand mit IP-Adresse und Port eintragen).

Berechtigung und Nachvollziehbarkeit

Berechtigung Android-Gerät debuggen in der Anfrage (Standard aus). Der Kunde sieht sie in der Hinweisleiste („Android aus (…)“) und kann sie jederzeit beenden; am Telefon muss er das Debuggen zusätzlich erlauben (USB-Vertrauensabfrage bzw. Kopplung).
Zusätzlich Android-Geräte per Adresse eintragen (Standard aus, nur zusammen mit Android-Debugging, auch für unbeaufsichtigte Sitzungen einstellbar): Der Entwickler darf Geräte im Netz des Kunden mit IP-Adresse und Port eintragen und seine Einträge wieder entfernen – für Geräte, die sich nicht per mDNS melden (Fire TV, Nvidia Shield mit Netzwerk-Debugging). Nur private Adressen (wie beim Eintrag durch den Kunden); Hiatus prüft nicht, ob dort ein Gerät antwortet. Jeder Eintrag und jedes Entfernen steht im Audit-Log („Android-Gerät vom Supporter eingetragen/entfernt: Adresse:Port“). Wer das erlaubt, ermöglicht ADB-Verbindungen zu beliebigen Ports im lokalen Netz des Kunden – nur für vertraute Entwickler.
Gemerkte Android-Geräte: Jede von Hand eingetragene Adresse (vom Kunden oder Entwickler) merkt sich der Rechner des Kunden in android-devices.dat im Datenverzeichnis (Dienst: Daten des Dienstes; höchstens 16, nur private Adressen, nach 90 Tagen ohne Benutzung vergessen). Angeboten werden sie nur mit beiden Berechtigungen, wenn der Entwickler das Android-Fenster öffnet, und nur, wenn dort gerade ein adb antwortet: Hiatus schickt die adb-Begrüßung (CNXN) und trennt nach der Antwort – vor dem Schlüsselaustausch, daher ohne Rückfrage am Gerät; adb ist beim Kunden nicht nötig. Audit-Log: „Gemerkte Android-Geräte angeboten (antworten): …“. Den Namen des Geräts meldet der Entwickler nach dem Verbinden (von adb gelesen); der Rechner des Kunden nimmt ihn nur für von Hand eingetragene Geräte an und prüft ihn (höchstens 64 Zeichen, keine Steuerzeichen) – er dient nur der Anzeige. Liste und Vergessen unter Einstellungen → Sicherheit; im Dienstbetrieb nur für den Benutzer an der Konsole.
Das Audit-Log beim Kunden enthält die Android-Verbindung (verbunden/getrennt), nicht jede einzelne Datei oder Logzeile.
Wer Android-Debugging erlaubt, gibt dem Entwickler vollen ADB-Zugriff auf das Gerät (Apps installieren, Daten debugfähiger Apps lesen und schreiben, Logs lesen; Puffer auf dem Gerät leeren löscht die Logs dort nach Rückfrage).

13. Grenzen einer Sitzung

Jede Sitzung hat feste Obergrenzen. Sie schützen beide Rechner vor Überlastung und vor einer feindlichen Gegenseite, die beliebig viele Verbindungen öffnen will. Sie gelten je Sitzung (mehrere Sitzungen haben je eigene) und sind fest eingebaut, nicht einstellbar.

Was	Grenze	Gilt für	Erreicht – was der Benutzer sieht
Tunnel, vom Supporter angelegt	32	Hinzufügen und Remote-Prozess … zusammen; Tunnel des Remote Debuggers und für Android zählen nicht mit	Knöpfe ausgegraut, Hinweis „Alle 32 Tunnel sind belegt – entfernen Sie einen …“; im Dialog Tunnel zu Remote-Prozessen „Höchstens 32 Tunnel – n Ports zu viel gewählt“
Gleichzeitige Verbindungen über Tunnel und Remote Debugger	64	ein gemeinsamer Topf: alle Tunnel des Supporters und die Verbindungen von Visual Studio zu msvsmon	Die Verbindung wird abgewiesen (das Programm des Supporters erhält einen Verbindungsabbruch); Hinweis „Verbindungsgrenze erreicht“ mit Grenze und Rat; am Tunnel „n abgewiesen (Grenze: 64 Verbindungen …)“ in Warnfarbe
Gleichzeitige Verbindungen zu Android-Geräten	64	eigener Topf (Verbinden und Koppeln, höchstens 16 Geräte) – beeinflusst Tunnel und Debugger nicht	wie oben, Text „Android: Verbindung abgewiesen …“
Kanäle (Streams) der Transportverbindung	256 je Richtung	alle Funktionen zusammen	Praktisch nie: Die Grenzen je Funktion ergeben zusammen weniger (siehe unten). Sonst Hinweis „keine freien Kanäle“
Remote Shells	4	je Sitzung	Meldung „Zu viele Shells“
Dateiübertragungen gleichzeitig	4	je Sitzung (der Partner nimmt zum Schutz höchstens 16 an)	weitere warten in der Warteschlange (keine Ablehnung)
Monitore mit Bild	8	je Sitzung	–
Prozesse in Tunnel zu Remote-Prozessen	512 Prozesse, 32 Ports je Prozess	je Abfrage	Hinweis „Liste unvollständig“

Rückmeldung ist Pflicht: Keine Verbindung wird still abgewiesen. Erreicht eine Verbindung eine Grenze, zählt der Tunnel sie als „abgewiesen“ (sichtbar in der Tunnelliste, bis der Tunnel entfernt wird), und es erscheint ein Hinweis „Verbindungsgrenze erreicht“ – auch für die unsichtbaren Tunnel von Remote Debugger und Android. Bei vielen Abweisungen hintereinander kommt höchstens ein Hinweis je Sitzung alle 5 Sekunden; der Zähler am Tunnel stimmt trotzdem. Das Programm, das sich verbinden wollte (z. B. Visual Studio, ein Browser, adb), sieht nur einen Verbindungsabbruch.

Was tun, wenn die 64 Verbindungen nicht reichen? Nicht benötigte Verbindungen schließen (z. B. Browser-Tabs, die einen Tunnel offen halten), Tunnel stoppen, die gerade nicht gebraucht werden, oder für eine zweite Aufgabe eine zweite Sitzung öffnen – jede Sitzung hat ihre eigenen Grenzen. Visual Studio öffnet beim Remote-Debugging selbst mehrere Verbindungen; deshalb teilen sich Tunnel und Debugger den größeren Topf.

Technik (für Administratoren): Der Supporter hält die Grenzen ein und meldet jede Abweisung. Der Partner-Rechner prüft sie unabhängig davon noch einmal – mit 8 Verbindungen Puffer, weil dort geschlossene Verbindungen kurz weiterzählen – und weist darüber hinaus mit „Limit“ ab; auch das sieht der Supporter als Abweisung. Die Summe aller Grenzen je Funktion (rund 180) liegt unter den 256 Kanälen der Transportverbindung, damit keine Funktion einer anderen die Kanäle wegnehmen kann (geprüft durch einen Test).