Private Verbindungen zwischen Servern, ohne VPN und ohne offene Ports
Wie Dienste, Datenbanken und Server in verschiedenen Clouds in Opfield einander erreichen: ausgehende Verbindungen mit mTLS, Secure Links über Relays, private Datenbanken mit einem Nutzer pro Verbindung und was Opfield Ihnen überlässt.
Autor: Opfield-Team4 Min. LesezeitAktualisiert
Ein typisches Setup: Die API läuft bei einem Cloud-Anbieter, ihre Datenbank bei einem anderen und die öffentliche Website auf einem dritten Server. Um sie zu verbinden, bauen Teams meist ein VPN zwischen den Servern oder öffnen den Datenbank-Port und beschränken ihn auf eine Liste von Adressen. Beides funktioniert, und beides bringt etwas zu pflegen und etwas anzugreifen.
Opfield geht einen anderen Weg. Ihre Server verbinden sich nur nach außen, und privater Verkehr zwischen ihnen läuft über Relays auf authentifizierten Verbindungen. Im Folgenden, wie das funktioniert und wo die Grenzen liegen.
Server verbinden sich nach außen, nichts wartet auf sie
Ihre Server brauchen keine offenen Management-Ports. Auf jedem Server laufen kleine Opfield-Daemons, die sich nach außen zum Relay von Opfield verbinden, normalerweise auf 9443/tcp. Die Verbindung ist immer TLS, und die Daemons bieten im Netz keine Management-API an. Ein Server in jeder Cloud oder hinter NAT kann beitreten, solange er das Relay erreicht.
Jeder Server weist nach, wer er ist
Einen Server hinzuzufügen braucht einen Setup-Befehl. Er enthält ein einmaliges Registrierungs-Token und den Fingerabdruck des Opfield-Zertifikats. Beim ersten Start prüft der Daemon dieses Zertifikat, bevor er irgendetwas sendet. Nur wenn der Fingerabdruck passt, sendet er das Token, sodass ein falscher DNS-Eintrag oder ein Proxy auf dem Weg es nicht abfangen kann.
Opfield stellt dem Server dann ein eigenes mTLS-Zertifikat aus der internen Zertifizierungsstelle von Opfield aus. Der Daemon entfernt das Token aus seiner Konfiguration und verbindet sich mit dem Zertifikat neu. Ab dann ist das Zertifikat die Identität des Servers, und Opfield prüft es bei jedem Stream. Es gibt kein gemeinsames Geheimnis, das durchsickern könnte, und das Löschen eines Servers widerruft sein Zertifikat, sodass sich der alte Daemon nicht mehr als dieser Server verbinden kann.
Öffentlicher Verkehr erreicht einen Dienst ohne veröffentlichten Port
Eine Route auf einem öffentlichen nginx-Server kann auf einen Container, ein Deployment oder einen Compose-Dienst auf einem anderen Server zeigen. Opfield verbindet beide mit einem Secure Link: einer authentifizierten privaten Verbindung über das Relay. Der Dienst veröffentlicht keinen Host-Port, und die Route findet ihn über seine Identität, sodass ein Neustart oder ein neues Release keine Änderung an der Route braucht. Secure Links gibt es in jedem Plan, auch in Community.
Datenbanken bleiben privat
Verwaltete PostgreSQL-Datenbanken, Key-Value-Stores und ClickHouse sind standardmäßig privat. Wenn Sie eine Anwendung mit einer Datenbank verbinden, fügt Opfield dem Container ein privates Netzwerk hinzu, gibt ihm die Verbindungsvariablen und leitet den Verkehr durch einen authentifizierten Tunnel über das Relay. Die Datenbank lauscht auf keinem öffentlichen Port.
Jede Verbindung erhält einen eigenen Datenbanknutzer: eine eigene Postgres-Rolle, einen ACL-Nutzer im Key-Value-Store oder einen ClickHouse-Nutzer. Die Anwendung erhält nie die Zugangsdaten des Eigentümers, und das Löschen der Verbindung widerruft diesen Nutzer. Braucht ein externes Werkzeug direkten Zugriff, ist das Veröffentlichen eines Datenbank-Ports eine bewusste Entscheidung. Es setzt Datenbank-Authentifizierung voraus, und Opfield öffnet dafür nicht die Host-Firewall. Verwaltete Datenbanken gibt es ab Personal.
Das Relay läuft als eigener, langlebiger Dienst, getrennt von der Opfield-Anwendung. Gewöhnliche Opfield-Updates erstellen es nicht neu, sodass bestehende Datenbanksitzungen weiterlaufen, während die Anwendung neu startet.
Mehr als ein Relay
Privater Verkehr muss nicht von einer Maschine abhängen. Neben dem Relay, das mit Opfield kommt, können Sie Relays auf weiteren Hosts hinzufügen und so einen Relay Pool bilden. Als Fehlerdomäne eines Relays gilt sein physischer Host, deshalb zählen zwei Relays auf demselben Host nicht als redundant.
Neue Verbindungen werden auf die bereiten Relays verteilt. Wenn Sie ein Relay leeren (Drain), gehen neue Verbindungen an die anderen, während bestehende Streams weiterlaufen. Relay-Updates sind signiert und werden ein Relay nach dem anderen ausgerollt. Anwendungen sehen eine logische Verbindung und müssen nicht wissen, welches Relay sie trägt. Opfield bleibt die Steuerungsebene: Ihre Daten laufen über die Relays, nicht durch die Opfield-Anwendung.
Was Opfield nicht tut
Das ist kein VPN und will auch keines sein. Opfield öffnet keine Firewalls, bietet kein NAT-Traversal und baut kein Overlay-Netzwerk auf. Die Server bleiben unabhängig, zwischen ihnen wird kein Vertrauen eingerichtet.
Einiges bleibt bei Ihnen:
- Jeder Server muss die ihm zugewiesenen Relays erreichen, standardmäßig auf
9443/tcp. Ein Relay ist die einzige Stelle, die eingehende Verbindungen von Ihren Servern annimmt. - Öffentliche nginx-Server brauchen offene Ports
80/tcpund443/tcpfür Web-Verkehr. - Ein Secure Link schützt den Transport und die Wahl des Ziels. Wer Ihre Anwendung aufrufen darf, entscheidet weiterhin die Anwendung.
Mehr erfahren
Die Dokumentation beschreibt Schritt für Schritt die Registrierung von Knoten, den Relay Pool, sichere Upstreams und Datenbankverbindungen, einschließlich der Firewall-Regeln für jede Art von Server.