Ein Laptop, NAS, Drucker oder Smartphone kann im Heimnetz problemlos funktionieren, ohne in einem Scan aufzutauchen. Die gewohnte App funktioniert vielleicht noch, ein freigegebener Ordner lässt sich öffnen oder das Gerät hat gerade eine Benachrichtigung gesendet. Da liegt der Gedanke nahe, dass der Scan falsch liegt oder das Gerät aus dem Netzwerk verschwunden ist. Ein einzelner fehlender Treffer lässt aber keinen dieser Schlüsse zu.
Ein häufiger Grund: Der Scan hat per Ping, also ICMP Echo, nach Geräten gesucht. Ein Gerät kann den Datenverkehr für seine normale Aufgabe zulassen, ohne auf ICMP Echo zu antworten. Es könnte aber auch im Ruhemodus sein, in einem anderen Netzwerksegment liegen oder außerhalb des Scanbereichs. Dieser Guide geht diese Möglichkeiten mit dir durch. Die Prüfung bleibt dabei auf ein Netzwerk begrenzt, das dir gehört oder das du verwalten darfst.
Ein fehlender Scan-Eintrag als einzelne Beobachtung
Halte zuerst fest, was der Scan tatsächlich gemacht hat. Notiere die Uhrzeit, den verwendeten Computer, dessen Netzwerk oder VLAN, den Zielbereich und alle Erkennungsmethoden, die das Tool anzeigt. Schreib auch den erwarteten Gerätenamen und die IP-Adresse auf, soweit du sie kennst. Halte außerdem fest, welche normale Aktivität darauf hindeutete, dass das Gerät online war. Mach das, bevor du einen Router neu startest, eine Firewall-Regel änderst oder einen Lease entfernst.
Ob ein Gerät „online“ ist, lässt sich nicht mit einem einzigen Netzwerktest klären. Ein Drucker kann einen Druckauftrag annehmen, aber einen Ping unbeantwortet lassen. Ein NAS kann einem Client eine Datei bereitstellen und gleichzeitig für einen Scan aus dem Gast-WLAN unerreichbar sein. Ein Smartphone wacht vielleicht kurz für eine Push-Nachricht auf und geht wieder in den Ruhemodus, bevor du den Scan startest. Auch umgekehrt gilt: Eine Ping-Antwort beweist nicht, dass alle Dienste auf dem Gerät funktionieren.
Das Internet Control Message Protocol definiert Echo-Request- und Echo-Reply-Nachrichten. Daraus folgt nicht, dass jeder Host oder jede Netzwerkrichtlinie eine Antwort an jeden anderen Host ermöglichen muss. RFC 792 beschreibt die Protokollnachrichten selbst. Eine ausbleibende Echo-Antwort sagt etwas über genau diese Anfrage und ihren Netzwerkpfad aus. Den Gesamtzustand des Geräts kannst du daraus nicht ablesen.
Vergleich der Netzwerkpositionen
Prüfe vor der Fehlersuche, wo das Gerät im Netzwerk eingebunden ist und von wo aus du den Scan ausgeführt hast. Befinden sich der scannende Computer und das gesuchte Gerät in derselben SSID, im selben kabelgebundenen LAN, VLAN oder gerouteten Subnetz? Gast- und IoT-Netzwerke schränken den Datenverkehr zwischen Clients oft absichtlich ein. Bei einem Mesh-System kann ein Gerät scheinbar nah am Router sein und trotzdem in einem eigenen Segment mit anderen Regeln für den Datenverkehr liegen.
Prüfe auch den Zielbereich. Ein Scan von 192.168.1.0/24 erfasst zum Beispiel kein Gerät mit der Adresse 192.168.168.25, selbst wenn beide Adressen zu Netzwerken am selben Standort gehören. Weite den Scan nicht auf Netzwerke aus, die du nicht verwaltest, nur um die Liste zu vervollständigen. Wenn du ein weiteres Subnetz verwaltest, prüfe dessen Adressbereich und die Route dorthin separat.
Bei einem IPv4-Gerät im selben lokalen Netzwerksegment kann ein kürzlich beobachteter Eintrag in der ARP- oder Nachbartabelle helfen. ARP ordnet einer IPv4-Adresse eine Adresse der Verbindungsschicht im lokalen Netzwerk zu. Es sucht nicht über einen Router hinweg nach Geräten in anderen Segmenten. RFC 826 erklärt diese lokale Funktion. Ein gespeicherter Eintrag beweist nicht, dass das Gerät noch da ist. Er kann dir aber helfen zu entscheiden, ob du die lokale Adresse oder den gerouteten Pfad genauer prüfen solltest.
Erkennungsmethoden des Scans
Tools zur Geräteerkennung nutzen unterschiedliche Abfragen. Je nach Tool, Berechtigungen und Ziel kann ein Scan ARP im lokalen IPv4-Netzwerk, ICMP Echo, TCP-Verbindungsversuche oder mehrere Methoden zusammen verwenden. Die Nmap-Referenz zur Host-Erkennung zeigt Beispiele für diese Ansätze und erklärt, warum sie unterschiedliche Ergebnisse liefern können.
Die Methode ist entscheidend. ARP kann ein lokales Gerät finden, das ICMP ignoriert. Je nach Scanner kann die TCP-Erkennung sowohl eine angenommene Verbindung als auch eine Reset-Antwort von einem geschlossenen Port auswerten. Ein Gerät kann in der Client-Liste des Routers stehen, weil es vor Kurzem einen DHCP-Lease erhalten hat, und im Ruhemodus trotzdem auf keine Abfrage antworten. Diese Beobachtungen sagen jeweils etwas anderes aus. Halte deshalb fest, was tatsächlich geprüft wurde.
Wenn der Scanner die ausgewählten Methoden anzeigt, wiederhole den Scan vom selben Computer und Netzwerk aus, sofern du dazu berechtigt bist, und vergleiche die Ergebnisse. Ändere nicht mehrere Einstellungen gleichzeitig. Ein weiterer Durchlauf kann zeigen, dass das Ergebnis nur vorübergehend war. Er klärt aber nicht, warum das Gerät nicht geantwortet hat. Notiere Uhrzeit und Methode zusammen mit dem Ergebnis, damit du diese Angaben bei späteren Vergleichen zur Hand hast.
Firewall und Netzwerkregeln prüfen, ohne den Schutz zu schwächen
Die Firewall des Betriebssystems kann die normalen Dienste eines Geräts zulassen und gleichzeitig unaufgefordert eingehenden Datenverkehr einschließlich ICMP einschränken. Microsoft dokumentiert, wie sich Windows-Firewall-Regeln nach Protokoll, Profil, Adresse und weiteren Bedingungen eingrenzen lassen. Lies die Dokumentation zur Windows-Firewall, bevor du eine Regel änderst.
Prüfe die Richtlinie über den üblichen Verwaltungszugang des Geräts, für den du berechtigt bist, statt die Firewall für einen Scan-Test auszuschalten. Bei einem verwalteten Computer kann die Richtlinie zentral von einem Administrator vorgegeben sein. Dass du dich anmelden kannst, bedeutet nicht automatisch, dass du sie ändern solltest. Bei einem NAS, Drucker oder einer Kamera findest du Angaben zu Netzwerk- und Ruhemodus-Einstellungen in der Dokumentation des Herstellers. Vielleicht gibt es eine Einstellung wie „Auf Ping antworten“. Wenn du sie aktivierst, entscheidest du damit auch, auf welche Anfragen das Gerät von außen reagiert. Für den normalen Betrieb muss sie nicht aktiviert sein.
Prüfe außerdem Router-Funktionen, die Clients voneinander trennen: Gastnetz-Isolation, WLAN-Client-Isolation, VLAN-Regeln, Kindersicherung oder Access-Point-Richtlinien. Wenn du eine Regel findest, die das Ergebnis erklärt, notiere sie. Schalte die Isolation nicht aus, nur damit ein Gerät im Scan auftaucht. Dieser Schutz kann bewusst eingerichtet worden sein.
Ein begrenzter Ablauf zur Fehlersuche
Beginne mit Informationen, die du ohne große Eingriffe prüfen kannst, und gehe dann zu gezielteren Prüfungen über:
- Prüfe Scanzeit, Zielbereich und das Netzwerk, von dem aus der Scan lief.
- Vergleiche die erwartete IP-Adresse und das Netzwerk des Geräts mit den aktuellen Angaben im Router oder Controller. Achte darauf, ob du eine aktuelle Zuordnung oder einen älteren Eintrag vor dir hast.
- Wiederhole dieselbe erlaubte Erkennungsmethode einmal vom selben Ausgangspunkt aus. Lass aus einer lokalen Prüfung keine großflächige Suche werden.
- Wenn du das Gerät verwaltest, prüfe einen normalen Dienst, den es bereitstellen sollte und auf den du bereits zugreifen darfst, etwa seine vorhandene Verwaltungsseite oder eine bekannte Dateifreigabe.
- Prüfe die dokumentierten Einstellungen für Ruhemodus, Firewall und Isolation, bevor du entscheidest, ob eine Konfigurationsänderung sinnvoll ist.
Das Ergebnis kann trotzdem offenbleiben. Auch das ist eine nützliche Information. „Das Gerät war zu diesem Zeitpunkt über seinen normalen Dienst erreichbar, hat aber auf diese Erkennungsmethode nicht geantwortet“ ist genauer, als es als offline einzustufen. Wenn das Gerät für eine kritische Aufgabe gebraucht wird und auch sein normaler Dienst nicht verfügbar ist, halte dich an den Support-Ablauf des Herstellers oder das Verfahren für Störungen, das dein Administrator vorgibt.
DeviceShelf kann dir eine weitere Beobachtung für ein Netzwerk liefern, das du verwaltest. Vergleiche jedes Erkennungsergebnis mit den aktuellen Angaben des Routers und dem Dienst, den das Gerät bereitstellen sollte. Ein fehlender Scan-Eintrag allein belegt weder einen Ausfall noch einen Firewall-Fehler oder ein unbefugt eingebundenes Gerät.
Halte den Prüfumfang klein. Notiere die verwendete Methode, den Netzwerkpfad und den Zeitpunkt. Prüfe anschließend zum Vergleich einen bekannten Dienst, sofern du dazu berechtigt bist. So hast du zu dem rätselhaften leeren Ergebnis eine nachvollziehbare Beobachtung, ohne die Sicherheitseinstellungen des Geräts zu lockern, nur damit der Scan einen Treffer liefert.