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).

**Entwurf liegt bereit (freigegeben 2026-09-11, NOCH NICHT deployt — Christoph war remote):**
- Phase A (Substrat + Exempt/JIT-Accepts + log-only): `routeros/tp23-stufe6-phaseA-exempt-log.rsc`
- Phase B (reject + Auto-Revert): `routeros/tp23-stufe6-phaseB-reject.rsc`
- 🔴 **Vor dem Deploy live verifizieren** (im Dateikopf markiert): (1) der Egress-Accept-Anker in
  der forward-Kette, vor dem die Regeln stehen müssen; (2) die Exempt-IPs des dev-MacBooks.

**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`.