docs: rohana does not belong outside — an external allowance drops out

The owner pointed out that rohana is still reachable over the private
network and need not be called externally. Measured and correct: 10.0.0.3
answers as Gitea for the public host header and serves a valid Let's
Encrypt certificate for that very name, validated with full verification.

So the private path is not just reachable but TLS-clean, and no service
needs reconfiguring. What is missing is only the internal pointer - the
Corefile already imports the custom override directory, the ConfigMap
simply does not exist yet.

Two of the four class B workloads therefore stop leaving the cluster, and
the Gitea exception recorded in AGENTS.md becomes an internal rule. The
storage box stays external: no private path was named for it and I am not
assuming one.

The price is written into the design rather than skipped. An internal
pointer turns two paths into one - if 10.0.0.3 is down, rohana is
unreachable from the cluster although the public route would work, and the
failure would look like "Gitea is gone" instead of "the private path is
gone".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM

docs/design/2026-08-21-egress-vollstaendig.md

@@ -302,4 +302,49 @@ aus einem ausgelösten Lauf.
 4. **`nc -z` misst TCP-Verbindungsaufbau, nicht Nutzbarkeit.** Für UDP
    (coturn, SFU) sagt es nichts — deren Prüfung braucht einen echten Call.
 
-> **STOP — Freigabe für Gate 3.**
+### Nachtrag zu Gate 3 — rohana gehört nicht nach draußen
+
+**Einwand sorb, 2026-08-21:** *„rohana ist immer noch über das private Netz
+theoretisch erreichbar und muss nicht extern aufgerufen werden."* Zutreffend,
+und nachgemessen:
+
+| Messung | Ergebnis |
+|---|---|
+| Private Adressen mit offenem `:443` | `10.0.0.2`, `10.0.0.3`, `10.0.0.4` |
+| Wer antwortet als rohana? | **`10.0.0.3`** — HTTP 200 mit Gitea bei `Host: rohana.axion1337.de` |
+| Trägt der private Endpunkt ein gültiges Zertifikat? | **ja** — `rohana.axion1337.de`, Aussteller Let's Encrypt, mit voller Prüfung validiert |
+
+Der private Weg ist also nicht nur erreichbar, sondern **TLS-sauber**. Kein
+Dienst muss umkonfiguriert werden, keine Ausnahme bei der Zertifikatsprüfung.
+
+**Warum es heute trotzdem nach draußen geht:** `rohana.axion1337.de` löst im
+Cluster auf die öffentliche Adresse auf — es fehlt nur der interne Zeiger.
+Die Corefile importiert bereits `/etc/coredns/custom/*.override`; die
+ConfigMap `coredns-custom` existiert schlicht noch nicht.
+
+**Änderung am Entwurf:**
+
+| | vorher | jetzt |
+|---|---|---|
+| `turn-secret-rotation` | `188.245.193.243/32` (öffentlich) | Zeiger auf `10.0.0.3`, Erlaubnis `10.0.0.3/32` |
+| `wikijs` (git-storage) | dito | dito |
+| `synapse-backup`, `wikijs-backup` | `91.98.246.178/32` | **unverändert** — für die Storage Box wurde kein privater Weg genannt und ich nehme keinen an |
+
+Damit verlassen von Klasse B nur noch die beiden Backups den Cluster, und
+die Gitea-Ausnahme aus `AGENTS.md` wird zu einer internen Regel.
+
+⚠️ **Der Preis, benannt statt übergangen:** Ein interner Zeiger macht aus
+zwei Wegen einen. Fällt `10.0.0.3` aus, ist rohana aus dem Cluster nicht
+mehr erreichbar, obwohl der öffentliche Weg funktionieren würde — und der
+Fehler sähe aus wie „Gitea ist weg", nicht wie „der private Pfad ist weg".
+Das gehört in den Kommentar der ConfigMap, damit die nächste Fehlersuche
+nicht dort anfängt, wo sie zuletzt aufgehört hat.
+
+**Zusätzliche Prüfung in Welle 2:** Nach dem Setzen des Zeigers muss aus
+einem Pod heraus gezeigt werden, dass `rohana.axion1337.de` auf `10.0.0.3`
+auflöst **und** die TLS-Prüfung weiterhin durchgeht — beides in einem Lauf,
+sonst ist „geht noch" wieder eine Vermutung.
+
+> **STOP — Freigabe für Gate 3** samt diesem Nachtrag. Der CoreDNS-Zeiger
+> wirkt clusterweit; das ist die einzige Änderung hier, die über die
+> NetworkPolicies hinausgeht.

docs/ledger/2026-08-21-egress-vollstaendig.md

@@ -27,9 +27,23 @@ related:
 | ob IPv6 eine Umgehung waere | podCIDRs nur IPv4, v6-Verbindung scheitert mit OSError | reused: IPv4-CIDRs genuegen — kein Zusatzaufwand fuer eine Adressfamilie, die es nicht gibt | |
 | das git-storage-Ziel von wikijs, statt es zu raten | steht nicht im Manifest, sondern in der Wiki.js-Datenbank: `https://rohana.axion1337.de/sorb/ThreadNetWiki.git` | reused: die laufende Konfiguration als Quelle — Klasse B bestaetigt | |
 | ob die Sperre von gestern ueberhaupt beisst, bevor neue dazukommen | drei echt externe Ziele blockiert, die Knoten-Adresse erreichbar | built: nichts — aber der Fund aendert die Klasseneinteilung und gehoert ins Issue | |
+| einen privaten Weg zu rohana, auf sorbs Einwand hin | `10.0.0.3:443` antwortet als Gitea und traegt ein gueltiges Let's-Encrypt-Zertifikat fuer den oeffentlichen Namen | reused: der vorhandene private Pfad statt einer Erlaubnis nach draussen — kein Dienst muss umkonfiguriert werden | |
+| einen Weg, den Namen intern umzubiegen | die Corefile importiert bereits `/etc/coredns/custom/*.override`; nur die ConfigMap fehlt | reused: der vorgesehene k3s-Mechanismus, keine Aenderung an der Corefile selbst | |
 
 ## Notes
 
+**sorbs Einwand hat eine Erlaubnis nach draussen ueberfluessig gemacht.**
+Der Entwurf wollte rohana als oeffentliches `/32` freigeben; tatsaechlich
+ist der Host privat erreichbar und traegt dort dasselbe gueltige
+Zertifikat. Aus einer externen Ausnahme wird damit eine interne Regel — und
+die in `AGENTS.md` dokumentierte Gitea-Ausnahme verlaesst den Cluster
+kuenftig gar nicht mehr.
+
+⚠️ Der Preis steht im Entwurf: Ein interner Zeiger macht aus zwei Wegen
+einen. Faellt `10.0.0.3` aus, ist rohana aus dem Cluster nicht erreichbar,
+obwohl der oeffentliche Weg ginge — und der Fehler saehe aus wie „Gitea ist
+weg".
+
 ⚠️ **Ich habe mir die Falle aus meinem eigenen Abnahmekriterium gestellt.**
 Kriterium 4 verlangt ausdruecklich ein Werkzeug, das im Container
 existiert — und die erste Gegenprobe in `element-admin` lief mit