Zum Inhalt

Discovery findet nichts

Ein Scan läuft durch, meldet aber „0 Geräte gefunden" — oder die Subnet-Liste bleibt leer. Discovery läuft komplett auf dem Collector, nicht auf dem Vesana-Server selbst — die meisten Ursachen liegen deshalb auf der Collector-VM oder im Netzwerk zwischen ihr und den Zielgeräten.

1. Läuft überhaupt ein Collector, und ist er online?

Ohne mindestens einen Collector im Zielnetz gibt es nichts zu scannen — der Scan-Button ist dann auch bewusst deaktiviert. Prüfe auf der Discovery-Übersicht die Collector-Zahl im Header, und auf der Collector-VM:

journalctl -u vesana-collector --since '5 minutes ago'

Details: Collector.

2. Steht das richtige Subnet überhaupt in der Liste?

Discovery scannt nur Subnets, die der Collector kennt — abgeleitet aus seinen Netzwerk-Interfaces, seiner Routing-Tabelle, per SNMP vom Gateway, oder manuell eingetragen. Ist das Zielnetz gar nicht in der Subnet-Liste:

  • „Subnetz-Liste neu laden" klicken — kein Scan, sondern zieht nur die aktuellen Interfaces/Routen/SNMP-Walk-Ergebnisse des Collectors neu (läuft von selbst nur einmal beim ersten Kontakt eines Collectors — sonst auf Klick oder per Zeitplan-Häkchen „Subnetze vorher aktualisieren")
  • Fehlt das Subnet danach immer noch: manuell eintragen (Subnet-Liste → „Subnet manuell eintragen")
  • Prüfen, ob das Subnet versehentlich als ausgeschlossen markiert ist — ein /16-Exclude blockt auch alle darunterliegenden /24-Subnets

Details: Discovery → Netze.

3. Manueller nmap-Test auf der Collector-VM

Der schnellste Weg, Discovery-Probleme vom eigentlichen Collector-Code zu trennen — direkt auf der Collector-VM:

# Ping-Scan (kein Port-Scan):
sudo nmap -sn 192.168.1.0/24

Findet auch der manuelle Scan nichts, liegt das Problem im Netzwerk zwischen Collector und Zielgeräten — nicht an Vesana:

  • Firewall/Segmentierung: Blockt eine Firewall zwischen Collector-VM und Zielsubnet ICMP oder die gescannten Ports? Discovery braucht mindestens ICMP-Erreichbarkeit für den initialen Ping-Sweep.
  • VLAN/Routing: Sitzt die Collector-VM im selben VLAN wie die Zielgeräte, oder muss geroutet werden — und ist dieses Routing tatsächlich eingerichtet?
  • VPN/Tunnel: Läuft die Collector-VM hinter einem VPN, das nur bestimmte Subnets durchlässt?

Findet der manuelle nmap-Scan dagegen problemlos Geräte, aber Vesana zeigt trotzdem nichts, liegt es eher an Scan-Profil, Ausschlüssen oder der Ghost-Filter-Logik (siehe unten).

4. Scan-Profil zu restriktiv?

Das Scan-Profil bestimmt, wie viele Ports geprüft werden und wie aggressiv gescannt wird:

Profil Ports Hinweis
Stealth 4 (22, 80, 443, 3389) findet nur Geräte mit diesen offenen Ports
Normal (Default) 8 guter Kompromiss
Aggressiv 24 breiteste Erkennung, aber mehr Netzlast und höheres IDS-Aufkommen

Ein Gerät, das nur auf einem selten geprüften Port antwortet (z. B. reines SNMP ohne die Standard-Ports), taucht mit Stealth/Normal eventuell gar nicht als „Gerät mit Identität" auf, auch wenn es per ICMP durchaus erreichbar ist. Fix: auf ein breiteres Profil wechseln oder gezielt die Aggressiv-Option für dieses eine Subnet nutzen.

Details: Discovery → Scan-Profile.

5. SNMP-Community fehlt

Ohne passende SNMP-Community bleibt ein Gerät, das eigentlich viele Detail-Infos liefern könnte, als „Unbekanntes Gerät (antwortet auf Ping)" stehen — es wird also durchaus gefunden, aber nicht identifiziert. Wenn „nichts gefunden" in Wirklichkeit „nichts identifiziert" bedeutet: SNMP-Community früh hinterlegen (Discovery → Einstellungen → SNMP-Communities), dann „Subnetz-Liste neu laden" oder einen erneuten Scan anstoßen — eine neu hinzugefügte Community stößt automatisch einen Subnet-Refresh an.

6. Ghost-Filter zieht zu breit? (selten)

Discovery filtert automatisch bekannte Netzwerk-Artefakte heraus — aber nur beweisbare (eine Proxy-ARP-MAC-Adresse, die auf mehr als drei IPs antwortet, oder pauschale RST-Sweeps). Ein Gerät, das nur auf Ping antwortet und sonst nichts freigibt, bleibt bewusst sichtbar — der Filter ist konservativ. Fehlt trotzdem ein bestimmtes, dir bekanntes Gerät komplett aus den Ergebnissen, ist der Ghost-Filter erfahrungsgemäß selten die Ursache — eher Punkt 3 oder 4 oben.

7. Scan hängt in „wartend"

Zeigt die Scan-Historie einen amber Wartegrund statt eines Ergebnisses:

  • „Wartet auf Collector-Update" — der Scan bleibt bewusst zurückgehalten, bis der Collector auf die für den Scan vorgesehene Version aktualisiert hat (verhindert, dass ein Auto-Update den laufenden Scan-Prozess killt). Läuft automatisch weiter, sobald das Update durch ist.
  • „Collector offline" — der Scan wartet auf Abholung durch den Collector, sobald der wieder online ist.

Kein Fehler, sondern Selbstschutz — abwarten oder Collector-Status prüfen (Punkt 1).

Checkliste

  1. Collector online? (journalctl)
  2. Zielsubnet in der Subnet-Liste, nicht ausgeschlossen?
  3. Manueller nmap -sn von der Collector-VM erfolgreich?
  4. Scan-Profil breit genug für die Zielgeräte?
  5. SNMP-Community hinterlegt, falls Identifikation (nicht nur Sichtbarkeit) gewünscht ist?
  6. Scan-Historie zeigt einen Wartegrund statt eines Fehlers?

Anschluss