admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b52d6aa49e56ab2fa3ee9c638f4ae7e2b639c254
bf-infra/docs/ip-plan.md
Christoph Emsenhuber b52d6aa49e TP45 Schicht A: Nautobot .30/.31/.32/.34 -> .154/.155/.156/.158 
Oktett-Klasse .150-.199 (App-Services). Nautobot gibt damit .30/.31 an
AGH frei. .157 ist gitea, deshalb nimmt redis .158.

- Datenmigration ueber neues nautobot/tp45-ip-move.py: Nautobot verbietet
  das Aendern einer IP nach dem Anlegen -> anlegen/primary_ip4 umhaengen/
  Altobjekt loeschen, in dieser Reihenfolge
- Stack-Redeploy (PUT /api/stacks/203), Caddy-Backend, Core-Literal *24
  ueber GC deployt (Plan 51a90e25) mit Wirksamkeitspruefung am Geraet
- caddy/deploy.sh: push_verified() ersetzt den push||push-Fallback.
  `pct push` meldet Exit 0 AUCH wenn es die Quelle nicht lesen kann, der
  Fallback griff deshalb nie und `caddy validate` pruefte die ALTE Datei
  -> gruene Abnahme bei unveraendertem Zustand (Symptom: 502 bei
  gesundem Backend)
- 39 Referenzen in 28 Dateien mitgezogen; lebende Doku nachgezogen
  (CLAUDE.md, ip-plan.md, cf-tunnel-mapping §0-Kopf, TP16.3/TP31-Prosa)
- GC-Compliance 140/140, 0 Drifts

Neue Funde (TP45-Prosa + CLAUDE.md):
- Die Core-Adressliste `nautobot` wird von GC nirgends gerendert -> ein
  Recovery von null erzeugt einen Core, in den Nautobot nicht mehr per
  SSH kommt. Gleiche Klasse wie die fehlenden DHCP-Reservierungen.
- Regel *24 (Literal) und *28 (Liste) sind Dubletten; der Literal steht
  bei 0 Paketen. Zusammenlegung bleibt offen.
- gc-manual-plan.py: /api/extras/job-log-entries/ liefert 404 (Nautobot
  3.x) -> bei gescheitertem Deploy fehlt die Fehlermeldung.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-09-21 13:14:35 +02:00

102 lines
8.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# AP — IP-Plan BF (per-Gerät, Ziel-VLAN-Subnetze)
> **Eigenständiges Arbeitspaket.** Hier definieren wir die **finalen statischen IPs** je Gerät in den
> Ziel-VLANs. Voraussetzung (✅ erfüllt 2026-06-16): Routing VLAN1 ↔ übrige VLANs steht (statische Route
> auf der FB → `10.40.41.1`), ap1-NAT nimmt LAN-internes aus (`srcnat accept 10.40.0.0/16`).
> Erst **bestätigte** Zeilen werden migriert. Status: ~~🟡 Entwurf — Vorschläge zum Festklopfen.~~
---
## ✅ Migration abgeschlossen (Stand 2026-08-19) — dieses Dokument ist Historie
> **Lies zuerst das hier, nicht die Tabelle.** Der Plan ist umgesetzt; die Tabelle unten ist das
> *Arbeitsblatt von damals* und bleibt bewusst erhalten (Konvention: fortschreiben, nicht überschreiben).
> Mehrere ihrer Zeilen beschreiben eine Topologie, die es **seit 2026-08-08 nicht mehr gibt** —
> insbesondere „ap1 = Router/GW" und `sw1` als lebendes Gerät.
>
> **Kanonischer Ist-Stand: `docs/teilprojekte.md` (Ist-Stand-Block) und `CLAUDE.md`.**
**Wie es heute wirklich aussieht:**
| Rolle | Gerät | Adresse |
|---|---|---|
| L3-Router + WAN-Edge + DHCP/DNS/NTP/WG-Hub | **`crs326-core`** | GW **`.1` je VLAN**, Mgmt-SVI `10.40.99.1`, WAN `vlan100` |
| L2-Switch Technik OG | **`crs326-branch`** | `10.40.99.2` |
| AP (reiner CAP unter CAPsMAN) | **ap1** | `10.40.99.11` |
| AP (reiner CAP unter CAPsMAN) | **ap2** | `10.40.99.12` |
| ~~ALLNET sw1~~ | — | ❌ ausgebaut 2026-08-08 |
| ~~Omada sw2~~ | — | ❌ ausgebaut 2026-07-23 |
| ~~FritzBox 6660~~ | — | ❌ ausgebaut 2026-07-01 (Arris im Bridge-Mode) |
**Was daraus für die Tabelle folgt:** die Zeilen `ap1` / `ap2` / `sw1` / `crs326-*` stehen unten noch mit
den *damals geplanten* Werten und ⬜-Status. Sie sind erledigt bzw. gegenstandslos — die Marker sind
2026-08-19 nachgezogen, die ursprüngliche Planung bleibt darunter lesbar.
**Ebenfalls überholt:** die Konventionszeile „GW je VLAN = `.1` (**ap1**)" und der Arbeitsschritt
„(3) DNS `bf.lan`-Eintrag **auf ap1** updaten" — beides ist seit dem Core-Cutover Sache von
`crs326-core`. **VLAN1 existiert seit TP19 (2026-08-18) gar nicht mehr** als Client-Netz, die Spalte
„aktuell (VLAN1)" ist damit reine Herkunftsangabe.
---
## Konventionen
- **Host-Oktett möglichst beibehalten** (weniger Churn in DNS/Configs): z.B. NAS `.10` → `10.40.20.10`.
- GW je VLAN = `.1` (~~ap1~~ **`crs326-core`**, seit 2026-08-08). Pools `.100–.200` = DHCP → statische Geräte **außerhalb** des Pools (`.2–.99`).
- Zuordnung: **VLAN20 INFRA** = NAS/VMs/Docker/HA/Services **+ Hypervisor** (User-Entscheid 2026-06-16:
pve/DS923 sind Infra *und* Hypervisor → INFRA) · **VLAN99 MGMT** = nur Netz-Gear-Mgmt (Switch/AP) ·
**VLAN10 MAIN** = trusted Clients · **VLAN40 MEDIA** = Sonos/AppleTV/TV.
- Pro migriertem Gerät: (1) IP am Gerät selbst umstellen, (2) DHCP-Reservierung/Static pflegen,
(3) DNS `bf.lan`-Eintrag auf ~~ap1~~ **`crs326-core`** updaten, (4) Reachability prüfen.
## Geräte-Tabelle (Vorschlag → bestätigen)
| Gerät | aktuell (VLAN1) | Rolle | Ziel-VLAN | **Vorschlag IP** | bestätigt | Notizen |
|---|---|---|---|---|---|---|
| ap1 (hAP ax²) | 10.40.41.1 | ~~Router/GW~~ → **reiner AP (CAP)** | 99 MGMT | ~~bleibt `.1` je VLAN; Mgmt `10.40.99.1`~~ → **`10.40.99.11`** | ✅ **erledigt, anders als geplant** | ⚠️ **Rolle seit 2026-08-08 auf `crs326-core`** (TP21.1) — kein DHCP/DNS/NAT/WG mehr. Seit TP28 (08-17) reiner CAP unter dem Manager auf dem Core |
| ap2 (hAP ax²) | 10.40.41.2 | AP (CAP) | 99 MGMT | ~~`10.40.99.2`~~ → **`10.40.99.12`** | ✅ **live** | TP19.1 2026-08-14 (Mgmt-Cutover); `.99.2` ging an `crs326-branch`. Uplink an branch `ether24` |
| ~~sw1 ALLNET (Core)~~ | 10.40.41.11 | — | — | — | ❌ **ausgebaut** | 2026-08-08 durch `crs326-core` ersetzt, physisch entfernt. Die hier geplante `.99.11` ging an **ap1**. Telnet-Runner unter `switch/` = Archiv |
| ~~sw2 Omada (ES208G)~~ | — | — | — | — | ❌ **abgebaut** | TP15 2026-07-23: physisch entfernt, durch crs326-branch ersetzt (Technik OG) |
| **crs326-branch** (CRS326) | 192.168.88.1 (Werk) | L2-Switch (Technik OG) | 99 MGMT | ~~`10.40.99.13` (Ziel `.99.12`)~~ → **`10.40.99.2`** | ✅ **live** | TP15 2026-07-23: ersetzt sw2. ⚠️ **Anders gekommen als geplant.** Uplink `ether1` → **`crs326-core ether8`** (nicht mehr sw1). Bring-up-Reste `.41.213` + SVI vlan10 entfernt 08-16 |
| **crs326-core** (CRS326) | 192.168.88.1 (Werk) | **L3-Router + WAN-Edge** (Technik UG) | 99 MGMT + GW je VLAN | ~~`10.40.99.11`~~ → **`10.40.99.1`** + **`.1` in jedem VLAN** | ✅ **produktiv** | TP21.1 2026-08-08: Cutover vollzogen, ersetzt ap1 als L3. Routing/DHCP (7 Server)/DNS (DoH)/NAT/NTP/WG-Hub. WAN `vlan100` = Liwest `90.146.33.177`. VLAN1-Temp `.41.211` entfernt |
| NAS nas-bf (DS923) | ~~10.40.41.10~~ | INFRA | 20 INFRA | `10.40.20.10` | ✅ **live** | TP14.1 2026-07-10; DNS `nas.bf.lan` nachgezogen 2026-07-16 |
| ~~Omada-Controller~~ | — | Service (macvlan/DS923) | — | — | ❌ **entfernt** | User hat den Container 2026-07-16 gelöscht (overkill für 1 Switch auf der Abschussliste, s. TP2.1/TP15). DNS-Eintrag `omada.bf.lan` entfernt |
| ~~omada-mcp~~ | — | Service (pve-LXC) | — | — | ❌ **entfernt** | mit dem Controller zusammen gelöscht 2026-07-16 (MCP-Server verwaist, in Claude-Settings noch registriert — Aufräumen offen). DNS-Eintrag `omada-mcp.bf.lan` entfernt |
| pve-mcp | 10.40.20.173 | Service (pve) | 20 INFRA | `10.40.20.173` | ✅ **live** | TP14.1; NAS-Stack (vlan20-only) |
| Docker-LXC | 10.40.20.126 | Docker-Host (pve) | 20 INFRA | `10.40.20.126` | ✅ **live** | TP14.2 2026-07-10: LXC 400 net0 tag=20; Docker `vlan20`=ipvlan parent `veth20` |
| Proxmox pve | 10.40.20.100 | Hypervisor+INFRA | 20 INFRA | `10.40.20.100` | ✅ **live** | TP14 2026-07-13: vmbr0.20 Host-IP + Default-GW-Flip, SSH-Key ✓, ap1-DNS+CF-Ingress(bf-pve) nachgezogen; `.41.100` bleibt interim ohne Route (wie sw1/sw2/ap2-Mgmt) |
| Mac mini | ~~10.40.41.167~~ | INFRA/Server | 20 INFRA | `10.40.20.167` | ✅ **live** | umgezogen. ⚠️ Die alte `.41.167` geisterte bis 2026-08-16 in `CLAUDE.md` — dort korrigiert. Portangabe „Omada P7" ist Historie (sw2 ausgebaut) |
| ~~FritzBox 6660~~ | — | WAN/Transfer | — | — | ❌ **physisch entfernt** | Liwest-Kabelmodemtausch 2026-07-01 (Edge-Cutover), kein Zurück — Arris-Kabelmodem im Bridge-Mode ersetzt sie komplett |
| platform-pg (LXC 105, pve) | — (neu) | Platform-Postgres (TP20), PG16, DB `nautobot` | 20 INFRA | `10.40.20.20` | ✅ **live** | TP20 2026-07-16: erstellt via `pct create`, Ubuntu 24.04 (native PG16, kein PGDG-Repo nötig), UTF8/en_US.UTF-8, `wal_level=replica`, `archive_mode` bewusst noch aus (s. Memory) bis pgBackRest/Garage-S3 da ist; Creds `postgres/.secrets` |
| nautobot (Portainer-Stack, NAS) | — (neu) | Nautobot Golden Config (TP21), App/API | 20 INFRA | `10.40.20.154` | ✅ **live** | TP21 2026-07-16: `ghcr.io/nautobot/nautobot:3.1.7`, ep14 Stack Id 203, DB=platform-pg; Begleitcontainer `nautobot-worker`.20.155, `nautobot-scheduler`.20.156, `nautobot-redis`.20.158. **TP45 Schicht A 2026-09-21:** Oktett-Klasse `.150–.199` (App-Services) — die alten `.30–.34` gibt Nautobot an AGH `.30`/`.31` frei |
> Weitere Geräte (Home Assistant, HA-IoT, Drucker-Reservierung, etc.) hier ergänzen, sobald relevant.
## Migrations-Reihenfolge & Risiko
### Phase 1 — INFRA, sofort möglich (✅ Mac mini schon live)
1. **Proxmox pve** → `10.40.20.100` (Hypervisor, kein Lockout-Risiko, Management per SSH/Web).
2. **Docker-LXC** → `10.40.20.126` (Portainer-Host auf pve, folgt pve).
3. **pve-mcp** → `10.40.20.173` (pve-LXC, folgt pve; MCP-URL in `~/.claude/settings.json` updaten).
4. **omada-mcp** → `10.40.20.176` (pve-LXC, folgt pve; MCP-URL in `~/.claude/settings.json` updaten).
### Phase 2 — MGMT-Plane, Lockout-Risiko (nach Phase 1, VLANs verifiziert)
5. **ap2** → `10.40.99.2` (hAP #2 Mgmt-IP; VLAN99 muss am Port sitzen, in einem Schritt).
6. **sw2 Omada (ES208G)** → `10.40.99.12` (Controller-Config + Port-VLAN in einem Schritt).
7. **sw1 ALLNET** → `10.40.99.11` (Telnet-CLI, risikoreichstes Gerät — zuletzt in dieser Phase).
### Phase 3 — Geblockt auf CF Zero Trust + TP10
8. **NAS nas-bf (DS923)** → `10.40.20.10`
- Voraussetzung 1: CF Zero Trust auf neue Ziel-Struktur (VLAN20-Subnetze, neue IPs) angepasst.
- Voraussetzung 2: TP10 abgeschlossen (VPN-Tunnel 2× WG auf ap1; FB kann Bridge-Mode gehen).
9. **Omada-Controller** → `10.40.20.175` (macvlan auf DS923 → folgt automatisch mit NAS; kurz Mgmt-Downtime).
### Phase 4 — nach TP10
10. **FritzBox 6660** → Bridge-Mode (wird zum reinen Modem; IP `10.40.41.254` entfällt als GW).
## Abhängigkeiten
- ✅ VLAN1↔VLANx-Routing (FB-Route) · ✅ ap1-NAT-Ausnahme (inter-VLAN ohne SNAT).
- Speist den **Rest des Omada-PVID-Fix** (P7 macmini→INFRA, P8 NAS→INFRA, P4 nach Klärung) sowie die
DNS-`bf.lan`-Aktualisierung in [project_tp4_router]-Memory.
- **NAS + Controller: geblockt auf CF Zero Trust + TP10** (User-Entscheid 2026-06-16).
Reference in New Issue View Git Blame Copy Permalink