9137c07c952f0666456b0a7f1a5994168eefefe8
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>
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 viaapt. 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
Languages
Go
52.8%
TypeScript
36.4%
Shell
4.6%
CSS
4.4%
Smarty
1.5%
Other
0.3%