Netzwerk und Ports

Diese Seite ist die Referenz für die Netzwerkseite einer Restow-Installation: welche Verbindungen es gibt, welche Seite sie jeweils öffnet, welches Protokoll und welchen Port sie nutzt und was ausfällt, wenn eine Firewall sie sperrt. Sie hilft Ihnen, die Firewall einer eigenen VM bei einem Hosting-Anbieter wie Hetzner oder in Azure zu planen, oder die eines Restow-Hosts in Ihrem LAN hinter einem Reverse-Proxy. Die kurze Liste der veröffentlichten Ports steht unter Ports und Rollen; alles andere steht hier.

Überblick

Restow läuft als ein Docker-Compose-Stack auf einem Host (siehe Ein Host). Wer eine Verbindung öffnet, entscheidet, welche Firewall sie erlauben muss:

Browser von Administratoren und Nutzern verbinden sich mit der Caddy-Edge per HTTPS auf Port 443.
Agents auf Servern und Clients verbinden sich mit derselben Adresse und demselben Port. Ein Agent verbindet sich nur nach außen. Auf dem Endpoint lauscht nichts, und die Instanz verbindet sich nie mit einem Endpoint: Aufgaben wie „Jetzt sichern“ erreichen den Agent in der Antwort auf seinen regelmäßigen Kontakt, alle 5 Minuten.
Proxmox-VE-Knoten verbinden sich mit derselben Adresse und demselben Port wie Agents, wenn Sie VMs und Container sichern. Der Helfer auf einem Knoten verbindet sich nur nach außen, und die Instanz verbindet sich nie mit einem Knoten (siehe Wie Proxmox-VE-Knoten ihr Repository erreichen).
Exchange Online verbindet sich mit Port 25 des Journal-Empfängers, der im Container api läuft, wenn Sie das Journaling nutzen. Ein Mailanbieter, der Kopien seiner Mail an das Archiv weiterleitet (seit 0.4.4), verbindet sich mit demselben Port.
Microsoft Graph verbindet sich wie ein Browser mit Port 443, mit seinen Änderungsbenachrichtigungen über neue Mail, wenn Sie Microsoft-365-Postfächer über Graph archivieren (seit 0.4.4). Das ist die einzige Verbindung, die Microsoft in die Installation öffnet (siehe Microsoft ruft die Instanz auf). Ohne sie geht nichts kaputt: Restow prüft die Postfächer stattdessen im Intervall.
Let’s Encrypt verbindet sich mit Port 80 (und 443), um Ihre Domain zu prüfen, wenn Caddy ein Zertifikat selbst anfordert.
Der Docker-Host bindet Freigaben ein (seit 0.4.0). Für die Sicherung von Freigaben verbindet sich der Docker-Host, nicht ein Container, mit Ihren Dateiservern: SMB auf TCP 445, NFS auf TCP 2049 (siehe Wie die Instanz Dateiserver erreicht). Der Dateiserver öffnet keine Verbindung zu Restow.
Der Restow-Host verbindet sich nach außen mit allem Übrigen: Microsoft 365, IMAP-Servern, S3-Speicher, einem Mail-Relay, Webhook-Zielen und, wenn Sie sie einschalten, Update-Quellen. Das meiste davon erledigt der worker, den Rest die api.
Die Container sprechen im Docker-Netz miteinander. Keiner dieser Ports wird veröffentlicht.

Restow kontaktiert keinen Server des Herstellers. Der Lizenzschlüssel wird offline geprüft, und die Update-Prüfung bleibt aus, bis ein Administrator sie einschaltet; sie sendet keine Angaben über Ihre Installation. Siehe Lizenz und Editionen und Updates.

Komponenten und Verbindungen. Der Punkt markiert die Seite, die eine Verbindung öffnet, die Pfeilspitze die Seite, die sie annimmt; gestrichelte Linien sind optionale Funktionen. Die Tabellen darunter enthalten dieselben Angaben.

Eingehende Verbindungen

Das sind die einzigen Verbindungen, die jemand zum Restow-Host öffnet.

Port	Protokoll	Von	Gebraucht, wenn	Wenn er geschlossen ist
443	TCP, HTTPS	Browser von Administratoren und Nutzern, Agents auf Servern und Clients, Proxmox-VE-Knoten, Microsoft Graph (Änderungsbenachrichtigungen für die Archiv-Erfassung, seit 0.4.4), Let’s Encrypt (TLS-ALPN-Prüfung); hinter einem Reverse-Proxy: der Proxy	Immer	Weboberfläche, Installationsskripte und alle Agents und Proxmox-VE-Knoten sind nicht erreichbar. Aufträge, die nur mit Microsoft 365, IMAP oder S3 sprechen, laufen weiter, weil der `worker` keine eingehende Verbindung braucht. Die Graph-Erfassung fällt darauf zurück, jedes Postfach alle 15 Minuten zu prüfen.
80	TCP, HTTP	Let’s Encrypt (HTTP-Prüfung), Browser, die eine `http://`-Adresse öffnen	Öffentlicher Modus, solange Caddy sein Zertifikat selbst bezieht	Caddy kann die HTTP-Prüfung nicht bestehen und bekommt sein Zertifikat womöglich nicht oder erneuert es nicht; `http://`-Adressen werden nicht umgeleitet. Öffnen Sie ihn für alle: Let’s Encrypt prüft von mehreren Orten gleichzeitig.
25	TCP, SMTP mit verpflichtendem STARTTLS	Exchange Online; die Mailserver eines Anbieters, der Kopien weiterleitet	Nur für das Exchange-Journaling und weitergeleitete Kopien (Business und Service Provider), nachdem Sie `JOURNAL_SMTP_PORT=25` und `JOURNAL_SMTP_BIND=0.0.0.0` gesetzt haben	Es kommen keine Journal-Reports und keine weitergeleiteten Kopien an. Was Exchange Online nicht zustellen kann, schickt es an Ihr Postfach für nicht zustellbare Journalberichte; der Server eines Anbieters versucht es eine Weile erneut. Der Port muss den Empfänger direkt erreichen, nie über Caddy oder einen HTTP-Proxy.
22	TCP, SSH	Ihre Administratoren	Um den Host zu verwalten. Das ist kein Restow-Port	Sie verwalten den Host auf anderem Weg, etwa über die Konsole des Anbieters. Erlauben Sie ihn nur von Ihren eigenen Adressen.

Restow prüft nicht, wer sich mit Port 25 verbindet, und begrenzt nur die Rate je Absenderadresse: Es nimmt ausschließlich Journal-Adressen an, die es kennt, und prüft weder SPF noch die Adressbereiche von Microsoft (siehe Exchange-Journaling); die Grenzen sind 600 Verbindungen pro Minute je Absenderadresse und 300 Zustellungen pro Minute je Archivadresse, je api-Prozess, und lassen sich ändern. Wenn Sie die Quelle für das Journaling einschränken wollen, nennt Microsoft die Adressen, von denen aus es sich mit Kundennetzen verbindet, auf der Seite weitere Endpunkte; prüfen Sie sie regelmäßig.

Microsoft ruft die Instanz auf: Graph-Änderungsbenachrichtigungen

Seit 0.4.4 ist das Archivieren von Microsoft-365-Postfächern über Graph (Business und Service Provider, siehe Archivierung) die eine Funktion, bei der Microsoft eine Verbindung in Ihre Installation öffnet. Für jedes archivierte Postfach bittet Restow Microsoft Graph um eine Änderungsbenachrichtigung; Microsoft sendet dann einen HTTPS-POST an diese beiden Pfade der öffentlichen URL, wenn eine Mail ankommt oder ein Abonnement Aufmerksamkeit braucht:

/api/v1/hooks/graph/notifications
/api/v1/hooks/graph/lifecycle

Was gelten muss:

Die öffentliche URL ist https:// auf Port 443 und nennt einen Host, den Microsoft aus dem Internet auflösen und erreichen kann. Eine URL mit anderem Port, localhost, einer privaten Adresse oder einem Namen, der auf .local, .internal oder .lan endet, ergibt keine Benachrichtigungen. Die URL kommt aus Installation → Server & Betrieb → Server, sonst aus RESTOW_PUBLIC_URL.
Das Zertifikat ist eines, das Microsoft validiert. Der Edge mit seinem eigenen Let’s-Encrypt-Zertifikat tut das. Ein Zertifikat der internen Stelle von Caddy nicht; hinter einem Reverse-Proxy sieht Microsoft also das öffentliche Zertifikat des Proxys.
Ein Reverse-Proxy reicht die beiden Pfade unverändert durch: POST, der Body bis 1 MiB, keine Anmeldung oder Single Sign-on davor, kein Filter nach Quelladresse, der Microsoft ausschließt, und eine Antwort in wenigen Sekunden (Microsoft wartet 3 Sekunden auf eine Benachrichtigung und 10 auf die Validierung eines neuen Abonnements).
Es wird keine Liste von Quelladressen gebraucht oder geliefert. Restow prüft nicht, woher eine Benachrichtigung kommt; es prüft das Geheimnis des Abonnements und ignoriert alles andere. Schränken Sie die beiden Pfade nicht nach Microsoft-Adressen ein, es sei denn, Sie halten die Liste selbst aktuell.
Ohne eine Edition, die die Erfassung aus dem Postfach enthält, antworten die beiden Pfade mit 404.

Gilt etwas davon nicht, schlägt Restow nicht fehl: Es legt kein Abonnement an und prüft jedes Postfach alle 15 Minuten auf Änderungen (ARCHIVE_GRAPH_POLL_MINUTES), und die Archiv-Seite nennt den Grund (graph.notification_url_unavailable, oder graph.subscription_failed, wenn Microsoft ein Abonnement ablehnt; es wird stündlich erneut versucht). Die ausgehende Seite bleibt unverändert: login.microsoftonline.com und graph.microsoft.com auf 443.

Ports, die geschlossen bleiben müssen

3000 (api): nur auf 127.0.0.1 veröffentlicht (RESTOW_API_PORT), für Health-Checks auf dem Host. Caddy erreicht ihn über das Docker-Netz.
5432 (postgres): Der Release-Stack veröffentlicht ihn nicht.
8090 (updater) und 8091 (mounter): nicht veröffentlicht, nur im Docker-Netz erreichbar.
Der Journal-Port, solange JOURNAL_SMTP_BIND den Standard 127.0.0.1 hat.

RESTOW_HTTP_PORT und RESTOW_HTTPS_PORT ändern die Host-Ports der Edge; mit einer Adresse und einem Port wie 127.0.0.1:8443 wird sie nur auf dieser Schnittstelle veröffentlicht. Let’s Encrypt braucht die Standard-Ports, ändern Sie sie also nur hinter einem weiteren Reverse-Proxy oder für eine lokale Evaluierung.

Ausgehende Verbindungen

Diese Verbindungen öffnet der Restow-Host. Ein Ziel brauchen Sie nur, wenn Sie die Funktion in der letzten Spalte nutzen.

Ziel	Port, Protokoll	Wozu	Gebraucht, wenn
`login.microsoftonline.com`	443, HTTPS	Token-Anfragen der Backup-App und der Admin-Consent-Ablauf	Microsoft-365-Quellen, Benachrichtigungs-Mail über Microsoft Graph
`graph.microsoft.com`	443, HTTPS	Microsoft Graph: Verzeichnissynchronisierung, Mail- und OneDrive-Backup und -Restore; Benachrichtigungs-Mail mit `MAIL_TRANSPORT=graph`	Microsoft-365-Quellen, Benachrichtigungs-Mail über Microsoft Graph
`*.sharepoint.com`, für OneDrive `<tenant>-my.sharepoint.com` Ihres Tenants	443, HTTPS	Graph nennt auf diesen Hosts kurzlebige URLs für OneDrive-Dateidownloads und Upload-Sitzungen für Restores	OneDrive-Schutz
Die IMAP-Server, die Sie eintragen	Der Port, den Sie eintragen: 993 (TLS) oder 143 (STARTTLS)	IMAP-Backup, Restore und Anmeldung testen; höchstens zwei Verbindungen je Konto. Die IMAP-Archivierung (seit 0.4.4) hält je Konto eine weitere mit IDLE offen, bis zu vier insgesamt, während ein Durchlauf und eine Sicherung laufen	IMAP-Quellen. Server auf Loopback-, privaten oder lokalen Adressen werden abgelehnt, außer es gilt `IMAP_ALLOW_PRIVATE_NETWORKS=true` oder eine Provider-Administration hat den Host gespeichert.
S3-kompatibler Speicher	443, HTTPS, oder der Port in der Endpoint-URL	Backup, Restore, Archiv und die Repositories von Endpoints	Ein S3-Speicherziel. Seit 0.4.0 muss ein neuer oder geänderter Endpoint `https://` verwenden (außer zu `localhost`).
Ihre Dateiserver (der Docker-Host)	TCP 445 (SMB), TCP 2049 (NFS); NFSv3 zusätzlich 111 (Portmapper) und der Port des Mount-Daemons	Eine SMB-Freigabe oder einen NFS-Export für einen Lauf schreibgeschützt einbinden: Sicherung einer Freigabe, Restore oder Kopie	Freigaben (seit 0.4.0). Die Verbindung macht der Kernel des Docker-Hosts, nicht ein Container.
Ihr Mail-Relay	Der Port, den Sie in der Einrichtung eintragen: 587 (STARTTLS) oder 465 (implizites TLS); unverschlüsselt nur für ein internes Relay	Alarme, Berichte und Einladungen	`MAIL_TRANSPORT=smtp`. Nicht nötig mit Microsoft Graph `sendMail`, das die beiden Microsoft-Zeilen oben nutzt.
Webhook-Ziele	Der Port in der jeweiligen URL, `http://` oder `https://`	Webhook-Zustellungen durch den `worker`	Wenn Sie Webhooks anlegen. Ziele auf Loopback oder in privaten Netzen werden abgelehnt, außer es gilt `RESTOW_WEBHOOK_ALLOW_PRIVATE=true`.
Let’s Encrypt, mit ZeroSSL als Ausweichziel von Caddy	443, HTTPS	Caddy fordert sein Zertifikat an und erneuert es (ACME)	Öffentlicher Modus, in dem die Edge ihr Zertifikat selbst bezieht. Nicht hinter einem Reverse-Proxy, der das Zertifikat hält (ab 0.2.0 mit `RESTOW_EDGE_TLS=internal`, oder mit unverschlüsselter HTTP-Strecke).
`api.github.com` oder der Host Ihrer eigenen Update-Quelle	443, HTTPS	Die Update-Prüfung liest die Release-Liste. Es werden keine Angaben über Ihre Installation gesendet, und einer Weiterleitung auf einen anderen Host wird nicht gefolgt.	Nur nachdem ein Administrator die Update-Prüfung eingeschaltet hat
`ghcr.io`, `tuf-repo-cdn.sigstore.dev`	443, HTTPS	Der optionale Updater lädt die Images und prüft ihre Signaturen mit cosign, über den Docker-Daemon des Hosts	Nur mit dem Profil `updater`
`github.com`, `ghcr.io`, `registry-1.docker.io`, `tuf-repo-cdn.sigstore.dev` und `download.docker.com`	443, HTTPS	Das Installationsskript. Der letzte Host nur, wenn das Skript Docker installiert. Ein Update von Hand lädt von `ghcr.io` und von `registry-1.docker.io`, das das Image `postgres` liefert.	Installation und Updates

Zwei Dinge sind keine Restow-Ports, müssen aber funktionieren: der DNS-Resolver des Hosts (Port 53), weil jedes Ziel oben ein Name ist, und eine synchronisierte Uhr (NTP, UDP 123), weil Zertifikatsprüfungen und Authenticator-Codes die richtige Zeit brauchen (siehe Erste Schritte).

Microsoft veröffentlicht die Endpunkte von Microsoft 365 mit Ports und Adressbereichen unter Microsoft 365 URLs and IP address ranges; login.microsoftonline.com, graph.microsoft.com und *.sharepoint.com stehen dort für TCP 443. Wenn Sie den ausgehenden Verkehr auf eine Liste beschränken, brauchen das Installationsskript und ein Update von Hand mehr Ziele als der tägliche Betrieb; öffnen Sie sie für die Zeit der Installation oder des Updates.

Im Docker-Netz

Die Container des Stacks erreichen sich im Standardnetz des Compose-Projekts über den Dienstnamen. Keiner dieser Ports wird veröffentlicht.

Von	Nach	Port	Protokoll	Wozu
`caddy`	`api`	3000	HTTP	`/api/`, `/agent/`, `/install/*`, `/healthz` und `/readyz` sowie ein Lebendigkeitsaufruf vor jedem Seitenaufruf. Dieser Aufruf sorgt dafür, dass die Wartungsseite erscheint, wenn die `api` nicht da ist.
`api`, `worker`, `scheduler`	`postgres`	5432	PostgreSQL	Anwendungsdaten und die Job-Queue, mit den drei Datenbank-Rollen
`api`	`updater`	8090	HTTP	Nur mit dem Profil `updater` (`RESTOW_UPDATER_URL`, Standard `http://updater:8090`)
`api`, `worker`	`mounter`	8091	HTTP	Nur mit dem Profil `mounts` (`RESTOW_MOUNTER_URL`, Standard `http://mounter:8091`): die `api` für Netzlaufwerke und den Status des Mounters, der `worker`, um Runner für Freigaben zu starten (seit 0.4.0). Ein gemeinsames Secret aus dem Volume `restow-mounter-shared` beglaubigt den Aufruf.
Runner für Freigaben	`api`	3000	HTTP	Nur über das interne Netz `runners` (`RESTOW_MOUNTER_RUNNER_API_URL`, Standard `http://api:3000`): die restic-Repository-Route des Runners und seine Fortschrittsmeldungen, mit einer Zugangsberechtigung, die für einen Lauf gilt und nur Daten hinzufügen kann (seit 0.4.0). Das Netz hat keine Route nach außen, ein Runner erreicht also sonst nichts.
`updater`	`api`	3000	HTTP	Nur mit dem Profil `updater`: Bereitschaft der neuen Version und, im Source-Modus, das gespeicherte Token
`caddy`	`updater`	8090	HTTP	Ein schreibgeschütztes Status-Dokument (`/_maintenance/status`) für die Wartungsseite
`worker`, `api`	sich selbst	zufällig, auf `127.0.0.1`	HTTP	Der Listener für eine restic-Wartungsoperation an einem Endpoint-Repository (siehe Wie Endpoints ihr Repository erreichen). Er verlässt den Container nie.
Der Host	`api`	3000 auf `127.0.0.1`	HTTP	Health-Checks (`RESTOW_API_PORT`). Das ist keine Verbindung zwischen Containern.

worker und scheduler stellen keine Ports bereit, und nichts verbindet sich mit ihnen. Sie verbinden sich mit PostgreSQL, und der worker verbindet sich für seine Aufträge mit den ausgehenden Zielen oben. Die Rollen rufen sich nicht gegenseitig auf: api und scheduler stellen Aufträge in die Queue in PostgreSQL (pg-boss), der worker fragt diese Queue ab (WORKER_POLL_SECONDS, Standard 2), und worker und scheduler melden in einer Datenbanktabelle, dass sie leben; diese liest /readyz. Die PostgreSQL-Verbindung ist damit die eine interne Verbindung, die jede Rolle braucht.

Ein Host

Die Rollen auf getrennten Hosts zu betreiben, wird in 0.x nicht unterstützt. Der Release-Stack läuft vollständig auf einem Host: api und worker binden beide das Volume restow-data mit dem lokalen Standardspeicher und denselben Import-Ordner ein, postgres ist nur im Docker-Netz erreichbar, worker und scheduler bieten nichts an, womit man sich verbinden könnte, und der Updater verwaltet genau ein Compose-Projekt. Es gibt keinen entfernten Worker und keinen Weg, einen Worker auf einem anderen Rechner auf eine Installation zu richten. Für mehr Durchsatz geben Sie dem Host mehr Ressourcen und starten mehr worker-Container (siehe Dimensionierung).

Wie Endpoints ihr Repository erreichen

Ein Endpoint spricht nie mit dem Speicherziel. Er spricht mit Ihrer Instanz, und die Instanz schreibt in den Speicher:

Der Agent öffnet HTTPS-Verbindungen zu Port 443 der Adresse Ihrer Instanz (der öffentlichen URL), für seinen regelmäßigen Kontakt unter /agent/v1/... und für die Backup-Daten.
Bei einem Backup nutzt restic auf dem Endpoint das REST-Backend-Protokoll gegen rest:https://<Instanz>/agent/restic/<Endpoint-ID>/, angemeldet per HTTP-Basic (Endpoint-ID und Agent-Secret). Caddy reicht /agent/restic/* an api:3000 weiter und streamt in beide Richtungen, ohne Grenze für die Größe des Bodys an der Edge.
Die api setzt das REST-Protokoll von restic selbst um, ohne eigenen Repository-Server. Sie prüft die Zugangsdaten, wendet die Append-only-Regeln und das Speicherbudget an und liest und schreibt die Objekte über die Speicherschicht des Mandanten: Sie landen im Primärziel des Mandanten unter endpoints/<Endpoint-ID>/. Ein lokales Volume, ein S3-Bucket und ein eingebundener NFS-Pfad nehmen denselben Codepfad.
Der Agent erhält nie Zugangsdaten des Speichers: keine S3-Schlüssel, keine Mount-Pfade, keine direkte Verbindung zum Speicher. Er akzeptiert außerdem ein Repository nur auf dem Host Ihrer Instanz und weist jedes andere ab.
Aufbewahrung, Repository-Prüfungen, Restore-Tests, Browsen und Downloads erledigt der Server als restic-Prozesse im Container worker oder api. Sie nutzen einen Listener auf 127.0.0.1 dieses Containers, der für genau eine Operation lebt; einen Wartungszugang aus dem Netz gibt es also nicht.

Für die Firewall heißt das:

Endpoints brauchen ausgehend nur HTTPS zu Ihrer Instanz und einen Namen, der sich auflösen lässt. Hinter einem Proxy beachten sie HTTPS_PROXY und NO_PROXY; eine private Zertifizierungsstelle braucht SSL_CERT_FILE oder einen Eintrag im Zertifikatsspeicher (siehe Proxy und private CA).
Das Speicherziel braucht keine eingehende Verbindung von Endpoints. Nur der Restow-Host verbindet sich damit.
Ein Reverse-Proxy vor Restow muss große Bodys durchlassen: Ein Agent lädt restic-Packs bis 128 MiB je Objekt hoch, und die api lehnt mehr ab. Ein Proxy mit kleinerer Grenze antwortet mit 413.

Die Pfade und die Größengrenzen für Anfragen stehen unter Ports und Rollen. Die Sicherheitseigenschaften stehen im Sicherheitsmodell.

Wie Proxmox-VE-Knoten ihr Repository erreichen

Das Backup von VMs und Containern von Proxmox VE (eine Preview, siehe Proxmox-VE-Backup) funktioniert wie bei den Agents: Der Knoten spricht nie mit dem Speicherziel, nur mit Ihrer Instanz, und nur ausgehend.

Der Helfer restow-pve auf jedem Knoten öffnet HTTPS-Verbindungen zu Port 443 der Adresse Ihrer Instanz, angemeldet mit dem eigenen Secret des Knotens. Jede Minute meldet er sich und fragt nach Aufgaben (/agent/pve/v1/...), und alle fünf Minuten meldet er die Gäste des Knotens. Die Instanz verbindet sich nie mit einem Knoten: Eine Aufgabe wie „Jetzt sichern“ erreicht den Knoten in der Antwort auf seine nächste Meldung.
Für VM-Festplatten sendet der Knoten geänderte 4-MiB-Blöcke in Paketen von bis zu 16 Blöcken an /agent/pve/v1/.... Die api prüft die SHA-256 jedes Blocks und schreibt ihn über die Speicherschicht des Mandanten. Die Caddy-Edge nimmt auf diesem Pfad Bodys bis 80 MiB an.
Für Container schreibt restic auf dem Knoten nach rest:https://<Instanz>/agent/pve/restic/<Gast-ID>/, mit einer Zugangsberechtigung, die für einen Lauf gilt und nur Daten hinzufügen kann. Die Edge streamt /agent/pve/restic/* wie /agent/restic/*, ohne Größengrenze. Die Daten landen im Primärziel des Mandanten unter pve-guests/<Gast-ID>/.
Das Installationsskript und die Updates des Helfers laden von /install/pve.sh und /install/agent/<Version>/... derselben Instanz.
Auf dem Knoten selbst spricht der Helfer mit der Proxmox-VE-API auf 127.0.0.1:8006. Diese Verbindung verlässt den Knoten nie.
Ein Knoten braucht ausgehend nur HTTPS zu Ihrer Instanz und einen Namen, der sich auflösen lässt. Er beachtet HTTPS_PROXY und NO_PROXY. Ein Reverse-Proxy vor Restow muss Bodys von mindestens 128 MiB durchlassen, wie bei den Agents.

Die Pfade stehen unter Ports und Rollen.

Wie die Instanz die Repositories erreicht

api und worker schreiben und lesen den Speicher jedes Mandanten. Was sie brauchen, hängt von der Art des Ziels ab:

Ziel	Netzwerkweg	Port	Hinweise
Lokales Volume (Standard)	Keiner. Das Docker-Volume `restow-data` ist unter `/data` in `api` und `worker` eingebunden (`STORAGE_LOCAL_PATH`, Standard `/data/chunks`).	Keiner	Es liegt auf der Platte des Restow-Hosts.
S3-kompatibel	`api` und `worker` zum Endpoint des Dienstes	443 (HTTPS) oder der Port in der Endpoint-URL, zum Beispiel `https://s3.example.com:9000`	Seit 0.4.0 muss der Endpoint `https://` verwenden: Ein neuer oder geänderter Endpoint über einfaches `http://` wird abgelehnt (`endpoint_insecure`), außer zu `localhost`, `127.0.0.1` und `[::1]`. Früher gespeicherte Endpoints funktionieren weiter und sind rot markiert. Testaufbauten setzen `S3_ALLOW_INSECURE=true`.
NFS	Die Freigabe wird auf dem Docker-Host eingebunden, und der eingebundene Ordner wird als Pfad in `api` und `worker` durchgereicht. Restow sieht ein Verzeichnis und spricht selbst kein NFS. SMB ist seit 0.2.1 kein unterstützter Speicher-Mount mehr; ein früher eingebundener Pfad funktioniert weiter.	NFS: TCP 2049. Vom Host zum NAS.	NFSv4 braucht nur Port 2049; das ältere NFSv3 braucht zusätzlich den Portmapper und weitere Ports. Die Compose-Datei des Releases enthält keinen solchen Mount. Seit 0.3.1 ergänzt ihn der Mounter über die Weboberfläche (siehe Mounter und NFS-Speicher); ohne ihn ergänzen Sie den Mount selbst, etwa mit einer Compose-Override-Datei. Das NAS muss die Adresse des Restow-Hosts zulassen.
Kopier-Ziele	Dieselben Wege, je Ziel einmal	Je nach Art des Ziels	Jedes neue Backup geht auch an die Kopier-Ziele. Siehe Backups und Zeitpläne.

Das eigenständige Restore-Werkzeug restow-restore liest einen Speicherordner direkt und braucht weder einen Restow-Server noch eine Datenbank noch eine Verbindung zu Restow. Es nimmt einen Pfad, binden Sie einen S3-Bucket also vorher ein oder kopieren Sie ihn. Siehe Restow selbst sichern.

Wie die Instanz Dateiserver erreicht

Die Sicherung von Freigaben (seit 0.4.0, siehe Freigaben) liest SMB-Freigaben und NFS-Exporte Ihrer Dateiserver ohne Agent darauf. Die Verbindung macht der Docker-Host, nicht ein Container: Der Mounter legt ein kurzlebiges Docker-Volume des Treibers local an, der Kernel des Hosts bindet die Freigabe darüber ein, und ein Runner-Container sieht nur den eingebundenen Ordner, für eine Sicherung schreibgeschützt.

Protokoll	Port, vom Docker-Host zum Dateiserver	Hinweise
SMB	TCP 445	SMB 2.1 bis 3.1.1. SMB1 und NTLMv1 werden abgelehnt. Braucht das Modul `cifs` im Kernel des Hosts.
NFS	TCP 2049	NFSv4 braucht nur diesen Port. NFSv3 braucht zusätzlich den Portmapper (111) und den Mount-Daemon. Braucht den NFS-Client auf dem Host (`nfs-common`, `nfs-utils`). Der Export muss die Adresse des Docker-Hosts zulassen.

Nichts wird eingehend geöffnet. Der Dateiserver braucht keine Verbindung zu Restow, und die Runner haben kein eigenes Netz außer dem internen Netz runners zur api.
Name und Adresse. Der Name des Dateiservers muss auf dem Docker-Host auflösen. Restow beurteilt die Adresse bei jedem Test und Lauf: Ein Server auf einer privaten oder Loopback-Adresse braucht die Genehmigung einer Provider-Administration oder, für eine Mandanten-Administration, den Installationsschalter Mandanten dürfen Freigaben in privaten Netzen hinzufügen (Installation → Standard-Repository & Netzlaufwerke → Runner für Freigaben; siehe Budgets, Netzwerke und Runner).
Über VPN oder Routing. Der Dateiserver muss vom Docker-Host selbst erreichbar sein. Der Dateiserver eines Kunden hinter einem Site-to-Site-VPN funktioniert, wenn der Docker-Host dorthin routet. Eine langsame Leitung wird so genutzt, wie sie ist: Restow sichert darüber.
SELinux. Setzen Sie auf einem Host mit aktivem SELinux RESTOW_MOUNTER_SELINUX_CONTEXT=true in der Umgebung des Dienstes mounter; eine Zeile in der .env erreicht ihn nicht (siehe Freigaben: der Docker-Host).

Betriebsszenarien

Wählen Sie das Szenario, das dazu passt, wie Sie den Host erreichen. Jedes hat seinen eigenen Regelsatz.

Szenario A: eigene VM mit öffentlicher IP

Das ist das übliche Bild für einen Provider, der eine Restow-Installation auf einer eigenen VM bei einem Hosting-Anbieter wie Hetzner Cloud oder in Azure betreibt. Die VM hat eine öffentliche Adresse, der DNS-Eintrag von RESTOW_APP_DOMAIN zeigt auf sie, und Caddy bezieht sein Zertifikat von Let’s Encrypt (zum Beispiel installiert mit --domain restow.example.com, siehe Erste Schritte). Die Cloud-Firewall des Anbieters übernimmt das Filtern.

Eingehende Regeln an der Cloud-Firewall:

Protokoll	Port	Quelle	Zweck
TCP	443	Überall (`0.0.0.0/0` und `::/0`)	Weboberfläche, Agents, Installationsskripte, TLS-ALPN-Prüfung
TCP	80	Überall	HTTP-Prüfung durch Let’s Encrypt, Umleitung auf HTTPS
TCP	25	Überall	Nur für das Exchange-Journaling und weitergeleitete Kopien; sonst weglassen
TCP	22	Die Adressen Ihrer Administratoren	SSH

Alles andere bleibt geschlossen. Der ausgehende Verkehr darf offen bleiben, was bei beiden Anbietern der Standard ist, abgesehen von Port 25 (unten), oder Sie beschränken ihn auf die Tabelle der ausgehenden Verbindungen.

Beispiel für eine eigene VM bei einem Hosting-Anbieter. Die Cloud-Firewall steht außerhalb der VM, Docker kann sie deshalb nicht umgehen.

Was die beiden Anbieter auf ihrer Seite tun:

Thema	Hetzner Cloud	Azure
Filtern	Eine Cloud Firewall sperrt jeden eingehenden Verkehr, den keine Regel erlaubt, und lässt jeden ausgehenden Verkehr zu, bis Sie ausgehende Regeln anlegen (dann sind nur noch die genannten Adressen erlaubt). Ein Server ohne Firewall wird nicht gefiltert.	Eine Netzwerksicherheitsgruppe an der Netzwerkschnittstelle oder im Subnetz. Die Standardregel `DenyAllInbound` (Priorität 65500) sperrt eingehenden Verkehr, den keine Regel erlaubt; legen Sie Ihre mit einer niedrigeren Prioritätszahl an. Eine öffentliche IP der SKU Standard ist für eingehenden Verkehr gesperrt, bis eine Gruppe ihn erlaubt. `AllowInternetOutBound` erlaubt ausgehenden Verkehr.
Ausgehend TCP 25	Standardmäßig auf allen Cloud-Servern gesperrt, zusammen mit 465. Nach einem Monat und der ersten bezahlten Rechnung können Sie per Limit-Anfrage eine Ausnahme beantragen; Hetzner entscheidet im Einzelfall. Die Sperre gilt je Konto. (FAQ)	Gesperrt bei Abonnements vom Typ Pay-as-you-go, MSDN, Azure Pass, Azure in Open, Education und Free Trial sowie bei Abonnements von Cloud Solution Providern (CSP), ohne Möglichkeit, die Sperre aufzuheben. Enterprise Dev/Test sperrt standardmäßig, eine Ausnahme ist möglich. Nicht gesperrt bei Enterprise Agreement und MCA-E. (Microsoft)
Ausgehend TCP 587	Nicht gesperrt	Nicht gesperrt, gleich welcher Abonnementtyp
Eingehend TCP 25	Die FAQ beschreibt die Sperre für den Mailversand und nennt keine Einschränkung für eingehenden Verkehr. Testen Sie von außen.	Der Artikel beschreibt die Sperre nur für ausgehende Verbindungen; eingehenden Verkehr entscheidet Ihre Sicherheitsgruppe. Testen Sie von außen.

Was das für Restow bedeutet:

Benachrichtigungs-Mail darf auf diesen Plattformen nicht über Port 25 gehen. Nehmen Sie ein Relay mit Anmeldung auf 587 (STARTTLS) oder 465, wenn der Anbieter es durchlässt, oder Microsoft Graph sendMail, das Restow unterstützt und das über Port 443 läuft (siehe Einrichtungsassistent). Auch für Mail aus Azure-VMs empfiehlt Microsoft ein Relay mit Anmeldung auf 587.
Exchange-Journaling braucht nur die eingehende Seite: Der Journal-Empfänger empfängt und sendet nie. Port 25 eingehend an der Cloud-Firewall genügt. Der Empfänger braucht ein öffentlich vertrautes Zertifikat für den Journal-Hostnamen (siehe Exchange-Journaling).
Reverse DNS. Die Journal-Einrichtung von Restow verlangt einen Hostnamen mit A-, AAAA- oder MX-Eintrag und ein passendes Zertifikat, sonst nichts. Ein PTR-Eintrag spielt für Mail eine Rolle, die Sie selbst versenden, nicht für den Journal-Empfänger.
Eine feste Adresse. Die DNS-Einträge und der Exchange-Connector zeigen auf die Adresse der VM. Nehmen Sie in Azure eine öffentliche IP der SKU Standard, die statisch ist, damit das Anhalten der VM sie nicht ändert.

Szenario B: hinter einem vorhandenen Reverse-Proxy im LAN

Nutzen Sie das, wenn ein Reverse-Proxy, zum Beispiel Nginx Proxy Manager, Traefik, HAProxy oder eine Firewall mit Proxy-Plugin wie OPNsense oder Sophos, die Ports 80 und 443 Ihrer öffentlichen Adresse bereits belegt und Anfragen an Hosts im LAN weiterreicht. Das öffentliche Zertifikat liegt auf dem Proxy; Restow steht dahinter. Die Einrichtungsschritte mit Einstellungen für Nginx Proxy Manager, Caddy und Traefik stehen unter Erste Schritte; diese Seite behandelt die Netzwerkseite.

Der Proxy beendet das öffentliche TLS. Browser und Agents verbinden sich mit dem Proxy unter Ihrer öffentlichen Domain, zum Beispiel restow.example.com. Setzen Sie RESTOW_PUBLIC_URL auf diese Origin; Passkeys funktionieren dann wie in jeder öffentlichen Installation.
Die Strecke vom Proxy zu Restow ist standardmäßig verschlüsselt. Ab 0.2.0 setzt die Option --behind-proxy des Installationsskripts RESTOW_EDGE_TLS=internal. Caddy liefert dann Port 443 mit Zertifikaten seiner eigenen internen Zertifizierungsstelle aus, statt Let’s Encrypt zu fragen; der Restow-Host braucht also keinen öffentlichen DNS-Eintrag und keinen Port 80 (das Skript veröffentlicht ihn nur auf dem Loopback). Der Proxy leitet an https://<Restow-Host>:443 weiter und sendet die öffentliche Domain als Servernamen (SNI). Ab 0.2.0 kopiert das Skript das Root-Zertifikat dieser Stelle nach /opt/restow/edge-root-ca.crt, damit der Proxy die Verbindung prüfen kann; erforderlich ist das nicht. Dieselbe Datei liegt als /data/caddy/pki/authorities/local/root.crt im Volume caddy-data; docker compose cp caddy:/data/caddy/pki/authorities/local/root.crt ./edge-root-ca.crt kopiert sie heraus.
Eine unverschlüsselte HTTP-Strecke ist eine Ausnahme. --proxy-hop http (unter 0.1.0 die Einrichtung von Hand) lässt den Proxy unverschlüsselt per HTTP mit Port 80 des Restow-Hosts sprechen, der dann jedem Rechner offensteht, der ihn erreicht; Port 443 wird dabei nur auf dem Loopback veröffentlicht. Nutzen Sie das nur, wenn Proxy und Restow auf einem Host oder in einem abgeschotteten Netz laufen: Passwörter, Session-Cookies, Agent-Secrets und die Mails, die Sie öffnen oder wiederherstellen, laufen dann unverschlüsselt durch das Netz.
Nennen Sie den Proxy in RESTOW_EDGE_TRUSTED_PROXIES: die Adresse des Proxys selbst, zum Beispiel 192.168.10.20/32, nicht Ihr ganzes Netz. Jede eingetragene Adresse darf eine beliebige Client-Adresse angeben; mit einem Bereich oder private_ranges könnte sich jeder Rechner darin im Audit-Log als jemand anderes ausgeben und die Ratenbegrenzung der Anmeldung umgehen. Caddy und die api entnehmen die Client-Adresse dann X-Forwarded-For; Audit-Log, die Annahme des Betreiberhinweises, die Ratenbegrenzung der Anmeldung und die Sperre eines Agents nutzen sie. Ab 0.2.0 setzt die Option --proxy-ip des Installationsskripts sie. Ohne diese Angabe erscheint jeder Client mit der Adresse des Proxys.
Port 25 kann nicht durch einen HTTP-Proxy laufen. Exchange Online (und ein Anbieter, der Kopien weiterleitet) liefert per SMTP mit STARTTLS an Port 25 aus, was ein HTTP-Proxy nicht spricht. Leiten Sie TCP 25 der öffentlichen Adresse per NAT (eine Portweiterleitung am Router oder an der Firewall) direkt an den Restow-Host weiter. Schreiben Sie die Quelladresse nicht um, denn der Empfänger begrenzt die Rate je Absenderadresse und würde alle Absender als einen zählen. Das Zertifikat für den Journal-Hostnamen liegt auf dem Restow-Host, nicht auf dem Proxy: Caddy hält dafür kein Zertifikat (und mit RESTOW_EDGE_TLS=internal gar kein öffentliches), stellen Sie es also mit einem anderen ACME-Client über die DNS-Challenge aus, wie unter Exchange-Journaling beschrieben.
Agents im LAN nutzen denselben öffentlichen Namen. Ein Agent akzeptiert ein Repository nur auf dem Host der öffentlichen URL, einen eigenen internen Namen für ihn gibt es also nicht. Aus dem LAN muss der Name zum Proxy führen: entweder per Split-DNS (Ihr LAN-Resolver antwortet auf restow.example.com mit der Adresse des Proxys) oder per Hairpin-NAT, auch NAT-Loopback oder NAT-Reflection genannt (der Router schickt eine Verbindung aus dem LAN zur öffentlichen Adresse zurück zum Proxy). Split-DNS ist die sauberere Wahl. In beiden Fällen sieht der Agent das öffentliche Zertifikat des Proxys. Agents außerhalb des LANs erreichen die öffentliche Adresse, der Router leitet Port 443 an den Proxy weiter.

Was der Proxy tun muss:

Einstellung	Wert	Warum
Upstream	Ab 0.2.0 der Standard: `https://<Restow-Host>:443`. Mit `--proxy-hop http`: `http://<Restow-Host>:80`.	Auf diesen Ports liefert die Edge Restow aus. `api:3000` ist nicht veröffentlicht und kein Upstream.
Host-Header	Die öffentliche Domain, unverändert	Caddy liefert nur die Site von `RESTOW_APP_DOMAIN` aus.
Graph-Benachrichtigungen	Reichen Sie `/api/v1/hooks/graph/` (die beiden Pfade der Archiv-Erfassung, seit 0.4.4) wie den Rest der Site durch: POST, keine Anmeldung davor, kein Filter, der Microsoft ausschließt	Microsoft Graph ruft diese Pfade aus dem Internet auf. Ohne sie prüft Restow die Postfächer im Intervall (Microsoft ruft die Instanz auf).
Servername (SNI)	Die öffentliche Domain. In nginx: `proxy_ssl_server_name on;` zusammen mit `proxy_ssl_name restow.example.com;` (oder `proxy_ssl_name $host;`)	Standardmäßig nimmt nginx den Namen aus der Upstream-Adresse und sendet für eine IP-Adresse kein SNI; `proxy_ssl_name` legt den Namen fest, der gesendet und geprüft wird. Caddy beantwortet eine Verbindung ohne SNI mit dem Zertifikat von `RESTOW_APP_DOMAIN`. (nginx)
Prüfung	Optional: `proxy_ssl_verify on;` und `proxy_ssl_trusted_certificate` mit dem exportierten Root-Zertifikat	Ohne sie ist die Strecke verschlüsselt, aber der Proxy prüft nicht, wer antwortet.
Client-Adresse	`X-Forwarded-For`, das die meisten Proxys ergänzen	Wird zusammen mit `RESTOW_EDGE_TRUSTED_PROXIES` gebraucht.
Anfragegröße	Mindestens 128 MiB. In nginx: `client_max_body_size 128m;`	Agents laden Packs bis 128 MiB je Objekt hoch. Der nginx-Standard ist 1m und antwortet mit `413`. (nginx)
Zeitlimits	Lang genug für große Downloads. Der Standard von `proxy_read_timeout` in nginx sind 60 Sekunden.	Ein großer ZIP-Download bricht ab, wenn ein Proxy eine ruhende Verbindung trennt (siehe Fehlerbehebung beim Endpoint-Backup).
Streaming	Antworten nicht puffern. In nginx: `proxy_buffering off;`	Der Fortschritt von Aufträgen erreicht den Browser als Server-Sent-Events-Strom, den nginx zurückhält, solange es Antworten puffert. Restow öffnet keinen WebSocket; eine Proxy-Option für WebSocket-Upgrades darf eingeschaltet bleiben, sie schadet nicht.

Regeln für die Firewalls im Beispielnetz des nächsten Abschnitts:

Wo	Richtung	Regel
Router oder Firewall	WAN zu LAN	TCP 443 an den Proxy
	WAN zu LAN	TCP 80 an den Proxy, nur wenn der Proxy sein Zertifikat mit der HTTP-Challenge bezieht (mit der DNS-Challenge ist kein eingehender Port nötig, siehe Let’s Encrypt)
	WAN zu LAN	TCP 25 an den Restow-Host, nur für das Journaling, ohne die Quelladresse umzuschreiben
Proxy-Host	Eingehend	TCP 80 und 443 vom Router
	Ausgehend	TCP 443 zum Restow-Host (mit `--proxy-hop http` TCP 80) und zu Let’s Encrypt
Restow-Host	Eingehend	TCP 443 nur vom Proxy (mit `--proxy-hop http` TCP 80); TCP 25 für das Journaling; TCP 22 von Ihrem Admin-Arbeitsplatz
	Ausgehend	Die Tabelle der ausgehenden Verbindungen, NFS zum NAS und, für die Sicherung von Freigaben, SMB (TCP 445) oder NFS (TCP 2049) zu den Dateiservern
NAS	Eingehend	TCP 2049 (NFS) nur vom Restow-Host
Dateiserver (Freigaben)	Eingehend	TCP 445 (SMB) oder TCP 2049 (NFS) nur vom Restow-Host

Docker ignoriert ufw- und firewalld-Regeln für veröffentlichte Ports; „nur vom Proxy“ gilt auf dem Restow-Host deshalb erst, wenn RESTOW_HTTPS_PORT an eine Adresse gebunden ist oder eine Regel in der Kette DOCKER-USER steht, siehe Erste Schritte → Firewall.

Szenario C: nur im LAN, ohne öffentliche Domain

Das ist der lokale Modus. Die Option --local des Installationsskripts liefert https://localhost oder einen internen Namen wie restow.internal mit einem Zertifikat der Caddy-eigenen Zertifizierungsstelle aus; Browser warnen davor. Das Installationsskript beschreibt --local als Evaluierungsmodus, nicht für den Produktivbetrieb; die folgenden Netzwerkfakten gelten für jede Installation, die nur aus dem LAN erreichbar ist.

Das Backup von Microsoft 365 und IMAP funktioniert. Beides sind ausgehende Verbindungen vom Restow-Host. Beim Microsoft-365-Consent kehrt der Browser der Administration zur Redirect-URI der App-Registrierung zurück; Microsoft selbst verbindet sich für die Sicherung nicht mit Ihrem Server (siehe Die ersten Schritte).
Exchange-Journaling und weitergeleitete Kopien sind nicht möglich. Sie brauchen einen öffentlich erreichbaren Port 25 und ein Zertifikat einer öffentlichen Stelle für einen öffentlichen Hostnamen.
Die Graph-Erfassung fragt ab. Microsoft erreicht eine Installation nur im LAN nicht, deshalb prüft die Archivierung von Microsoft-365-Postfächern über Graph (seit 0.4.4) jedes Postfach alle 15 Minuten, statt benachrichtigt zu werden. Die Archiv-Seite sagt das. Die IMAP-Archivierung funktioniert, weil sie ausgehend ist.
Passkeys werden nicht angeboten. Sie brauchen eine richtige Domain mit gültigem HTTPS-Zertifikat (passkey_ready); die Anmeldung läuft über das Notfall-Passwort mit Authenticator-App. Siehe Einrichtungsassistent.
Agents müssen im LAN sein oder es per VPN erreichen. Sie müssen der lokalen Stelle von Caddy vertrauen, deren Root-Zertifikat als /data/caddy/pki/authorities/local/root.crt im Volume caddy-data liegt: Tragen Sie es in den Zertifikatsspeicher des Betriebssystems ein oder zeigen Sie unter Linux mit SSL_CERT_FILE darauf (siehe Proxy und private CA).
IMAP-Server im LAN werden standardmäßig abgelehnt, siehe die Tabelle der ausgehenden Verbindungen.

Regelsatz des Restow-Hosts:

Richtung	Regel
Eingehend	TCP 443 aus dem LAN, TCP 22 von Ihrem Admin-Arbeitsplatz. Nichts aus dem Internet.
Ausgehend	Die Tabelle der ausgehenden Verbindungen für die Funktionen, die Sie nutzen, zum Beispiel 443 zu Microsoft 365

Beispielnetz

Das Beispiel für Szenario B nutzt einen Router mit der öffentlichen Adresse 203.0.113.10 und dem LAN 192.168.10.0/24. Die Adressen sind Beispiele für die Dokumentation (RFC 5737 und ein privater Bereich); ersetzen Sie sie durch Ihre.

Beispiel für eine Installation hinter einem Reverse-Proxy. Die Adressen sind Beispiele für die Dokumentation (RFC 5737 und ein privates LAN). Die Tabellen darunter nennen dieselben Regeln.

Gerät	Adresse	Rolle
Router und Firewall	`203.0.113.10` (WAN), `192.168.10.1` (LAN)	Leitet 443 und 80 an den Proxy und 25 an die Restow-VM weiter; NAT für ausgehenden Verkehr
Reverse-Proxy	`192.168.10.20`	Hält das öffentliche Zertifikat von `restow.example.com`; leitet mit diesem Servernamen an `https://192.168.10.30:443` weiter
Restow-VM	`192.168.10.30`	Docker-Host mit dem Restow-Stack; Caddy auf 443 mit seiner internen Stelle; Journal-Empfänger auf 25
NAS	`192.168.10.40`	NFS-Freigabe für das Speicherziel
Laptop im LAN	`192.168.10.101`	Agent; das LAN-DNS antwortet auf `restow.example.com` mit `192.168.10.20`
Laptop unterwegs	`198.51.100.23`	Agent; erreicht `restow.example.com` unter `203.0.113.10`

DNS: restow.example.com zeigt im öffentlichen DNS auf 203.0.113.10 und im LAN-Resolver auf 192.168.10.20 (Split-DNS). Der Journal-Hostname archive.example.com zeigt auf 203.0.113.10 und wird auf Port 25 an 192.168.10.30 weitergeleitet.

Verfolgen Sie zwei Verbindungen durch das Beispiel. Ein Laptop unterwegs öffnet HTTPS zu restow.example.com, das zu 203.0.113.10 aufgelöst wird. Der Router leitet Port 443 an den Proxy weiter, der Proxy beendet das öffentliche TLS und öffnet eine neue HTTPS-Verbindung zu 192.168.10.30:443 mit dem Servernamen restow.example.com, und Caddy reicht die Anfrage an die api weiter. Exchange Online öffnet SMTP zu archive.example.com:25. Der Router leitet die Verbindung direkt an 192.168.10.30:25 weiter, wo der Journal-Empfänger im Container api mit STARTTLS antwortet. Keine der beiden Verbindungen berührt den Weg der anderen.

Für Szenario A ist dieselbe Zeichnung kürzer, weil die VM selbst im Internet steht und die Cloud-Firewall Router und Proxy ersetzt (siehe die Zeichnung unter Szenario A). Ihre öffentliche Adresse 203.0.113.50 ist ebenfalls ein Beispiel für die Dokumentation.

Welche Ports muss ich öffnen?

Wenn Sie nutzen	Eingehend öffnen	Ausgehend erlauben
Die Weboberfläche	TCP 443, und TCP 80, solange Caddy sein Zertifikat selbst bezieht	Nichts
Agents auf Servern und Clients	Dieselbe 443. Auf den Endpoints nichts.	Die Endpoints brauchen nur HTTPS zu Ihrer Instanz (`HTTPS_PROXY`, wenn sie hinter einem Proxy sitzen)
Proxmox-VE-Knoten (VMs und Container, Preview)	Dieselbe 443. Auf den Knoten nichts.	Jeder Knoten braucht nur HTTPS zu Ihrer Instanz (`HTTPS_PROXY`, wenn er hinter einem Proxy sitzt). Der Helfer erreicht die Proxmox-VE-API auf `127.0.0.1:8006` auf dem Knoten selbst.
Exchange-Journaling, weitergeleitete Kopien eines Mailanbieters (seit 0.4.4)	TCP 25 direkt zum Empfänger, nie durch einen HTTP-Proxy, und ein Zertifikat für den Journal-Hostnamen	Nichts, der Empfänger sendet nie
Archiv-Erfassung von Microsoft-365-Postfächern über Graph (seit 0.4.4)	Dieselbe 443, von Microsoft erreichbar, mit den beiden durchgereichten Pfaden `/api/v1/hooks/graph/`. Optional: ohne sie prüft Restow jedes Postfach alle 15 Minuten.	443 zu `login.microsoftonline.com` und `graph.microsoft.com`
IMAP-Archivierung (seit 0.4.4)	Nichts	993 oder 143 zu Ihren IMAP-Servern, je Konto eine Verbindung dauerhaft offen mit IDLE
Benachrichtigungs-Mail	Nichts	587 oder 465 zu Ihrem Relay, oder Microsoft Graph `sendMail` über 443
Microsoft-365-Backup	Nichts	443 zu `login.microsoftonline.com`, `graph.microsoft.com` und `*.sharepoint.com`
IMAP-Backup	Nichts	993 oder 143 zu Ihren IMAP-Servern
S3-Speicher	Nichts	443 oder der Port in der Endpoint-URL zum S3-Dienst
NFS-Speicher	Nichts (das NAS muss den Restow-Host zulassen)	Vom Host zum NAS: 2049 (NFS)
Sicherung von Freigaben (SMB und NFS, seit 0.4.0)	Nichts (der Dateiserver muss den Restow-Host zulassen)	Vom Docker-Host zum Dateiserver: 445 (SMB), 2049 (NFS); NFSv3 zusätzlich 111 und der Mount-Daemon
Nur lokales Volume	Nichts	Nichts
Webhooks	Nichts	Der Port in der URL des jeweiligen Ziels
Update-Prüfung und Updater	Nichts	443 zu `api.github.com`, `ghcr.io` und `tuf-repo-cdn.sigstore.dev`
Installation und Updates von Hand	Nichts	443 zu `github.com`, `ghcr.io`, `registry-1.docker.io`, `tuf-repo-cdn.sigstore.dev` (und `download.docker.com`)

Fehlerbehebung

502 am Proxy. Der Proxy erreicht den Host, bekommt aber keine gültige Antwort vom Upstream. Prüfen Sie Schema und Port: https auf 443 (nicht http auf 443 und nicht 3000, das nicht veröffentlicht ist) oder http auf 80 mit --proxy-hop http. Auch ein TLS-Fehler zum Upstream, etwa ein unbekanntes Zertifikat oder ein falscher Servername, endet in 502. Testen Sie auf dem Proxy-Host: curl -sk --resolve restow.example.com:443:192.168.10.30 https://restow.example.com/healthz sollte antworten. Ist die api nicht da, beantwortet Caddy Seitenaufrufe selbst mit seiner Wartungsseite und dem Status 503 (siehe Updates); eine schlichte 502-Seite kommt deshalb meist vom Proxy.
Let’s Encrypt scheitert. Caddy braucht eine RESTOW_APP_DOMAIN, die zum Host aufgelöst wird, und die Ports 80 und 443 müssen es aus dem Internet erreichen. Sehen Sie in docker compose logs caddy nach. Prüfen Sie Router, die Firewall des Anbieters und ob sonst nichts die Ports belegt. Beschränken Sie Port 80 nicht auf eine Liste von Quellen, denn Let’s Encrypt prüft von mehreren Orten. Hinter einem Reverse-Proxy, der das Zertifikat hält, braucht der Restow-Host gar keines von Let’s Encrypt (ab 0.2.0 mit RESTOW_EDGE_TLS=internal, oder mit unverschlüsselter HTTP-Strecke). Siehe Fehlerbehebung.
Die Archiv-Erfassung über Graph prüft im Intervall, obwohl sie benachrichtigt werden sollte. Die Archiv-Seite nennt den Grund. graph.notification_url_unavailable: Die öffentliche URL ist nicht https:// auf 443 oder nennt localhost, eine private Adresse oder einen Host auf .local, .internal oder .lan; korrigieren Sie Installation → Server & Betrieb → Server oder RESTOW_PUBLIC_URL. graph.subscription_failed: Microsoft hat das Abonnement abgelehnt, meist weil es https://restow.example.com/api/v1/hooks/graph/notifications nicht erreichen oder validieren konnte; testen Sie den Pfad von außen, prüfen Sie Proxy und Zertifikat, und Restow versucht es nach einer Stunde erneut. Siehe Quellen verbinden.
Exchange Online erreicht den Journal-Empfänger nicht. Prüfen Sie in dieser Reihenfolge: Der DNS-Eintrag des Journal-Hostnamens zeigt auf die öffentliche Adresse; TCP 25 wird direkt an den Restow-Host weitergeleitet und nicht an den Proxy, und der Anbieter filtert ihn nicht; JOURNAL_SMTP_BIND=0.0.0.0; das Zertifikat passt zum Journal-Hostnamen. Von außen muss openssl s_client -starttls smtp -connect archive.example.com:25 -servername archive.example.com das Zertifikat zeigen. Siehe Exchange-Journaling.
Ein Agent kann sich nicht anmelden oder sichert nicht. Vom Endpoint aus muss curl -fsS https://restow.example.com/healthz antworten. Eine private Zertifizierungsstelle braucht SSL_CERT_FILE oder einen Eintrag im Zertifikatsspeicher, ein Proxy braucht HTTPS_PROXY. Siehe Fehlerbehebung beim Endpoint-Backup.
Ein Proxmox-VE-Knoten kann sich nicht anmelden oder sichert nicht. Vom Knoten aus muss curl -fsS https://restow.example.com/healthz antworten. Ein Proxy braucht HTTPS_PROXY. Siehe Fehlerbehebung beim Proxmox-VE-Backup.
413 beim Hochladen durch Agents oder Proxmox-VE-Knoten. Ein Proxy vor Restow begrenzt den Body. Erhöhen Sie die Grenze auf mindestens 128 MiB.
Das Audit-Log zeigt den Proxy als Client-Adresse. Der Proxy fehlt in RESTOW_EDGE_TRUSTED_PROXIES.
Ein Test oder Lauf einer Freigabe schlägt mit share.unreachable fehl. Der Docker-Host bekommt vom Dateiserver keine Antwort: Prüfen Sie Namen, Routing oder VPN vom Host selbst und dass TCP 445 oder 2049 vom Restow-Host aus offen ist. Siehe Freigaben: Fehlerbehebung.
Ein veröffentlichter Port ignoriert Ihre ufw-Regel. Docker umgeht sie, siehe Szenario A. Filtern Sie an der Cloud-Firewall.
Benachrichtigungs-Mail aus einer Cloud-VM scheitert. Port 25 ist bei Hetzner und Azure standardmäßig gesperrt. Nehmen Sie 587 oder Microsoft Graph sendMail.

Quellen

Hetzner: FAQ zu Cloud-Servern, Mailversand, Firewalls im Überblick, Firewall anlegen
Microsoft Azure: Troubleshoot outbound SMTP connectivity, Network security groups, Public IP addresses
Microsoft 365: URLs and IP address ranges, weitere Endpunkte
Caddy: Automatic HTTPS; Let’s Encrypt: Challenge Types
Docker: Packet filtering and firewalls, Docker with iptables
nginx: ngx_http_proxy_module, ngx_http_core_module
Port von NFS: RFC 7530, NFS Version 4
Adressen für Dokumentation: RFC 5737