admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

TP10 ✅ Kern durch: beide WG live auf ap1-Hub, FB-Bridge entblockt

Browse Source 
DW/Geli on-site abgeschlossen (2026-06-27): Geli auf 10.95.10.0/24
renumbert, FB-WG single 10.95.10.1/24, alter FB↔FB-WG geswappt.
End-to-End verifiziert (macmini/Linz → Gelis 24/7-APs .246/.247,
echte LAN-IPs, kein 10.255.255.x-NAT-Leak). FM+DW live im Double-NAT.

Doku/Status von "🅿️ vertagt/geparkt" auf Ist-Stand gezogen, Bridge-Gate
an allen Stellen aufgelöst, stale 192.168.178-Referenzen bereinigt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Christoph Emsenhuber
2026-06-27 16:44:15 +02:00
parent 48754f446d
commit 1f8e6b06c2
4 changed files with 41 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/teilprojekte.md
View File

@@ -21,7 +21,7 @@ IP-Blöcke: `.1–10` Router/APs (ap1=.1, ap2=.2) · `.11–20` Switches (ALLNET
ALLNET-Core `.11` (FW2.2.1, VLANs 10/20/30/40/50/90/99/100; GE1/GE2/GE8 Trunk; **TP1 ✅ 2026-06-15**). Omada-Switch `.12` (adopted, **TP2 ✅ 2026-06-15**; Trunk-ALL auf P1+P2, Access-Profile auf P3-P8; Profile noch PVID=1 bis Omada-PVID-Fix).
Omada-Controller **`.175`** (DS923/macvlan, mbentley 6.2, 🟢 live). omada-mcp **`.176`** (pve-LXC, StreamableHTTP, 🟢 live, 84 read-Tools; Controller-API v2 intern via christoph@emsenhuber.com).
2× hAP ax² (7.23.1): ap1 `.1` (ALLNET P1) — **TP4 ✅ 2026-06-15: L3-Router aktiv** (VLAN-Subinterfaces, DHCP, DNS, NAT). ap2 `.2` (Omada P2 — Trunk). FB6660 = Double-NAT-Upstream bis FB-Bridge-Mode.
**AP4.1 (FB-Bridge, 2026-06-16):** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live auf ap1 (`routeros/wan-cutover-*.rsc` + Runbook; scheduler-frei, Disk-Log `wan-test.0.txt`). ⚠️ **FB-Bridge bleibt vorerst nur TEST (reversibel)** — die FB hält 2 produktive VPN-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WG) → **permanenter Bridge-Mode gegated auf TP10** (VPN-Migration auf 2× WG/ap1).
**AP4.1 (FB-Bridge, 2026-06-16):** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live auf ap1 (`routeros/wan-cutover-*.rsc` + Runbook; scheduler-frei, Disk-Log `wan-test.0.txt`). ✅ **Bridge-Gate aufgelöst (2026-06-27):** TP10-Kern durch (beide VPN von der FB auf ap1-WG migriert) → die FB terminiert keine Tunnel mehr → **permanenter Bridge-Mode ist jetzt entblockt** (offen = WAN-Seal + Liwest-Anruf).
Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Controller + omada-mcp 🟢.
**Nächster Schritt: Omada-PVID-Fix** (MAIN→PVID10, INFRA→PVID20, untagNetworkIds bereinigen) + IP-Migration Geräte.
> ⚠️ **HW-Constraint hAP ax²:** 1 GB RAM, aber nur **128 MB Flash + KEIN USB** → **Container auf dem Router NICHT praktikabel**.
@@ -99,7 +99,7 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
- ⚠️ Auto-Suffix `.lan` (RouterOS-Einschränkung, kann nicht auf leer gesetzt werden) — TP5-Cleanup.
- ✅ **NAT:** srcnat masquerade out-interface=bridge (ap1 → FB → Internet, Double-NAT Interim-Lösung).
- ✅ **Routing-Tabelle:** 0.0.0.0/0 via 10.40.41.254%bridge; alle 7 VLAN-Subnetze als Connected-Routes aktiv.
- ⏳ **FB-Bridge-Mode (AP4.1)** — ether1 als WAN ist vorkonfiguriert (DHCP-Client, NAT out=ether1, Fallback-Route bridge distance=2). **Test 2026-06-16:** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live (`routeros/wan-cutover-test.rsc`/`-macclone-test.rsc` + `wan-cutover-runbook.md`; scheduler-frei wg. device-mode, Disk-Log `wan-test.0.txt`). User-Befund „nach Gateway .1 ging nichts mehr" → Root-Cause offen (Hypothese DoH-Bootstrap). ⚠️ **Bridge bleibt nur TEST/reversibel; permanenter Umstieg gegated auf TP10** (FB hält bis dahin 2 VPN-Tunnel + Telefon). Bis dahin: Double-NAT via bridge (funktioniert).
- ⏳ **FB-Bridge-Mode (AP4.1) — jetzt entblockt (TP10-Kern durch 2026-06-27)** — ether1 als WAN ist vorkonfiguriert (DHCP-Client, NAT out=ether1, Fallback-Route bridge distance=2). **Test 2026-06-16:** Public-IP `86.56.201.104` per ether1 bewiesen (kein Liwest-MAC-Lock). Offline-Testmechanismus live (`routeros/wan-cutover-test.rsc`/`-macclone-test.rsc` + `wan-cutover-runbook.md`; scheduler-frei wg. device-mode, Disk-Log `wan-test.0.txt`). User-Befund „nach Gateway .1 ging nichts mehr" → Root-Cause offen (Hypothese DoH-Bootstrap). ✅ **VPN-Gate weg** (beide Tunnel auf ap1-WG migriert); offen = WAN-Input-Seal (Block C aus `tp10-cutover-apply.rsc`) + **Liwest-Anruf** → ether1 = Public Edge, Double-NAT weg. Telefon bleibt an der FB. Bis dahin: Double-NAT via bridge (funktioniert).
- **DNS-Entscheidung** (Technitium **und** externer BIND verworfen): RouterOS-DNS als Resolver, keine DHCP→DNS-Auto-Registrierung (soweit möglich). Infra-Hosts als statische `/ip dns static`-Einträge unter `bf.lan`; dynamische Clients bewusst ohne Namen. Filtering/DNSSEC via DoH-Upstream (TP3). HA: 2. Resolver auf ap2, statische Einträge beidseitig pflegen.
- Abh.: TP1 ✅. TP3-Abhängigkeit entfällt (WLAN läuft weiterhin über FB bis TP3).
- **Ermöglicht jetzt:** PVID-Fix in Omada-Profilen (MAIN→PVID10, INFRA→PVID20), untagNetworkIds-Bereinigung, DHCP-Reservierungen für NAS/macmini/pve auf neue VLAN-Subnetze migrieren.
@@ -136,18 +136,21 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
**Empfehlung:** VRRP nur für **MAIN/INFRA**, sonst ap2 als **Kalt-Ersatz** + Backup. DHCP/DNS schon redundant (Split + 2 Resolver).
- Abh.: TP4. (Research erledigt, s. TP-R + Config-Skizze im Report.)
### TP10 — Multi-Site VPN ▸ 🅿️ VERTAGT — gebündelt mit Bridge-Cutover (`docs/tp10-vpn-migration.md`)
### TP10 — Multi-Site VPN ▸ ✅ KERN DURCH (2026-06-27) — beide WG live auf ap1-Hub (`docs/tp10-vpn-migration.md`)
> **Details/Cutover/Gotchas/Eckdaten → `docs/tp10-vpn-migration.md` (Single Source of Truth).** Research: `docs/research/vpn-comparison.md`.
- **🅿️ VERTAGT, gebündelt mit Bridge-Cutover (2026-06-17):** VPN-auf-FB ⊕ FB-Bridge schließen sich aus → Migration am
Bridge-Tag (dann ap1 = Edge mit Public-IP, **kein Port-Forward-Umweg**). Beide VPN vorerst über die FB: **FM=IPsec, DW=FB-WG**.
- **✅ KERN DURCH (2026-06-27):** beide AVM-Tunnel → **2× WireGuard mit Hub auf ap1** migriert. Live: `peer fm`
(`10.101.0.0/24`, bidirektional, myfritz-Endpoint) **und** `peer dw` (`10.95.10.0/24`, CGNAT-Dial-in) mit frischem
Handshake + Traffic. Noch im **Double-NAT** über die BF-FB-Portfreigabe (51821 → ap1). FM-IPsec gekillt, Gelis
alter FB↔FB-WG sauber geswappt. **→ entblockt den permanenten FB-Bridge-Mode.**
- **✅ DW/Geli on-site verifiziert (2026-06-27):** Geli auf `10.95.10.0/24` renumbert, FB-WG single `10.95.10.1/24`,
Keepalive 25, Endpoint `bf4…:51821`. End-to-End von macmini/Linz → Gelis 24/7-APs `10.95.10.246/.247` sauber
(echte LAN-IPs, **kein `10.255.255.x`**-NAT-Leak).
- **💡 Root Cause (FM-PoC bewiesen):** FB masqueradet WG, wenn die Interface-`Address` eine **Transfernetz-IP** ist →
muss die **FB-LAN-IP** sein (AVM Proxy-ARP). Damit ist der WG-Spoke-Ansatz machbar.
- **Stand:** Hub `wg-hub` (UDP 51821, Key `P/bzt…`, MTU 1412) auf ap1 **geparkt** (Peers disabled, Routen entfernt,
Firewall = TP5-Vorarbeit bleibt). Endpoint = DDNS **`bf4.emsenhuber.net:51821`** (Cloudflare, DNS-only → 86.56.201.104).
**DW-Config bei Geli vor Ort gestaged** (2026-06-17; dual-range `192.168.178.0/24` + künftig `10.95.10.0/24`).
v6-direkt-Variante (Gelis natives v6) als spätere Option vermerkt.
- **Offen:** ap1-Seite aktivieren (peer2 + Routen für beide DW-Ranges), sobald BF erreichbar.
- ⚠️ **Blockiert** den permanenten FB-Bridge-Mode (AP4.1/TP4) bis zur Migration.
muss die **FB-LAN-IP** sein (AVM Proxy-ARP). War der Schlüssel zum sauberen LAN-LAN.
- **Hub:** `wg-hub` (UDP 51821, Key `P/bzt…`, MTU 1412, keine IF-IP). Endpoint = DDNS **`bf4.emsenhuber.net:51821`**
(Cloudflare, DNS-only → 86.56.201.104, überlebt Bridge). Apply gebündelt in `routeros/tp10-cutover-apply.rsc`.
- **Offen (entblockt):** permanenter FB-Bridge-Cutover (WAN-Seal Block C + **Liwest-Anruf** → ether1 = Public Edge,
Double-NAT weg); BF-FB-eigenen WG-Server 51820 abräumen; DDNS-Auto-Updater für `bf4` auf NAS/pve.
### TP11 — Monitoring & Mgmt-Control-Plane ▸ research-gated
- MikroMCP + omada-mcp + **SNMP/icinga-mikrotik**, RoMON, NTP, **E-Mail-Alerts**, Netwatch. → Teil von `docs/research/routeros-capabilities.md`.
@@ -175,4 +178,5 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
4. **Dann:** TP5 (Firewall/Deny-by-default) → TP6 (QoS/CAKE). ~~TP7 (mDNS)~~ ✅ 2026-06-17, ~~TP3 (WLAN/CAPsMAN)~~ ✅ 2026-06-18.
⚠️ TP5 muss die TP7-Firewall-Holes mitnehmen (s. TP7: MAIN↔MEDIA-forward + UDP 5353 input).
⏳ Sonos-WLAN-Migration (7 Geräte FB-WLAN→VLAN40) als Anschluss an TP3/TP7 (User-seitig, schließt den Household).
5. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP10 (VPN), TP11 (Monitoring), TP12 (IPv6), TP13 (Spaß).
5. **TP10 (VPN) ✅ Kern durch (2026-06-27)** — Rest = FB-Bridge-Cutover (WAN-Seal + Liwest-Anruf), entblockt.
6. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP11 (Monitoring), TP12 (IPv6), TP13 (Spaß).