Search by

do1emu / module-netzwerk

do1emu

Netzwerk-Modul für die modulare Intranet-Plattform: Inventar und Karte des lokalen Netzwerks, erhoben von einem externen Collector (z. B. Raspberry Pi), gelesen aus einer MSSQL-Datenbank.

Package info

github.com/kleinebekele/intranet-module-netzwerk

pkg:composer/do1emu/module-netzwerk

Security

Advisories: 0

Aikido package health analysis

Transparency log

Statistics

Installs: 51

Dependents: 0

Suggesters: 0

Stars: 0

Open Issues: 0

v1.17.1 2026-09-24 08:46 UTC

Requires

  • php: ^8.3

Requires (Dev)

None

Suggests

None

Provides

None

Conflicts

None

Replaces

None

MIT 38075b1ad3c5586d2439818bea2fc55717a6a253

  • do1emu

laravelsnmpintranetmodulnetzwerkinventar

Published on Packagist.org on 2026-09-24 08:46 UTC

This package is auto-updated.

Last update: 2026-09-24 08:46:40 UTC

README

Modul für die modulare Intranet-Plattform: zeigt das Inventar und die Karte des lokalen Netzwerks – welche Geräte es gibt, wo sie hängen, ob sie online sind.

Seiten: Karte (Topologie-Baum aus LLDP-Daten: Switches mit Portanzahl, aktueller Rate, Fremd-Nachbarn und Redundanz-Querverbindungen; neu entdeckte, noch nicht abfragbare Geräte erscheinen amber mit Einbindungs-Anleitung), Geräte (Endgeräte-Inventar aus dem Ping-Scan, je Netzsegment, mit Spalten „Anschluss", Typ, Standort und Info) und je Knoten eine Detailseite (Portleiste mit Status/Speed/Rate/Uplinks und VLANs („1U, 10T" = untagged/tagged), angeschlossene Geräte je Port, WLAN-Clients bei APs, Nachbarn, Link zum Webinterface des Geräts) – verlinkt aus Karte und Geräteliste.

Pflege-Daten: Zu jedem Gerät (Endgerät wie Infrastruktur-Knoten) lassen sich Gerätetyp, Standort und ein freies Info-Feld hinterlegen – Stift-Symbol in der Geräteliste bzw. „bearbeiten" auf der Knoten-Detailseite. Standorte sind eine Hierarchie (Gebäude → Stockwerke → Räume, jede Ebene einzeln pflegbar, Räume per Komma in Serie); am Gerät wählt man einen Punkt daraus (ganzes Gebäude, Stockwerk oder Raum). Typen und Standorte verwaltet je ein eigener Menüpunkt (CRUD). Diese Daten liegen in der Instanz-Datenbank (netzwerk_geraetetypen, netzwerk_gebaeude, netzwerk_stockwerke, netzwerk_raeume, netzwerk_geraete, verknüpft lose über MAC bzw. IP) – die MSSQL-Quelle bleibt read-only. Viele Typen erkennt das Modul automatisch (Knoten-Art, Hersteller, Hostname); erkannte Typen erscheinen kursiv und werden beim Speichern im Formular übernommen.

Das Modul liest nur. Erhoben werden die Daten von einem externen Collector (bei uns: ein Raspberry Pi im Netz, der per nmap und SNMP scannt) und in eine MSSQL-Datenbank geschrieben; das Intranet kennt keinerlei Zugangsdaten zu Netzwerkgeräten.

Installation

composer require do1emu/module-netzwerk
php artisan modules:sync
php artisan migrate

Danach in der .env die Datenquelle hinterlegen (ODBC-Weg, empfohlen):

NETZWERK_DB_DSN="Driver={ODBC Driver 18 for SQL Server};Server=host,1433;Database=meinedb;TrustServerCertificate=yes"
NETZWERK_DB_USERNAME=leser
NETZWERK_DB_PASSWORD=...
# optional (Standard: Ekkon3):
# NETZWERK_DB_SCHEMA=Ekkon3

Alternativ nativ über pdo_sqlsrv mit NETZWERK_DB_HOST / NETZWERK_DB_PORT / NETZWERK_DB_DATABASE – Details in config/netzwerk.php.

Ohne Konfiguration zeigt das Modul einen Hinweis statt Fehlern.

Sichtbarkeit: Der Menüpunkt startet ohne Rollen-Freigabe (= nur Admins). Die Übersicht zeigt Netz-Interna (IPs, MACs, Hostnamen) – bewusst je Rolle freischalten unter Verwaltung → Module → Netzwerk.

Für die lokale Entwicklung ohne erreichbare MSSQL-Quelle zeigt NETZWERK_DEMO=true erfundene Beispieldaten auf der Karte (niemals auf einem Server setzen).

Datenmodell

Gelesen werden aus {schema}:

  • network_devices – Endgeräte-Inventar (Ping-Scan): mac, ip, segment, hostname, vendor, firstSeen, lastSeen
  • network_nodes – Infrastruktur (Switches, APs, Controller, Firewall) mit status (aktiv | entdeckt | stumm)
  • network_links – LLDP-Kanten (inkl. Fremd-Nachbarn ohne eigenen Node)
  • network_ports – Ports je Node mit Status, Speed, aktueller Rate (bit/s) und VLAN-Mitgliedschaften (pvid, vlanUntagged, vlanTagged; leer bei Geräten ohne Q-BRIDGE-MIB)

Das Schema samt Staging-Tabellen und MERGE liegt unter pi/ beim Collector. „online" berechnet das Modul beim Lesen aus lastSeen (Standard: 15 Minuten, NETZWERK_OFFLINE_AB_MINUTEN), nicht aus gespeicherten Flags – fällt der Collector aus, zeigt die Übersicht ehrlich offline.

DHCP

Seite DHCP: je DHCP-Bereich eine Adresskarte (jede IP des Netzes), der Verlauf der freien Adressen und die Liste „Wer hatte wann welche Adresse".

  • Rahmen = Pool. Durchgezogen: DHCP möglich (zwischen Start und Ende, nicht ausgeschlossen). Gestrichelt: DHCP nicht möglich.
  • Füllung = Belegung. Reservierung, Lease, manuell belegt (im Intranet gepflegt, für Geräte mit fester IP, die nicht antworten), antwortet (im Ping-Scan online) oder frei. Vergibt der DHCP-Server eine manuell belegte Adresse trotzdem, bekommt das Kästchen einen roten Ring.
  • Klick auf ein Kästchen zeigt Gerät, MAC, Hersteller, Ping-Stand und die Pflege-Daten (Typ, Standort, Info) mit Link zum Bearbeiten.
  • Knopf „Skript: Ausschlüsse als Einzel-IPs" erzeugt ein PowerShell-Skript, das die Ausschluss-Bereiche durch einzelne IPs ersetzt (gleiche Adressen, Pool unverändert; mit Probelauf, Sicherung, Abgleich und Gegenprobe) und die Bezeichnungen aus dem Intranet auflistet – Ausschlüsse selbst haben im Windows-DHCP kein Beschreibungsfeld.

Die Daten liefert scripts/dhcp-statistik.ps1 auf einem Windows-DHCP-Server an den Webhook-Eingang der Plattform (Ekkon → Webhook-Eingang, eigene Quelle anlegen, URL übernehmen):

.\dhcp-statistik.ps1 -Url https://<intranet>/webhooks/ekkon/<schluessel> -Einrichten

Das legt eine geplante Aufgabe an (alle 15 Minuten). Der Task Netzwerk/Dhcp übernimmt die Eingänge alle 5 Minuten in netzwerk_dhcp_*. Belegungen (Gerätename, MAC) sind personenbezogen und werden nach 90 Tagen gelöscht (Task-Einstellung).

Ausbaustufen

  1. ✅ Geräte-Inventar
  2. ✅ Netzwerkkarte aus LLDP-Daten (Topologie-Baum, Discovery unbekannter Switches)
  3. ✅ Gerät-zu-Switchport-Zuordnung (FDB) und WLAN (WC7500: Controller und APs als Karten-Knoten, Clients mit „AP + SSID") – Spalte „Anschluss" in der Geräteliste
  4. ✅ OPNsense-ARP + DNS-Namen (MACs/Namen über alle Netze, Firewall auf der Karte; die Firewall-Interfaces erscheinen als Ports ihres Knotens)
  5. ✅ Traffic-Statistiken – Seite „Statistik": Verläufe je Port (24 h / 7 Tage / 30 Tage) aus network_port_stats, serverseitig gerenderte SVG-Charts
  6. ✅ Alarme – über Ekkon, das Task-System der Plattform (seit 2026-09 fest im Core), registriert das Modul den Task Netzwerk/Alarme: meldet über die Ekkon-Benachrichtigungsrouten, wenn ein eingebundener Knoten nicht mehr antwortet (Schwelle einstellbar), wieder erreichbar ist (abschaltbar), ein neues Gerät entdeckt wurde oder in einem WLAN mehr Geräte gleichzeitig eingebucht sind als erlaubt. Die überwachten WLANs werden auf der Task-Seite gepflegt (Ekkon-Basis ≥ 1.20, Einstellung vom Typ view): Mehrfachauswahl aus den vom Collector gesehenen SSIDs (mehrere = zusammen- gezählt, etwa 2,4- und 5-GHz-Netz desselben WLANs) plus Schwelle, Liste mit Entfernen. Gemeldet wird der Übergang, Quelle ist der Schnappschuss network_wlan_clients des Collectors. Knoten, die nicht dazugehören (z. B. ein LLDP-sprechender Virtualisierungs-Host), lassen sich auf ihrer Detailseite ausblenden – weg von Karte und Alarm, jederzeit über den Abschnitt „Ausgeblendet" auf der Karte zurückholbar. Der erste Lauf merkt sich nur die Ausgangslage. ⚠️ Ohne eingerichtete Route (Ekkon → Benachrichtigungen) erreichen die Meldungen niemanden — der Task weist in seiner Lauf-Historie darauf hin.

Das Konzept samt Collector-Beschreibung liegt bei der betreibenden Instanz. Das Repo selbst bleibt frei von Netzdaten.