Ports und Netzwerkpfade
Der Plattformverantwortliche legt Platzierung und Dienstadressen fest, der Netzwerkverantwortliche genehmigt die Pfade, und die Dienstverantwortlichen entscheiden, welche öffentlichen Endpunkte ihre Anwendungen benötigen. Die Host-Firewalls bleiben in Ihrer Verantwortung: Opfield öffnet sie nicht und bietet keine NAT-Traversierung.
Das Standardziel ist einfach: Benutzer erreichen Opfield und den öffentlichen Ingress über HTTPS; verwaltete Nodes bauen authentifizierte ausgehende Verbindungen zu Relay auf; interne Datenbanken und Steuerschnittstellen bleiben privat. Fügen Sie eine Offenlegung nur für einen dokumentierten Produktpfad hinzu.
Übersicht der Konnektivität
Abschnitt betitelt „Übersicht der Konnektivität“| Pfad | Zweck |
|---|---|
| Client -> Opfield HTTPS | Konsole, REST, OAuth, MCP, WebSockets, Inferenz-Proxy |
Verwalteter Daemon -> Relay 9443/tcp |
Authentifizierte ausgehende Steuerung und unterstützter Tunnelverkehr |
Internet -> nginx 80/tcp |
HTTP und ACME HTTP-01, wo verwendet |
Internet -> nginx 443/tcp |
Öffentliche HTTPS-Routen und Pages |
| Opfield/Daemon -> externe Anbieter | DNS, OIDC, E-Mail, Git, Registries, Updates, ACME, KI-Anbieter |
| Interne Opfield-Dienste | PostgreSQL, Redis, internes gRPC, Callbacks des Inferenzkerns |
Relay – nicht die Opfield-Anwendung – ist der öffentliche Eigentümer von 9443/tcp. Entfernte Relay-Worker müssen Datenendpunkte ankündigen, die von den zugewiesenen verwalteten Hosts erreichbar sind.
Halten Sie PostgreSQL, Redis, internes gRPC, den Inferenzkern, Owner-Ports von Datenbanken, Steuerschnittstellen der Daemons und Binding-spezifische Docker-Netzwerke privat.
Richtung der Konnektivität
Abschnitt betitelt „Richtung der Konnektivität“Verwaltete Daemons bauen ausgehende authentifizierte Verbindungen zu Relay auf. Operatoren legen Steuerports von Daemons normalerweise nicht gegenüber Opfield offen. Entfernte Relay-Worker sind die Ausnahme: Ihr angekündigter Endpunkt 9443/tcp muss von den ihnen zugewiesenen verwalteten Hosts erreichbar sein.
Ingress Nodes empfangen öffentlichen Anwendungsverkehr auf den Ports 80 und 443 gemäß den Anforderungen von Route und ACME. Docker und Storage Nodes benötigen für Secure Links keine öffentlichen Workload- oder Owner-Ports. Ein veröffentlichter Endpunkt einer verwalteten Datenbank ist eine ausdrückliche Zustimmung und sollte unabhängig eingeschränkt werden.
Firewall-Planung
Abschnitt betitelt „Firewall-Planung“| Quelle | Ziel | Erforderlich, wenn |
|---|---|---|
| Benutzer/Browser | Opfield HTTPS | Konsole, REST, OAuth, MCP, WebSockets, Inference |
| Verwalteter Node | zugewiesenes Relay 9443/tcp |
Immer für verwaltete Steuerung und unterstützte Tunnel |
| Docker Node einer Availability-Richtlinie im Lease-Modus und Ingress Node ihrer Routen | jedes Relay des Pools, standardmäßig 9443/tcp |
Failover der Datenebene: Lease-Verkehr und Secure Links der Mitglieder verwenden jedes Relay |
| Internet/Client | Ingress 80/tcp |
HTTP-Route oder ACME HTTP-01 |
| Internet/Client | Ingress 443/tcp |
HTTPS-Routen und Pages |
| Opfield/Node | DNS- und Update-Endpunkte | Namensauflösung und Herunterladen signierter Updates |
| Opfield/Build Worker | Git- und Registry-Anbieter | Erkennung von Quellen, Build-Eingaben, Push/Pull |
| Opfield | OIDC, SMTP, DNS, Webhook, SIEM, KI-Anbieter | Nur aktivierte Integrationen |
| Anwendungsclient | veröffentlichter TLS-Port der Datenbank | Nur wenn der direkte Zugriff bewusst aktiviert ist |
| Opfield | Lizenzdienst über HTTPS: license.opfield.dev oder die in LICENSE_SERVICE_URL gesetzte Adresse |
Registrierung und Heartbeats; Aktivierung kostenpflichtiger Schlüssel; Opfield-Updates einer Installation, die einen kostenpflichtigen Tarif hat oder hatte (Community-Installationen ohne Schlüssel werden auch aktualisiert, wenn der Dienst nicht erreichbar ist). |
| Opfield | Update-Dienst get.opfield.dev über HTTPS |
Release-Prüfungen und signierte Downloads |
| Opfield | Cloud-Konto account.opfield.dev über HTTPS |
Nur solange die Opfield Cloud verbunden ist; eine ausgehende Verbindung |
| Speicher-Client | S3-Port des verwalteten Speichers (standardmäßig 9000) | Nur wenn die Veröffentlichung bewusst aktiviert ist |
| Storage Node | ghcr.io, dann Docker Hub als Ausweichlösung |
Herunterladen von Images verwalteter Datenbanken und Speicher; der Backup-Runner kommt nur von ghcr.io |
| Docker Node | ghcr.io, dann Docker Hub als Ausweichlösung |
Herunterladen der festgelegten Compose-Laufzeit |
| Storage Node als Backup-Executor | externe Datenbanken, Speicherendpunkte und ghcr.io |
Backups und Wiederherstellungen von Datenbanken |
| Externes Key-Value-Ziel einer Wiederherstellung | Dienst-IP des Executors, TCP 20000–39999 | Nur während einer Wiederherstellung in einen externen Key-Value-Store |
| Externer ClickHouse-Server | S3-Staging-Endpunkt | Backups und Wiederherstellungen von externem ClickHouse |
Verwenden Sie Allowlists der Anbieter und Egress-Richtlinien, wo es praktikabel ist, berücksichtigen Sie aber Zertifikatsprüfung, Weiterleitungen, DNS sowie Paket- und Registry-Endpunkte, die die gewählte Funktion benötigt. Verwenden Sie keine breite „alles erlauben“-Regel, um eine ungeklärte Abhängigkeit zu verdecken.
Auswahl der Adressen
Abschnitt betitelt „Auswahl der Adressen“Opfield erfasst gemeldete lokale und öffentliche Adressen sowie rollenspezifische Dienstadressen. Wählen Sie Adressen anhand des tatsächlichen Pfads der Gegenstelle: öffentliche Clients zum Ingress, verwaltete Hosts zu Relay, Docker-Operationen zwischen Nodes zu erreichbaren Dienstadressen und Datenbankzertifikate zu den veröffentlichten Dienst-IPs.
Das Ändern einer Adresse kann DNS-Aktualisierungen, eine Zertifikatsrotation, eine Routenmigration oder eine Neuverteilung von Relay erfordern. Prüfen Sie jede Gegenstelle, bevor Sie den alten Pfad entfernen.
Prüfung
Abschnitt betitelt „Prüfung“Testen Sie aus dem tatsächlichen Quellnetzwerk, nicht nur vom Zielhost aus. Bestätigen Sie DNS, TCP-Erreichbarkeit, TLS-Identität, das Verhalten des HTTP- oder gRPC-Protokolls und den von Opfield gemeldeten Health-Zustand. Eine erfolgreiche TCP-Verbindung allein beweist weder Authentifizierung noch Anwendungsbereitschaft.
Änderungs- und Rollback-Verfahren
Abschnitt betitelt „Änderungs- und Rollback-Verfahren“Bevor Sie eine öffentliche Adresse, einen Relay-Endpunkt, eine Firewall-Regel, einen DNS-Eintrag oder eine Zertifikatsidentität ändern, listen Sie jede Gegenstelle auf, die den Pfad verwendet, und legen Sie einen Zeitraum fest, in dem alter und neuer Pfad parallel bestehen. Senken Sie die DNS-TTL nur, wenn DNS Teil der Änderung ist, und tun Sie es früh genug, damit es wirkt. Halten Sie den alten Weg verfügbar, bis externe Prüfung und erneute Verbindungen der verwalteten Nodes den neuen Pfad bestätigen.
Setzen Sie zurück, indem Sie die vorherige Adresse, den DNS-Wert, das Zertifikat oder die Zuweisung als eine koordinierte Änderung wiederherstellen. Vermeiden Sie ein Hin- und Herwechseln zwischen Konfigurationen, solange Caches und langlebige Verbindungen noch aktiv sind. Prüfen Sie nach dem Rollback Relay-Sitzungen, Aktualität der Nodes, Routen, Pages, Datenbank-Bindings, Webhooks und den von der Installation genutzten ausgehenden Verkehr zu Quellen und Anbietern.
Diagnose für Operatoren
Abschnitt betitelt „Diagnose für Operatoren“Verwenden Sie eine Prüfung Ebene für Ebene von der tatsächlichen Quelle aus:
- DNS liefert die vorgesehene Adresse.
- Netzwerkpfad und Firewall erlauben den dokumentierten Zielport.
- TLS präsentiert die erwartete Identität und eine vertrauenswürdige Kette.
- Das Anwendungsprotokoll schließt Authentifizierung oder Health Checks ab.
- Opfield erhält einen frischen, vom Eigentümer gemeldeten Zustand.
Halten Sie fest, welche Ebene fehlschlägt. Das Öffnen weiterer Ports behebt kein Problem mit Zertifikat, Autorisierung, Richtlinie oder Anwendungsbereitschaft.