noroot 9137c07c95 fix(tls): Management-Zertifikat des Standby lief ab und erneuerte sich nie
Auf utm-2 war das Zertifikat der Management-UI seit dem 28.08. abgelaufen
(entdeckt am 11.09.) und haette sich aus eigener Kraft nie wieder
erneuert. Zwei Ursachen trafen zusammen:

1) Das FQDN eines per Join dazugekommenen Nodes landet in KEINER
   tls_certs-Zeile — es wird beim Setup einmalig ausgestellt und danach
   von niemandem mehr angefasst. certrenewer arbeitet nur die Tabelle ab
   und sieht es deshalb nie. (utm-1 steht dort drin, weil sein FQDN beim
   Erst-Setup regulaer als Domain angelegt wurde — deshalb fiel es dort
   nicht auf.)
2) Der Scheduler blockt auf einem Nicht-VIP-Master jede ACME-Erneuerung
   (v1.3.20). Fuer geteilte Domains ist das richtig: die zeigen per DNS
   auf die VIP, nur der Master kann die Challenge bestehen. Fuer das
   eigene Management-FQDN stimmt es nicht — utm-2.netcell-it.de zeigt auf
   89.163.205.8, die eigene IP des Nodes, und Port 80 antwortet dort.

Neu: runManagementCertRenew laeuft auf JEDEM Node unabhaengig von der
VIP, aber ausschliesslich fuer das eigene FQDN aus setup.json. Prueft die
Restlaufzeit der Datei unter /etc/edgeguard/tls und erneuert ab 30 Tagen
Rest (gleicher Schwellwert wie bei den Domain-Certs).

Bewusst NICHT ueber tls_certs: das ist eine replizierte Shared-Table, und
cluster-reconcile-replication TRUNCATEt solche Tabellen beim Refresh —
eine lokal auf dem Subscriber eingefuegte Zeile waere beim naechsten
Paket-Upgrade wieder weg. Das Management-Zertifikat ist node-lokale
Infrastruktur und wird wie die cluster-tls-Certs als reine Datei
behandelt. Existiert dagegen bereits eine tls_certs-Zeile fuer das eigene
FQDN (Fall utm-1), bleibt alles beim Alten und certrenewer behaelt die
Zustaendigkeit — sonst haetten zwei Mechanismen dieselbe Datei.

Tests decken die Schwellwert-Entscheidung ab, inklusive des
utm-2-Falls (bereits abgelaufen) und kaputter PEM-Dateien.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-11 12:02:26 +02:00
2026-05-08 18:45:41 +02:00
2026-09-11 11:52:15 +02:00

EdgeGuard

Native Reverse-Proxy / Loadbalancer / Forward-Proxy / VPN / Firewall — als signiertes .deb für Debian 13 + Ubuntu 24.04, amd64 + arm64.

Status: v0.x — Neufassung des bisherigen Docker-Stacks, parallel zum Bestand proxy-lb-waf.

Installation

curl -fsSL https://get.edgeguard.netcell-it.de | sudo bash

Unterstützte Plattformen: Debian 13 (Trixie), Ubuntu 24.04 LTS (Noble) — amd64 + arm64.

Architektur in Kürze

  • Daten-Services (v1): HAProxy (TLS-Termination + LB + L7-Routing), Squid, WireGuard, Unbound, nftables — alle nativ via APT, Configs aus PostgreSQL generiert.
  • Control-Plane: edgeguard-api (Go/Gin), management-ui (React/AntD), PostgreSQL 16, KeyDB Active-Active.
  • Cluster: N symmetrische Peers, KeyDB AA für Shared State, PG Streaming Replication, Floating-IP des Hosters statt VRRP.
  • Auslieferung: signierte .deb, Update via apt. Update-Trigger via UI/API.

Volle Architektur: docs/architecture.md.

Build

make build       # Host-Architektur
make deb         # amd64 + arm64 .deb
make publish     # deb + Upload Gitea Package Registry

Repo

  • Lokal: /var/www/edgeguard-native
  • Gitea: https://git.netcell-it.de/projekte/edgeguard-native
Description
EdgeGuard Native — Reverse-Proxy / Loadbalancer / Forward-Proxy / VPN / Firewall ohne Docker, .deb-Auslieferung fuer Debian 13
Readme 14 MiB
Languages
Go 52.8%
TypeScript 36.4%
Shell 4.6%
CSS 4.4%
Smarty 1.5%
Other 0.3%