From 180c5b6c575c485a315c291dee8ab86aa7458b06 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 21 Sep 2026 21:29:38 +0200 Subject: [PATCH] TP45 Schicht E: Umzug laeuft ueber den Core, nicht ueber Doppeladresse am Host Neue IPs .110/.121/.130 werden zuerst am Core generiert (Sekundaer-IP auf vlan20 + 1:1-NAT aufs Geraet), gemessen wird ab Tag 1 mit zwei Zaehlern (neue IP = wer ist umgestellt, Alt-IP = ist noch was los). Das Geraet wird erst angefasst, wenn seine Alt-IP still ist ("siedeln"). Alles ins Soll, nicht als Transaktion. NAS siedelt zuletzt und gemeinsam. Warum NAT statt Routing: im selben Subnetz antwortet das Geraet dem Client direkt per L2 -- er verwirft die Antwort von .10 auf eine Verbindung zu .110. Vorabcheck: NAS-NFS/iSCSI sind IP-ACL'd, aber ohne lebende Nutzer (pve hat null NAS-Mounts) -- der src-nat-Umweg bricht nichts. Nebenbefund: die Exports stehen auf totem 10.40.41.x plus drei 10.0.0.0/8-Freigaben. Co-Authored-By: Claude Sonnet 4.6 --- docs/teilprojekte.md | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index a6e4153..1f83b64 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -2744,9 +2744,39 @@ unter `*1A TP5-WOULD-DROP` / `*2D TP5: deny-by-default` (621 Pakete). | **B** | VLAN30 — **nur die Pool-Grenze**, Geräte bleiben (Christoph 2026-09-21) | offen | | **C** | DNS/FQDN: `ds-bf` über Caddy, `coolify.bf` neu, `.bf` vollständig auf den Core, AGH nur Filtering, TP34 | offen | | **D** | Tunnel-Inventar + GC + generische Namen, TP30 #10, Leak-Ursachen | offen | -| **E** | nas/pve/macmini mit Doppeladresse — **eigene Session**, pve2 nur reservieren | offen | +| **E** | nas/pve/macmini — **neue IPs zuerst am Core** (Sekundär-IP + 1:1-NAT), dann messen und umstellen; nas zuletzt | offen | | **F** | CF-/Tunnel-SSoT + Recovery → **TP46** | offen | +##### Schicht E — Mechanik (Christoph-Entscheid 2026-09-21, ersetzt „Doppeladresse am Host zuerst") + +**Neue IPs zuerst am Core, nicht am Gerät:** Sekundär-IPs `.110` (nas) · `.121` (pve) · `.130` +(macmini) auf der Core-`vlan20` **plus 1:1-NAT** auf das Gerät (`dst-nat` + `src-nat`, platziert +**vor** der `no-NAT inter-VLAN`-Regel). 🔴 **Routing allein reicht nicht** — im selben Subnetz +antwortet das Gerät dem Client direkt per L2, der Client verwirft eine Antwort von `.10` auf eine +Verbindung zu `.110`; der Rückweg braucht `src-nat`, und die Adresse muss **am Core liegen**, sonst +beantwortet er kein ARP dafür (**nicht** `proxy-arp` — das antwortet für *jede* freie Adresse im +/24). Heute ist die Core-NAT-Kette leer (nur `no-NAT inter-VLAN` + WAN-Masquerade) ⇒ Neubau. + +**Ab dann gemessen:** zwei Zähler je Host — auf der **neuen** IP (NAT-Regel: „wer ist schon +umgestellt") und auf der **Alt-IP** (`action=passthrough`, `comment="dualaddr-watch: …"`: „ist noch +was los"), beide ohne `log`. **Erst wenn der Alt-IP-Zähler über N Tage stillsteht**, wird das Gerät +**zum Siedeln vorgemerkt**: neue IP aufs Gerät → NAT + Sekundär-IP + Zähler raus → Alt-IP entfernen +→ Doku/Nautobot nachziehen. Alles **ins Soll**, nicht als Transaktion (Christoph: *„wir haben einen +Ist- und einen Sollzustand; die Regel kann uns nicht vorschreiben, wie lange wir für die Überführung +brauchen"*). + +**Reihenfolge:** `nas` siedelt **zuletzt und gemeinsam** (die meisten Abhängigkeiten: SMB, Time +Machine, Caddy-Backend `ds-bf`), `pve`/`macmini` vorher; **`pve2` nur reservieren** (`.120`). + +**Vorabcheck ✅ 2026-09-21:** NAS-NFS (`/etc/exports`, 9 Shares) und iSCSI (`.10`/`.11`:3260) sind +IP-ACL'd, haben aber **keine lebenden Nutzer** — pve hat **null** NAS-Mounts (einzige Remote-Storage +ist `pbs 10.40.20.135`), kein LXC hängt am NAS, die Synology-Firewall hat keine Regeln ⇒ der +src-nat-Umweg (gleich-subnetzige Clients sehen den Core als Quelle) **bricht nichts**. +🔴 **Eigener Aufräumposten:** dieselben Exports stehen komplett auf totem **`10.40.41.x`** plus drei +`10.0.0.0/8`-Freigaben (offen für jeden 10/8-Client). +⚠️ Der NAS trägt **zwei** VLAN20-Adressen (`.10` `ovs_eth0`, `.11` `ovs_eth1`) — laut Christoph +haben die beiden nichts miteinander zu tun; `.11` gehört **nicht** in die Umzugslogik. + 🔴 **Warum Nautobot zuerst.** AGH will `.30`/`.31` — dort saß Nautobot (`.30`/`.31`/`.32`/`.34`). **28 Skript-/Config-Dateien** referenzierten `10.40.20.30` (alle `gc-*.py`, 14× `ingest-*.py`, `tp44-*`, `routeros/fetch-core-cutover-config.py`) — alle am 2026-09-21 mitgezogen. Und: **der