Nextcloud nur über VPN: zuerst alle Zugänge erfassen

Ein Nextcloud-Konzept nur über VPN scheitert, wenn es den Browser schützt und den Sync-Client vergisst. Die Webseite, die Desktop-Synchronisierung, mobile Uploads, WebDAV-Werkzeuge und Empfänger geteilter Links brauchen alle einen Weg zum selben Dienst, und jeder davon kann einen anderen Zugang offenlegen. Erfassen Sie sie, bevor Sie etwas schließen. Diese Liste ist der eigentliche Perimeter.

Arbeiten Sie die Checkliste der Reihe nach ab. Der erste Punkt legt fest, was privat für dieses Deployment bedeutet; die späteren Punkte prüfen, ob das Deployment dieser Definition tatsächlich entspricht.

Definieren Sie privat, bevor Sie den Perimeter ändern

Schreiben Sie die Anforderung in einem Satz auf: Jeder Benutzer muss dem VPN beitreten, bevor er die Anwendung erreicht, oder die Anwendung darf öffentlich bleiben, während ihr Ursprung privat bleibt. Das sind unterschiedliche Entwürfe, und ein öffentlicher Reverse-Proxy, der in einen privaten Tunnel weiterleitet, erfüllt nur den zweiten.

Eine private Backend-Adresse macht die Anwendung nicht privat. Wenn eine öffentliche Zuordnung, ein zweiter Hostname oder ein IPv6-Listener dieselbe Nextcloud-Instanz weiterhin erreicht, existiert der Zugang unabhängig davon, wo das Backend liegt. Prüfen Sie jeden Namen von außen, bevor Sie den Dienst als privat erklären. Ein fehlender DNS-Eintrag ist nicht dasselbe wie ein geschlossener Port.

Einigen Sie sich auch auf die Zielgruppe: Mitarbeiter, ein Haushalt, eine Partnerorganisation oder eine Teilmenge von Konten. Die Antwort entscheidet, ob ein öffentlicher Freigabelink ein Merkmal oder ein Widerspruch ist. Schreiben Sie diese Zielgruppe in den Zugangsplan. Sie ist der Prüfstein für jede folgende Ausnahme.

Erfassen Sie jeden Zugang und jeden Namen

Listen Sie öffentliche Adresszuordnungen, Reverse-Proxys, alternative Hostnamen, IPv6-Listener und jede Tunnel- oder Mesh-Adresse auf, die den Dienst erreicht. Nehmen Sie die Namen auf, die auf diese Adressen auflösen, denn ein vergessener DNS-Eintrag ist ein Zugang mit freundlicher Beschriftung.

Prüfen Sie die Proxy-Konfiguration auf weitergeleitete Header und alternative Server-Blöcke. Ein Proxy, der für eine andere Anwendung hinzugefügt wurde, kann denselben Upstream über einen Pfad oder einen übrig gebliebenen virtuellen Host offenlegen. Lesen Sie die tatsächliche Konfiguration statt des geplanten Diagramms. Beide weichen am häufigsten voneinander ab, nachdem eine Anwendung verschoben wurde.

Blockieren Sie dann die Zugänge, die Sie nicht gewählt haben. Ein privates Backend mit einem öffentlichen Frontend ist kein reines VPN-Design, und eine Firewall-Regel, die nur IPv4 abdeckt, lässt den IPv6-Listener offen. Schließen Sie beide Familien und beide Namen in derselben Änderung.

Geben Sie jedem Client einen Dienstnamen

Richten Sie privates DNS auf den Dienst, leiten Sie diesen Namen durch das VPN und stellen Sie das Zertifikat dafür aus. Der Name muss über den privaten Pfad aufgelöst werden und ohne Warnung validieren. Ein Client, der die IP direkt erreicht, braucht den Namen trotzdem.

Clients, die sich über eine unabhängige IP-Adresse verbinden, sollten keine Zertifikatsfehler wegklicken müssen, damit das Design funktioniert. Ein stabiler Name verhindert außerdem, dass Sync-Clients doppelte Servereinträge anlegen, wenn sich eine Adresse ändert. Das ist der Unterschied zwischen einem privaten Dienst und einer privaten IP.

Lassen Sie die Zertifikatsvalidierung aktiviert. Ein privates Netz verringert die Angriffsfläche, macht aber eine ungeprüfte TLS-Verbindung nicht akzeptabel, und ein Client, der Warnungen ignorieren gelernt hat, wird sie auch in anderen Netzen ignorieren.

Begrenzen Sie den Netzzugang, nicht das ganze LAN

Erlauben Sie eingetragenen Benutzern, den Nextcloud-Dienst und seine nötigen Abhängigkeiten zu erreichen, und halten Sie die Serververwaltung auf einem separaten Pfad. Ein VPN, das einen Client in das gesamte Heim- oder Büronetz lässt gibt diesem Client weit mehr, als die Anwendung verlangt.

Der VPN-Zugang ersetzt keine Nextcloud-Konten, Berechtigungen oder zusätzliche Authentifizierung. Die Anwendung entscheidet weiterhin, welcher Benutzer welche Datei lesen darf, und die Netzschicht sollte nicht die einzige Kontrolle sein.

Halten Sie den genehmigten Quellbereich und die Dienstports fest. Der Zielverantwortliche braucht die beobachtete Quelle, und NAT oder Proxy können sie umschreiben, bevor die Anfrage die Anwendung erreicht.

Prüfen Sie jeden Ablauf außerhalb des Browsers

Desktop-Synchronisierung und mobile Uploads öffnen ihre eigenen Verbindungen zu ihren eigenen Zeiten. Sie brauchen den genehmigten privaten Pfad, wenn sie sich verbinden, und sie können sich anders verhalten, wenn das VPN fehlt: erneut versuchen, pausieren oder einen Fehler anzeigen. Testen Sie jeden davon, nicht nur den Browser.

WebDAV-Werkzeuge und Kalender- oder Kontakt-Clients sind eigene Integrationen mit eigener Konfiguration. Ein Client, der eine öffentliche URL zwischenspeichert, versucht diese URL nach der Perimeteränderung weiter, und der Fehler sieht wie ein Anwendungsproblem aus.

Geteilte Links verdienen eine ausdrückliche Entscheidung. Ein Link gewährt seinem Empfänger keinen VPN-Zugang, daher kann ein externer Empfänger ihn in einem echt reinen VPN-Design nicht nutzen, obwohl der Link gültig ist. Wenn Teilen nach außen nötig ist, ist das eine bewusste Ausnahme mit eigenem Zugangspfad, kein Versehen, das man später entdeckt.

Federation und Server-zu-Server-Integrationen brauchen dieselbe Behandlung. Sie sind Erreichbarkeitsbeziehungen zwischen Installationen, und ein rein privates Deployment muss sagen, ob sie unterstützt werden.

Akzeptieren Sie sowohl den erlaubten als auch den abgelehnten Fall

Prüfen Sie von einem freigegebenen Client aus die Weboberfläche und einen gewöhnlichen Datei-Upload oder -Download. Prüfen Sie dann einen Sync-Client und einen Ablauf außerhalb des Browsers. Erfolg nur im Browser ist keine Abnahme.

Bestätigen Sie von einem nicht freigegebenen Pfad aus, dass die Anwendung über jeden Zugang im Inventar unerreichbar ist. Testen Sie den alternativen Hostnamen und die IPv6-Adresse, nicht nur die primäre URL.

Prüfen Sie schließlich die Anwendungseinstellungen, die leicht mit Netzwerkrichtlinien verwechselt werden. trusted_domains listet Namen, die die Instanz akzeptiert; es ist keine Allowlist für Client-IPs. Wenn ein Reverse-Proxy Adressinformationen liefert, trusted_proxies muss den tatsächlichen Proxy benennen, und weitergeleitete Header sollten nur von ihm akzeptiert werden.

Setzen Sie die normale Härtungsarbeit neben der Netzänderung fort: Halten Sie Daten und Backups aus ungewollten Webpfaden heraus, patchen Sie die Anwendung, schützen Sie den Administratorzugang und halten Sie die Wiederherstellung nutzbar. Ein VPN entfernt eine Zugangsfläche; es macht einen eingetragenen Client nicht vertrauenswürdig.