Network Worker
Ein Python-basierter Dienst, der im Kundennetzwerk läuft und SNMP-Polling, Ping-Monitoring, Netzwerk-Scans und SSH-Konfigurationsbackups übernimmt – vollautomatisch und offline-fähig.
Offener Quellcode
Genau wie beim IT-Doku Agent gilt: Der Network Worker ist bewusst kein kompiliertes Binary. Der komplette Python-Quellcode liegt offen unter /opt/network-worker/src/ auf dem installierten System.
Jede Netzwerkoperation ist nachvollziehbar – kein versteckter Traffic.
Sicherheitsprüfer können den Code einsehen, bevor er im Netzwerk aktiv wird.
Eigene SNMP-OIDs, SSH-Handler oder Scanner-Logik hinzufügen.
Was macht der Network Worker?
Der Worker läuft als systemd-Service auf einer Linux-Maschine im Kundennetzwerk (z.B. ein kleiner Server, eine VM oder ein Raspberry Pi) und kommuniziert mit dem Portal über eine REST-API.
SNMP-Polling
Switches, Drucker, NAS, USV, APs – System-Info, Interfaces, MAC/ARP-Tabellen, Toner, Speicher
Ping-Monitoring
Kontinuierliches ICMP-Monitoring mit Ausfallserkennung, Latenz-Tracking und Protokoll
Network Discovery
ARP-Scan, Port-Scan, MAC-Vendor-Lookup, Gerätetyp-Erkennung (~200 Hersteller)
SSH-Backup
Firewall- und Switch-Konfigurationen sichern (Securepoint, Cisco, HP, Aruba)
Firewall-Sync
Securepoint UTM, Cisco IOS, Aruba OS/CX – Regeln, Interfaces, Konfiguration synchronisieren
Auto-Update
Hash-basierte Versionserkennung, Download und Update ohne manuelle Eingriffe
Installation
Der Worker wird mit einem einzigen Befehl installiert. Das Installationsscript erkennt die Linux-Distribution automatisch.
Installationsscript ausführen
Auf einer Linux-Maschine im Kundennetzwerk (Ubuntu, Debian, CentOS, RHEL, Rocky, Fedora):
curl -sSL https://ihr-portal.de/network-worker/install.sh | sudo bashInstalliert Python 3, libpcap, erstellt den Systembenutzer network-worker, richtet systemd-Service ein und startet das Web-UI auf Port 8080.
API-Token im Web-UI hinterlegen
Öffnen Sie http://<server-ip>:8080 im Browser. Erstellen Sie im Portal unter Admin → Network Workers einen neuen Worker und kopieren Sie den API-Token in die Konfigurationsseite.
Fertig – Worker arbeitet
Der Worker verbindet sich mit dem Portal, meldet sich per Heartbeat und beginnt, zugewiesene Aufgaben auszuführen.
Installationspfade
/opt/network-worker/ – Quellcode
/etc/network-worker/config.yaml – Konfiguration
/var/log/network-worker/ – Logs
/var/lib/network-worker/cache.db – Lokaler Cache (SQLite)
Systemvoraussetzungen
Linux (64-bit) mit systemd
Python 3.10+ (wird automatisch installiert)
Netzwerkzugang zum Portal (HTTPS, Port 443)
Zugriff auf das Kundennetzwerk (SNMP, ICMP, SSH)
Architektur
Der Worker betreibt 6 unabhängige asynchrone Schleifen parallel:
Heartbeat
Meldet dem Portal: „Ich lebe". Unabhängig von allen anderen Schleifen – auch bei Netzwerkproblemen zuverlässig.
Task-Polling
Holt neue Aufgaben vom Portal (SNMP-Abfrage, Discovery, SSH-Backup, etc.) und führt sie aus.
Sync
Sendet gesammelte Ergebnisse ans Portal. Bei Verbindungsverlust mit exponentiellem Backoff (bis 5 Min).
Autonome Tasks
Führt wiederkehrende Aufgaben (SNMP-Polling, Backups) nach konfigurierbarem Intervall aus dem lokalen Cache aus – auch offline.
Ping-Monitor
Kontinuierliche ICMP-Überwachung aller konfigurierten Ziele mit einstellbarem Intervall (1–60 Sekunden).
Auto-Update
Prüft alle 5 Minuten per SHA256-Hash ob eine neue Version verfügbar ist. Update ohne Neustart-Unterbrechung.
Offline-Fähigkeit
Der Worker arbeitet auch ohne Verbindung zum Portal weiter:
- Lokaler SQLite-Cache speichert wiederkehrende Aufgaben, Scheduling-Zeiten und Ergebnisse
- Autonome Tasks laufen nach konfigurierbarem Intervall (1–120 Min) unabhängig vom Portal
- Ergebnis-Queue puffert Daten und sendet sie, sobald das Portal wieder erreichbar ist
- Ping-Monitoring läuft ununterbrochen – Ausfälle werden auch offline protokolliert
- Scheduling bleibt stabil: Task-Zeitpläne werden lokal verwaltet und beim Sync mit dem Portal nicht zurückgesetzt
Ideal für Außenstellen: Der Worker eignet sich besonders für Standorte mit instabiler Internetverbindung. Die Daten gehen nie verloren – sie werden lokal zwischengespeichert und automatisch synchronisiert.
SNMP-Polling
Der Worker unterstützt SNMP v1, v2c und v3 und kann folgende Daten abfragen:
System-Info
Hostname, Beschreibung, Uptime, Standort
Interfaces
Name, Speed, Admin-/Oper-Status pro Port
MAC-Tabelle
Welche MAC-Adresse an welchem Port (Layer-2 Topologie)
ARP-Tabelle
IP-zu-MAC-Zuordnungen für die Netzwerk-Dokumentation
Drucker-Status
Seitenzähler, Toner-Füllstände, Verbrauchsmaterial, Fehlerzustand
Speicher (Storage)
Festplatten/Volumes mit Kapazität und Belegung (HOST-RESOURCES-MIB)
Die SNMP-Daten werden im Portal automatisch ausgewertet für Monitoring-Alerts (Toner-Warnung, Speicher voll, Neustart-Erkennung).
Automatisches Polling
Für Switches mit aktiviertem SNMP erstellt das Portal automatisch wiederkehrende Poll-Aufgaben. Das Intervall ist pro Switch konfigurierbar:
| Intervall | Empfehlung |
|---|---|
1–2 Min | Nur für Debugging – erzeugt hohe Last auf Switch und Worker |
5 Min | Kritische Infrastruktur (Core-Switches, Rechenzentrum) |
15 Min (Standard) | Empfohlen – guter Kompromiss zwischen Aktualität und Last |
30–60 Min | Stabile Umgebungen, Access-Switches mit wenig Änderungen |
120 Min | Selten genutzte Switches, Außenstellen |
Der Artisan-Command switch:auto-schedule läuft alle 5 Minuten und erstellt bzw. aktualisiert die Recurring-Tasks automatisch. Wird SNMP für einen Switch deaktiviert, wird der zugehörige Task ebenfalls deaktiviert.
Automatische Port-Erkennung
Nach jedem SNMP-Poll erkennt das Portal automatisch, welches Gerät an welchem Switch-Port hängt – ohne manuelles Zuordnen.
SNMP-Poll holt MAC-Tabelle
Der Worker liest per Q-BRIDGE-MIB alle MAC-Adressen und deren zugehörige Ports aus dem Switch.
PortMappingService gruppiert nach Port
MACs werden nach if_index gruppiert. Ports mit genau 1 MAC = Direktverbindung, Ports mit >3 MACs = Uplink.
MAC-Adresse wird abgeglichen
Jede MAC wird gegen bekannte Quellen geprüft: Geräte (primary_mac), Netzwerk-Interfaces, andere Switches, Firewalls, Discovery-Ergebnisse.
Verbindungen werden geschrieben
Erkannte Zuordnungen werden auf den Switch-Port geschrieben und automatisch als Topologie-Verbindungen für das Netzwerk-Diagramm angelegt.
Direktverbindung
1 MAC auf dem Port → Gerät direkt am Switch angeschlossen (PC, Drucker, NAS, AP)
Uplink
>3 MACs auf dem Port → Verbindung zu anderem Switch, Firewall oder Router. Port wird als Uplink markiert.
Topologie
Erkannte Verbindungen erscheinen automatisch im Netzwerk-Diagramm. Manuell erstellte Verbindungen werden nie überschrieben.
Automatisch vs. manuell: Auto-erkannte Verbindungen werden mit einem is_auto_detected-Flag markiert. Beim nächsten Poll werden veraltete Auto-Verbindungen bereinigt, manuell erstellte Verbindungen bleiben immer erhalten.
MAC-Tabelle & Port-Map
In der Switch-Übersicht können Sie die MAC-Tabelle jedes Switches einsehen:
- Port-Map: Pro Port: Name, Anzahl MACs, erkanntes Gerät (Name + IP), Verbindungstyp (Direkt/Uplink/Leer)
- MAC-Tabelle: Alle MAC-Adressen sortiert nach Port, mit VLAN, Vendor-Hint und Discovery-Match
- Statistik: Gesamt-Ports, belegte Ports, erkannte Geräte, Uplinks
- Jetzt scannen: Erstellt sofort einen SNMP-Poll-Task für den ausgewählten Switch
Network Discovery
Der Worker führt auf Anfrage des Portals Netzwerk-Scans durch. Mehr dazu in der Discovery-Dokumentation.
- ARP-Scan: Schnelle Erkennung aller Geräte im lokalen Subnetz (via scapy)
- Ping-Probe: ICMP-Fallback für Subnetze ohne ARP-Zugriff
- rDNS-Lookup: Hostname-Auflösung über Reverse-DNS
- MAC-Vendor-Lookup: OUI-Datenbank mit ~200 Herstellern (Cisco, HP, Brother, etc.)
- Port-Scan: Offene Ports erkennen (9100=Drucker, 161=SNMP, 3389=RDP, etc.)
- SNMP-Probe: Automatische SNMP-Erkennung und Datenabfrage
Web-UI Dashboard
Der Worker hat ein eingebautes Web-Dashboard auf Port 8080 für Einrichtung und Diagnose:
Status-Übersicht
Uptime, Verbindungsstatus, verarbeitete Tasks, Speicherverbrauch
Live-Logs
Echtzeit-Log-Anzeige mit Farbcodierung und Filter nach Level (Error/Warning/Info/Debug)
Netzwerk-Info
Lokale Interfaces, IP-Adressen, MAC, Geschwindigkeit
Einstellungen
Portal-URL, API-Token, Poll-Intervall, Verbindungstest
Szenario: Sie übernehmen einen neuen Kunden und möchten alle Netzwerk-Geräte automatisch erfassen.
- 1. Worker auf einer Linux-VM im Kundennetzwerk installieren (Einzeiler, 5 Minuten).
- 2. Im Portal unter Netzwerke die Kunden-Subnetze eintragen (z.B.
192.168.1.0/24,10.0.0.0/24). - 3. Discovery-Scan starten – der Worker scannt per ARP, erkennt Geräte, Hersteller und offene Ports.
- 4. Entdeckte Geräte direkt als Inventar-Einträge übernehmen (Name, IP, Typ vorausgefüllt).
- 5. SNMP-Credentials hinterlegen → Switches, Drucker und NAS werden automatisch gepollt. Erste PDF-Dokumentation in 30 Minuten fertig.
Sicherheit
Eigener Systembenutzer
Läuft als network-worker mit minimalen Rechten. Nur CAP_NET_RAW für ARP-Scanning.
Bearer-Token-Auth
Jeder Worker hat einen eigenen API-Token. Kommunikation nur über HTTPS.
systemd-Sandbox
ProtectSystem=strict, ProtectHome=yes – kein Zugriff auf System- oder Home-Verzeichnisse.
Konfiguration geschützt
/etc/network-worker/ mit Modus 700 – nur root und der Service-User können lesen.
Hinweis: Pro Kundenstandort wird ein Network Worker benötigt. Bei mehreren Standorten installieren Sie je einen Worker vor Ort. Über die Standortzuordnung im Portal wird sichergestellt, dass jeder Worker nur seine lokalen Geräte pollt.
Tipp: Das Web-UI auf Port 8080 ist nur für die Ersteinrichtung gedacht. Im laufenden Betrieb verwalten Sie den Worker über das Portal (Admin → Network Workers). Logs können Sie auch per journalctl -u network-worker -f lesen.
Häufige Fragen
Prüfen Sie: (1) Läuft der Service? systemctl status network-worker (2) Ist das Portal erreichbar? curl -I https://ihr-portal.de (3) Ist der API-Token korrekt? Schauen Sie ins Web-UI unter http://worker-ip:8080 → Einstellungen.
Jedes Linux-System reicht: eine VM mit 1 vCPU und 512 MB RAM, ein Raspberry Pi, ein alter Thin Client oder ein Container. Der Worker braucht kaum Ressourcen – er muss nur Netzwerkzugang zum Kundennetz und Internet zum Portal haben.
Ja – ein Worker pro Kundennetzwerk (bzw. Standort). Der Worker muss im selben Netzwerk sein wie die Geräte, die er scannen und pollen soll. Bei einem Kunden mit 3 Standorten brauchen Sie 3 Worker.
Vollautomatisch. Der Worker prüft alle 5 Minuten per SHA256-Hash ob eine neue Version auf dem Portal verfügbar ist. Bei einem Update wird das neue Paket heruntergeladen, entpackt und per rsync angewendet – die Konfiguration und der lokale Cache bleiben erhalten. Der Service startet automatisch neu.
Nach jedem SNMP-Poll liest der PortMappingService die MAC-Tabelle des Switches aus und gleicht die MAC-Adressen mit bekannten Geräten, Switches und Firewalls ab. Ports mit genau einer MAC werden als Direktverbindung erkannt, Ports mit vielen MACs als Uplink. Erkannte Zuordnungen werden automatisch als Topologie-Verbindungen angelegt. Manuell erstellte Verbindungen werden dabei nie überschrieben.
Das Intervall ist pro Switch einstellbar: 1, 2, 5, 15, 30, 60 oder 120 Minuten. Standard sind 15 Minuten. Recurring-Tasks werden vom Worker lokal gecacht und auch bei Verbindungsunterbrechung zum Portal zuverlässig ausgeführt.