bf-infra/docs/tp23-stufe6-bypass-sperre-runbook.md

TP23 Stufe 6 — DNS-Bypass-Sperre (Runbook für eine SEPARATE, VOR-ORT-Session)

🔴🔴 HARTES GATE: NUR VOR ORT ausführen. NICHT aus der Ferne, nicht während Christoph abwesend ist. (Notiert 2026-09-06: Christoph ist ~1 Woche nicht vor Ort → in diesem Fenster gar nicht anfangen, auch nicht die log-only-Vorstufe scharf lassen.)

Grund: Die Sperre macht das AGH-Paar .36/.37 zum harten DNS-SPOF. Bis heute kann jeder Client bei einem AGH-Ausfall auf einen externen Resolver ausweichen; nach der Sperre nicht mehr — ein AGH-Ausfall = hausweiter DNS-Ausfall (betrifft die Familie), und ohne physischen Zugriff gibt es keinen schnellen Rollback. Eine falsch platzierte Drop-Regel kann außerdem den Fernzugang selbst (WG/cf-mesh) aussperren, mit dem man den Fehler zurücknehmen wollte.

Ziel

Clients dürfen plain DNS (udp/tcp 53) und DoT (853) nur noch zu den erlaubten Resolvern (10.40.20.36, 10.40.20.37, Core 10.40.X.1) schicken. Externe DNS-Server (Smart-TV mit 8.8.8.8 hartkodiert, App-eigene Resolver) werden geblockt → kein Umgehen des Filters. Das ist der letzte Baustein von TP23 und lebt in der TP5-Firewall (forward-Kette).

Voraussetzungen

Erfüllt (Stand 2026-09-06):

• Self-Service-Oberfläche steht und ist getestet (HA-Dashboard dns-ausnahmen, Stufe 5) → ein geblockter Dienst kann ohne Admin temporär freigegeben werden. Das war die harte Reihenfolge-Regel („erst der Ersatz, dann die Sperre").
• dns-bypass-exempt-Gruppe existiert auf dem Resolver-Paar (AGH-Client-Seite).

Noch zu bauen (Teil dieser Session, VOR dem Drop):

• Firewall-Exempt ist noch NICHT da: eine Address-List dns-bypass-exempt (permanent) mit dem dev-MacBook (10.40.10.183 und 10.40.10.82, dual-homed) + Agent-Toolchain, plus eine accept-Regel vor dem Drop. Ohne die verliert der Entwicklungsrechner seinen Ausweg.
• Ad-hoc-JIT: Address-List jit-dns-bypass mit timeout nach dem Muster jit-admin (routeros/tp5-etappe4-input-mgmt.rsc) — selbstverfallende Freigabe.

Bekannte Grenze (offen benennen, nicht „lösen")

Die Sperre greift auf Port (53/853). DoH läuft über 443 und ist damit portgleich zu HTTPS — ein Gerät, das DoH gegen 8.8.8.8:443 fährt, umgeht die Sperre. Das per SNI/IP zu schließen ist ein eigenes, größeres Thema (nicht Teil von TP23). Für den Alltag (TVs/IoT mit Plain-DNS) reicht die Port-Sperre.

Sichere Methodik — log-only zuerst, Drop zuletzt

1. Exempt + JIT bauen (via Nautobot GC, ip-firewall-filter steht unter Drift-Kontrolle → kein Direkt-Write): accept für dns-bypass-exempt/jit-dns-bypass → 53/853, platziert vor der künftigen Drop-Regel. Erst hier abnehmen, dass die Exempts wirklich durchkommen.
2. Log-only-Vorstufe: eine Regel TP5-WOULD-DROP-DNS, die LAN→extern auf dst-port 53,853 (udp+tcp), nicht zu .36/.37/Core, nur loggt (in den Kollektor 10.40.20.18:514, wie die bestehende TP5-WOULD-DROP). Mehrere Tage laufen lassen und den Drop-Log lesen: welche Geräte reden mit welchen externen Resolvern? Jedes davon ist ein Kandidat, der nach dem Drop bricht — vorab entscheiden (Reservierung auf AGH, Exempt, oder bewusst brechen lassen). 🔑 Merkregel aus dem E5-Drop-Log: Geräte fallen oft mit udp/161/andere nebenbei auf — nur die 53/853-Zeilen zählen hier.
3. Erst nach ruhigem/verstandenem Log: die Log-only-Regel auf action=drop (oder reject mit icmp-port-unreachable, damit Clients schneller auf den nächsten Resolver fallen) heben — mit Auto-Revert-Absicherung (Scheduler/Netwatch, der die Regel nach X Minuten deaktiviert, falls nicht bestätigt), analog zum TP5-E3/E4-Vorgehen. Vor Ort, mit offener Konsole.

Was NICHT gesperrt werden darf (sonst Selbst-Aussperrung)

• .36/.37 → CF-DoH-Upstream (443) und Core-Resolver-Egress: die Resolver müssen raus.
• Core 10.40.X.1 DoH-Egress.
• cf-mesh / WG-Pfad (Fernzugang) — die Drop-Regel matcht nur dst-port 53,853; trotzdem vor dem Scharfschalten gegenprüfen, dass Management-Input (cf-mesh, HA 8728, Nautobot 22) unberührt bleibt.

Rollback

• GC-Deploy der vorherigen Version (Regel zurück auf disabled/entfernt) — bzw. der Auto-Revert.
• Fällt das AGH-Paar bei aktiver Sperre aus: Drop-Regel deaktivieren (Vor-Ort-Konsole) → Clients können sofort wieder externe Resolver nutzen.

Abnahme

• Exempt-Host (dev-MacBook) löst extern weiter auf; ein Test-Gerät mit hartkodiertem 8.8.8.8 löst nicht mehr (aber über AGH schon).
• Self-Service: eine geblockte Domain per HA-Button freigeben → wirkt; nach Ablauf wieder gefiltert.
• Compliance nach dem GC-Deploy grün (python3 nautobot/gc-transaktion.py status, GC 140/140).

Verweise

• Stufe 4/5 (fertig): adguard/README.md, adguard/ha-self-service.md, adguard/agh-exception.py.
• JIT-/Firewall-Muster: routeros/tp5-etappe4-input-mgmt.rsc; GC-Pipeline: nautobot/gc-configplan.py.
• Kontext/Reihenfolge-Regel: TP23-Abschnitt in docs/teilprojekte.md.