Elf Geräte im Netz, die niemand eingetragen hat — gefunden durch ein entferntes Flag

Der Plan war ein anderer. Für die zweite Ausbaustufe des Netzwerkbereichs im Control Center standen fünf Themen auf der Liste: VLANs, DHCP-Leases, VPN, DNS-Zählwerte und Verkehr je Gerät.

Erst messen, dann bauen. Statt der Liste zu folgen, habe ich jede Quelle einzeln am laufenden System abgefragt. Nach zwanzig Minuten war klar: vier von fünf haben schlicht keine Datengrundlage. Keine getaggten Interfaces, also keine VLANs. DHCP läuft hier über dnsmasq, der Exporter kennt nur Kea und ISC. Beim VPN antwortete der Endpunkt fehlerfrei mit null Zeitreihen — nichts kaputt, nur nichts eingerichtet. Und Pi-hole v6 hat keinen /metrics-Endpunkt mehr und beantwortet die API mit 401.

Hätte ich der Feature-Liste geglaubt, wären daraus vier Seiten mit erfundenen Zahlen geworden. Stattdessen hat jeder der fünf Bereiche jetzt seinen vollständigen Datenweg — und wo nichts fließt, benennt die Oberfläche, was fehlt und woran es liegt.

Der eigentliche Fund war ein Nebenprodukt. Beim Durchgehen dessen, was der OPNsense-Exporter überhaupt kann, fiel mir ein Flag auf: --exporter.disable-arp-table. Das hatte ich beim Einrichten selbst gesetzt und seitdem nie wieder angesehen. Der Collector liefert je Nachbar IP, MAC, Hostname und Interface — also genau die Frage, an der ich eine Stufe vorher gescheitert war und die in der Oberfläche als „unbekannt, weil keine Quelle" stand.

Flag raus, Exporter neu gestartet: 18 Einträge, 16 davon im LAN. Fünf Geräte waren gepflegt, elf nicht. Der größte Gewinn dieser Ausbaustufe war ein entferntes Flag, keine neue Software.

Vier der 16 melden eine zufällige MAC. Privacy-Randomisierung ist bei Telefonen und Tablets längst Standard. Das ist keine Störung, sondern eine Eigenschaft, die in die Oberfläche gehört: Solche Geräte erscheinen nach jedem Netzwechsel als neu. Trotzdem bleibt die MAC der bessere Schlüssel als die IP — eine MAC gehört zum Gerät, eine IP nur bis zum nächsten DHCP-Wechsel. Wer zuerst über die IP auflöst, ordnet früher oder später Messwerte dem falschen Gerät zu.

Der Fehler, den ich mir dabei selbst eingebaut habe: Der Verkehr eines Netzsegments war zunächst die Summe aller Geräte-Uplinks. Ergebnis: 351 Mbit/s auf einer Leitung, die 142 trug. Router und Switch tragen dieselben Pakete wie alle Endgeräte zusammen — die Summe zählt sie dreifach. Derselbe Fehler stand in der Rangliste der größten Verursacher, wo plötzlich die Weiterleiter ganz oben standen.

Die Regel „nicht addieren" war für Leitungen längst dokumentiert. Dass sie genauso für Segmentsummen und Ranglisten gilt, hatte ich nirgends übertragen — und beide Ergebnisse sahen völlig plausibel aus. Gemessen wird jetzt an genau einem Port; Weiterleiter fliegen aus der Rangfolge, werden aber benannt statt still gefiltert. Eine verschwundene Zeile hält irgendwann jemand für einen Fehler.

Was ich mitnehme: Nachsehen, was die vorhandenen Exporter schon können und nur abgeschaltet ist — das ist billiger als jede neue Komponente. Und: Ob ein Werbefilter läuft, sagt ein Prozessstatus. Ob er greift, sagt nur eine Abfrage auf eine bekannt geblockte Domain. Nur die deckt auch den Fall ab, dass der Dienst läuft und falsch antwortet.