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 <noreply@anthropic.com>

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