Nachtrag Branko — RZ-NetBox: Mandant + Gruppe gesetzt, VM liefert 0 GerĂ€te

Von: Branko / Ansible-Katze → OZMAI
Stand: 13. Oktober 2026
Bezug: 2026-10-13_ANTWORT-OZMAI_TLS-GATE-V3-16-NETBOX-LIVE.md
Evidenz: Aussagen zum RZ-Zustand sind ATTESTED_BY_BRANKO, hier nicht selbst gegengeprĂŒft.

1. Der RZ-Befund hat sich geÀndert

OZMAI §1 geht von „RZ ohne Tenants“ aus. Das gilt nicht mehr: Im RZ sind Mandantengruppe und Mandant angelegt, die Verbindung ist nur lesend und in die richtige Gruppe provisioniert.

Die Warnung aus §1 bleibt trotzdem richtig. Der Connector liest bisher nur tenant=<slug> (Mandant). Die Mandantengruppe (tenant_group) ist eine eigene NetBox-Relation, die der Connector nicht auswertet. Ob die Gruppe im RZ die Grenze trÀgt oder der Mandant, ist damit nicht entschieden, nur die Voraussetzung ist da.

2. Warum 0 GerÀte: eine VM ist kein GerÀt

Der Connector liest ausschließlich dcim/devices. VMs liegen in virtualization/virtual-machines, einem anderen Objekttyp. Das ist als N7 schon dokumentiert („VMs werden nicht gespiegelt“, CHANGELOG „Nicht gebaut“).

Zur AbhÀngigkeitsfrage:

  • Die VM hĂ€ngt nicht vom GerĂ€t ab. Sie gehört zu einem Cluster. Optional kann sie einem Host-GerĂ€t zugeordnet sein (device-Feld der VM), das Ă€ndert aber nichts an der Abfrage.
  • Der Mandant an der VM ist ein eigenes Feld der VM. Er wird nicht ĂŒber das Host-GerĂ€t vererbt.
  • Ein Filter auf dcim/devices?tenant=
 kann eine VM deshalb nie liefern. 0 ist die korrekte Antwort auf die gestellte Frage, kein Verbindungs- oder Rechtefehler.

Gegenprobe, ohne Code zu Àndern:

GET /api/dcim/devices/?tenant=<slug>                    → erwartet 0
GET /api/virtualization/virtual-machines/?tenant=<slug> → erwartet 1 (die VM)

Wichtig: Der Token braucht dafĂŒr Leserecht auf virtualization. Das ist bei „nur lesen“ nicht automatisch dabei.

3. Bevor ein VM-Spiegel gebaut wird: zwei Stolpersteine

  1. IdentitĂ€tsraum. netbox:<id> ist heute eindeutig, weil nur GerĂ€te gelesen werden. GerĂ€te und VMs haben getrennte ID-RĂ€ume, GerĂ€t 7 und VM 7 können beide existieren. Der Anker mĂŒsste den Typ tragen (z. B. netbox:dev:<id> / netbox:vm:<id>), sonst kollidiert er still.
  2. Andere Unterobjekte. Bei VMs sind es virtualization/interfaces (MAC) und IPs ĂŒber virtual_machine_id statt device_id. Die wg-Key-Konvention im Kommentar (wg-pub <key>) mĂŒsste fĂŒr VMs erst bestĂ€tigt werden.

Beides ist PrĂŒffall, nicht Bauauftrag.

4. Zu §2 und §5: MAC und wg-Key sind jetzt in der DB

Die MAC-Adressen der Crumbforest-NetBox sind vollstĂ€ndig gespiegelt, inklusive hinterlegter wg-Pub-Keys. Das stĂŒtzt die engere Lesart:

  • Das sind administrative Anker aus einem Inventarscope, keine beobachtete GerĂ€tezuordnung (NETBOX_RECORD ⇏ OBSERVED_PHYSICAL_DEVICE).
  • Login ist eine Sitzung. Die GerĂ€tebindung lĂ€uft ĂŒber den Spiegel und ist eine getrennte Aussage (AUTHENTICATED_SESSION ⇏ IdentitĂ€t).

5. Stand zu OZMAI §7

# Frage Stand
1 Welche Relation trĂ€gt die Gruppengrenze im RZ? ⬜ Mandant/Gruppe jetzt vorhanden, Entscheidung offen
2 Connector liest sie, ohne Crumbforest-Tenant-Semantik zu importieren? ⬜ offen (tenant_group ungelesen, VMs ungelesen)
3 Was trĂ€gt ein GerĂ€te-Zertifikat dann? ⬜ offen, hĂ€ngt an 1 und an der Node-CA
4 WidersprĂŒchlicher Verwaltungsstand → getrennte Findings ⬜ offen, noch nicht gefahren

6. Neuer PrĂŒffall: CrumbDNS/OZMDNS auf dem Bare-Metal, ohne VMs

Zielbild (Branko): Im RZ lĂ€uft CrumbDNS/OZMDNS auf einem Bare-Metal-Host ohne VMs, ĂŒber eine BrĂŒcke intern im eigenen VPN. Die WG-VMs sind vom internen DNS getrennt, ebenso ZugĂ€nge und Freigaben.

Die Trennung liegt auf zwei Ebenen, nicht in einer:

RESOLVES(name)  ⇏ REACHABLE(host)
DNS_ENTRY       ⇏ ACCESS_GRANT
  • DNS: eigene interne Zone, Sicht pro Segment (BrĂŒcke / WG). Der Resolver lauscht nur auf wg und der BrĂŒcke, nicht auf 0.0.0.0.
  • Zugang und Freigabe: Firewall auf dem Host (default-deny, forward BrĂŒcke ↔ wg explizit), pro WG-Peer eigene AllowedIPs. Der DNS erteilt keine Freigabe.

Drei Punkte, die nicht belegt sind:

  1. ❓ Forwarding. Routet der Host zwischen wg0 und der BrĂŒcke? Wenn ja, erreicht ein Peer VMs, die er nicht auflösen kann. Die Trennung muss in der Firewall stehen.
  2. ❓ Quelle der Zone. Schreibt NetBox die Zone? Dann fehlen VMs im DNS, solange N7 (§2) offen ist. Eine Zone aus einem Spiegel ist eine Verwaltungsaussage (NETBOX_RECORD ⇏ OBSERVED_PHYSICAL_DEVICE).
  3. ❓ „Ohne VMs“ als Zustand. Ob der Host wirklich nur DNS und WG trĂ€gt, ist ATTESTED_BY_BRANKO, nicht geprĂŒft.

Frage an OZMAI: Welche Aussage trĂ€gt ein DNS-Eintrag in diesem Aufbau? Ein Eintrag sollte nur eine Auflösung bezeugen, keine Freigabe und keine Existenz des GerĂ€ts. Passt das zur Grenze „Wald liest und rendert, aktuiert keine Safety“?

PrĂŒffĂ€lle zum Fahren:

  • P-DNS-1: Namen auflösbar, Host nicht erreichbar (Firewall sperrt) → Findings getrennt, keine „GerĂ€t down“-Aussage.
  • P-DNS-2: Host erreichbar, Name fehlt (Zone nicht gepflegt) → kein „GerĂ€t unbekannt“.
  • P-DNS-3: Eintrag in der Zone, VM in NetBox gelöscht → Widerspruch zwischen zwei VerwaltungsstĂ€nden, kein automatisches Urteil.

7. Offen

  • ❓ Mandant oder Mandantengruppe als Grenze im RZ (Entscheidung Branko/Crew).
  • ❓ Token-Leserecht auf virtualization im RZ.
  • ❓ NetBox-Version im RZ (Token-Format).
  • ⬜ VM-Spiegel (N7), mit typgetragenem Anker (§3).
  • ⬜ tenant_group als Filter im Connector.
  • ❓ Ort der Node-CA.
  • ❓ DNS-PrĂŒffall (§6): Forwarding wg ↔ BrĂŒcke, Quelle der Zone, Zustand „ohne VMs“.
  • ⬜ „aus der Null oder in die Null“: zwei produktive Tests (Crumbforest-NetBox, RZ-NetBox) gegen dieselbe Passkante fahren, erst dann ACME-/Ansible-AnnĂ€herung bewerten.