Zum Inhalt

Discovery findet nichts

Ein Scan läuft durch, meldet aber „0 Geräte gefunden" — oder die Netz-Liste bleibt leer. Gescannt wird von einem Collector bzw. vom Aktiven Collector auf dem Vesana-Server, jeweils aus dessen Netz heraus — die meisten Ursachen liegen deshalb auf dieser Maschine oder im Netzwerk zwischen ihr und den Zielgeräten.

1. Ist ein Collector da und online?

Ohne einen erreichbaren Collector im Zielnetz gibt es nichts zu scannen. Ist keiner online, sagt die Discovery-Übersicht das ausdrücklich — „Geräte suchen (Scan)" und „Netze automatisch finden" funktionieren erst, wenn mindestens einer erreichbar ist. Auf einer Collector-VM:

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

Details: Collector.

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

Discovery scannt nur Netze, die der Collector kennt — aus seinen Netzwerk-Schnittstellen, seiner Routing-Tabelle, seinem ARP-Cache, per SNMP vom Gateway und von überwachten SNMP-Geräten, oder manuell eingetragen. Ist das Zielnetz gar nicht in der Liste:

  • „Netze automatisch finden" klicken — kein Geräte-Scan, sondern der Collector schaut neu nach, welche Netze er kennt. Von selbst läuft das nur einmal beim ersten Kontakt eines Collectors und, wenn beim Zeitplan „Subnetze vorher aktualisieren" angehakt ist, vor einem geplanten Scan — sonst auf Klick.
  • Fehlt das Netz danach immer noch: „Subnetz hinzufügen" (manuell eintragen, z. B. für Netze hinter einem VPN).
  • Prüfen, ob das Netz versehentlich ausgeschlossen ist — ein /16-Ausschluss sperrt auch alle /24-Netze darin.

Details: Discovery → Netze.

3. Manueller Erreichbarkeits-Test auf der Collector-Maschine

Der schnellste Weg, Netzwerk-Probleme von Vesana zu trennen — direkt auf der Collector-Maschine ein Gerät aus dem Zielnetz ansprechen, von dem du weißt, dass es läuft:

# Antwortet das Gerät auf Ping?
ping -c 3 192.168.1.10
# Ist ein bekannter Port offen (hier 443)?
timeout 3 bash -c '</dev/tcp/192.168.1.10/443' && echo offen
# Im selben Netz: steht das Gerät in der ARP-Tabelle?
ip neigh show 192.168.1.10

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

  • Firewall/Segmentierung: Blockt eine Firewall zwischen Collector und Zielnetz ICMP und die gescannten Ports? Im eigenen Netz findet der Scanner Geräte auch per ARP; in gerouteten Netzen braucht er ICMP oder einen offenen Port.
  • VLAN/Routing: Sitzt der Collector im selben VLAN wie die Zielgeräte, oder muss geroutet werden — und ist dieses Routing tatsächlich eingerichtet?
  • VPN/Tunnel: Läuft der Collector hinter einem VPN, das nur bestimmte Netze durchlässt?

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

4. Scan-Profil zu restriktiv?

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

Profil Ports Tempo
Stealth 4 (22, 80, 443, 3389) 50 Pakete/s
Normal 11 200 Pakete/s
Aggressiv 27 1000 Pakete/s — muss beim Start ausdrücklich bestätigt werden

Ein Gerät, das nur auf einem selten geprüften Port antwortet, taucht mit Stealth/Normal eventuell nicht als „Gerät mit Identität" auf, auch wenn es erreichbar ist. Fix: auf ein breiteres Profil wechseln. Stealth-Scans dauern in dichten Netzen merklich länger, weil die 50 Pakete/s eingehalten werden.

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. Außerdem fehlt dann die Routing-Tabelle des Gateways als Quelle für fremde Netze. Wenn „nichts gefunden" in Wirklichkeit „nichts identifiziert" bedeutet: SNMP-Community hinterlegen (Discovery → Einstellungen → SNMP-Communities), danach „Netze automatisch finden" bzw. einen neuen Scan von Hand anstoßen — eine neu hinzugefügte Community löst selbst nichts aus.

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 Adressen antwortet, oder pauschale RST-Antworten auf alles). 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" oder ist fehlgeschlagen

Zeigt die Scan-Historie einen Wartegrund statt eines Ergebnisses:

  • „Wartet auf Collector-Update" — der Scan wird zurückgehalten, bis der Collector auf die vorgesehene Version aktualisiert hat (verhindert, dass ein Auto-Update den laufenden Scan abbricht). Seit v1.903.0 nur, wenn der Collector das Update wirklich bekommt, und höchstens 30 Minuten lang — danach geht der Scan trotzdem raus.
  • „Collector offline" — der Scan wartet auf Abholung durch den Collector, sobald der wieder online ist.

Ein Scan hat insgesamt 15 Minuten; läuft die Frist ab, bevor die Nachprüfung der Geräte fertig ist, meldet der Collector den Scan als fehlgeschlagen statt ein unvollständiges Ergebnis zu liefern. In großen Netzen dann in kleinere Bereiche teilen oder ein schnelleres Profil wählen.

Checkliste

  1. Collector online? (journalctl)
  2. Zielnetz in der Liste, nicht ausgeschlossen?
  3. Manueller ping / Port-Test von der Collector-Maschine 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