Ein Gerät kann ganz normal funktionieren und trotzdem bei einem Scan aus einem anderen Teil deines Heimnetzes fehlen. Das passiert häufig, wenn ein Router mehrere private Subnetze verbindet: Vielleicht nutzt das Haupt-LAN 192.168.1.0/24, während ein Testnetz, VPN, Gastnetz oder das Netz hinter einem weiteren Router 192.168.168.0/24 verwendet. Die Adressen sehen ähnlich aus. Trotzdem sind es getrennte IP-Netze. Ob ein Rechner im einen Netz einen Rechner im anderen erreicht, hängt vom Routing und den Regeln zwischen den Netzen ab. Die gemeinsamen ersten beiden Teile 192.168 sagen nichts über die Erreichbarkeit aus.
Diese Anleitung ist für ein Netzwerk gedacht, das dir gehört oder das du verwalten darfst. Sie zeigt dir, wie du ein einzelnes Gerät in einem gerouteten Subnetz gezielt prüfst, ohne Segmentierung, Firewall-Regeln oder Zugriffskontrollen zu umgehen. Vielleicht musst du nur herausfinden, wo du ansetzen solltest: beim Gerät, bei der Route dorthin oder bei der Methode zur Geräteerkennung.
Anlass war ein echter Supportfall mit einem Haupt-LAN im Bereich 192.168.1.x und einem gerouteten Subnetz im Bereich 192.168.168.x hinter einem Router. Wenn ein Gerät in so einem Aufbau im Scan fehlt, beweist das noch keinen Ausfall.
Genaue Adressen beider Netze
Notiere die Adresse und Präfixlänge des Rechners, von dem aus du prüfst, und des gesuchten Geräts. Bei einem Präfix wie /24 gehören die Adressen von 192.168.1.0 bis 192.168.1.255 zum selben IPv4-Netz. 192.168.168.0/24 ist ein eigenes Netz. Beide liegen in Adressbereichen, die für private Netze reserviert sind. Private Adressen bedeuten aber nicht, dass die Geräte zur selben Broadcast-Domäne gehören. RFC 1918 definiert die privaten IPv4-Bereiche, garantiert aber keine Verbindung zwischen beliebigen privaten Netzen.
Halte vor dem nächsten Scan vier Dinge fest:
- IP-Adresse und Präfix des Rechners, von dem aus du prüfst.
- Erwartete IP-Adresse, Hostname oder DHCP-Reservierung des Geräts.
- Standardgateway des Rechners, von dem aus du prüfst.
- Router, Firewall oder verwalteter Switch zwischen den beiden Netzen.
Identifiziere ein Gerät nicht nur anhand des letzten Teils seiner Adresse. 192.168.1.50 und 192.168.168.50 sind unterschiedliche Adressen. Auch ein bekannter Hostname kann je nach Netz zu einer anderen Adresse aufgelöst werden. Wenn das Gerät DHCP nutzt, prüfe den DHCP-Server für sein Subnetz. Geh nicht davon aus, dass die Geräteliste des Hauptrouters auch Geräte in einem nachgelagerten Netz enthält. Ein DHCP-Lease zeigt dir, welche Adresse zu einem bestimmten Zeitpunkt zugewiesen war. Er ist kein allgemeiner Test der Erreichbarkeit. RFC 2131 beschreibt dieses Modell der zeitlich begrenzten Adressvergabe.
Routing und lokale Geräteerkennung
Viele Methoden zur lokalen Geräteerkennung funktionieren nur in dem Netzwerksegment, aus dem die Anfrage stammt. ARP ordnet zum Beispiel einer IPv4-Adresse eine Adresse auf der Sicherungsschicht im lokalen Netz zu. Router leiten einen ARP-Broadcast nicht ins nächste Subnetz weiter. RFC 826 beschreibt diese lokale Aufgabe von ARP. In einer ARP-Tabelle oder im Ergebnis eines Scanners, der auf lokales ARP setzt, kann deshalb ein Gerät fehlen, das über einen Router erreichbar ist.
Das bedeutet nicht automatisch, dass der Scanner fehlerhaft oder das Gerät offline ist. Bei einer Prüfung über einen Router wird normaler IP-Verkehr an das Gateway geschickt. Dafür müssen die nötigen Routen in den jeweiligen Richtungen vorhanden sein und die Regeln den Verkehr erlauben. Ein Gastnetz kann absichtlich Internetzugang erlauben und zugleich den Zugriff auf das Haupt-LAN sperren. Ein Test-VLAN kann Zugriffe ausschließlich von einem Verwaltungsrechner aus erlauben. Ein nachgelagerter Router für den Heimgebrauch kann NAT (Netzwerkadressübersetzung) nutzen und eingehende Verbindungen von der vorgelagerten Seite ablehnen.
Kläre jeweils eine konkrete Frage:
- Kann der prüfende Rechner über sein Gateway Daten ins zweite Netz schicken?
- Gibt es eine funktionierende Rückroute, und lassen die geltenden Firewall-Regeln Antworten zu?
- Bietet das Gerät einen regulären Dienst an, den du nutzen darfst und der über diesen Pfad antworten sollte?
- Ist das Tool zur Geräteerkennung so eingestellt, dass es den entfernten Adressbereich prüft, oder nur das direkt angeschlossene LAN?
Diese Antworten sagen dir mehr als eine lange Liste von Geräten, die gerade lokal sichtbar sind.
Routenprüfung vor Änderungen am Scan
Sieh dir zuerst die Routingtabelle des prüfenden Rechners und die Konfiguration der beteiligten Router an. Ermittle, welche Route für die Zieladresse verwendet wird – das kann auch die Standardroute sein – und notiere den nächsten Hop. Ein leeres Scan-Ergebnis ist kein Grund, eine statische Route hinzuzufügen. Eine falsche Route kann Daten an einen unbeteiligten Rechner schicken. Gerade bei VPNs und virtuellen Maschinen kommen mehrfach verwendete private Adressbereiche häufig vor. Raten ist deshalb riskant.
Führe anschließend einen einfachen Test durch, für den du bereits berechtigt bist. Eine Hostnamenauflösung zeigt, auf welche Adresse ein Name verweist. Eine vorhandene HTTPS-Verwaltungsseite, eine SSH-Sitzung, eine Dateifreigabe oder eine Verbindung über eine Anwendung kann zeigen, ob ein bestimmter Dienst antwortet. ICMP Echo liefert einen weiteren Anhaltspunkt, ist aber kein universeller Funktionstest: Ein Gerät oder eine Firewall kann solche Anfragen ablehnen, während ein Dienst, auf den du zugreifen darfst, weiterhin funktioniert. Scan-Tools dokumentieren verschiedene Methoden zur Host-Erkennung, weil Rechner und Netze auf unterschiedliche Prüfanfragen reagieren. Die Nmap-Referenz zur Host-Erkennung beschreibt Beispiele und deren Grenzen.
Teste genau das, was du wissen musst. Wenn du prüfen willst, ob die Weboberfläche eines NAS von einem Verwaltungsrechner aus noch erreichbar ist, rufe diese Oberfläche mit deiner bestehenden Zugriffsberechtigung auf. Das ist aussagekräftiger, als das NAS für ausgefallen zu erklären, weil es auf eine Geräteerkennung per Broadcast nicht reagiert hat. Bei einer Home-Assistant-Entität prüfst du die konfigurierte Adresse und das Protokoll der Integration unabhängig vom Scan-Ergebnis.
Zugriffsregeln und Verkehrsrichtung
Wenn eine direkte, erlaubte Prüfung fehlschlägt, richte nicht sofort eine weitreichende Freigabe zwischen den Netzen ein. Finde heraus, welches Gerät die Zugriffsregeln zwischen ihnen durchsetzt, und suche nach einem Protokolleintrag oder einer ausdrücklichen Regel für den betreffenden Verkehr. Regeln können je nach Richtung unterschiedlich sein. Das Haupt-LAN darf vielleicht Verbindungen zu einem IoT-VLAN aufbauen, während Verbindungen in umgekehrter Richtung gesperrt sind. Ein nachgelagerter Router kann seine Clients außerdem vor einem vorgelagerten LAN verbergen.
Prüfe die Host-Firewall getrennt von der Router-Firewall. Selbst bei korrekter Route kann das Betriebssystem des Zielgeräts den Zugriff auf einen Dienst oder eine ICMP-Anfrage ablehnen. Eine Änderung an einer Windows-Firewall-Regel behebt wiederum keine fehlende Rückroute auf einem Router. Microsoft beschreibt die Windows-Firewall als hostbasierte Kontrolle des Netzwerkverkehrs. Berücksichtige bei der Prüfung ihrer Regeln das Netzwerkprofil und den konkreten Dienst. Dokumentation zur Windows-Firewall
Vor einer Änderung solltest du sagen können, auf welcher Ebene sie ansetzt. Ändere immer nur eine Sache und achte darauf, dass du sie rückgängig machen kannst. Wenn du etwa einem berechtigten Verwaltungsrechner vorübergehend Zugriff auf einen dokumentierten Dienst erlaubst, erfährst du mehr, als wenn du VLANs zusammenlegst, eine Firewall deaktivierst und beide Router neu startest. Notiere Zeitpunkt, Quelladresse, Zieladresse, Protokoll oder Dienst und Ergebnis. Sobald du das Ergebnis festgehalten hast, nimm die vorübergehende Testfreigabe wieder zurück.
Gezielte Scan-Konfiguration
Wenn du einen Scanner verwendest, prüfe, ob sein Zielbereich dem gerouteten Subnetz entspricht. Er muss außerdem auf einem Rechner laufen, der dieses Subnetz erreichen darf und soll. Ein Scan des lokalen LANs findet nicht automatisch alle Geräte hinter einem Router. Wenn du einen entfernten Bereich hinzufügst, bevor du die Route geprüft hast, bekommst du möglicherweise schwer einzuordnende Zeitüberschreitungen und Ergebnisse voller Adressen, die von diesem Standort aus nie erreichbar waren.
Für eine laufende Inventarisierung beschriftest du jeden Bereich nach seinem Zweck: Haupt-LAN, Server-VLAN, Testnetz oder Gastnetz. Halte fest, ob der Scan von einem Rechner im jeweiligen Segment ausgeht oder über einen Router läuft. Fehlt ein Gerät bei einem späteren Scan, kannst du gezielt prüfen: Fehlt es in seinem eigenen Segment, ist es vom Überwachungsrechner aus nicht erreichbar oder wird der Zugriff durch die vorgesehenen Regeln ausgeschlossen?
DeviceShelf kann dir einen weiteren Anhaltspunkt zu Geräten in einem von dir verwalteten Netz liefern. Ordne das Ergebnis zusammen mit dem konfigurierten Scan-Bereich, der Route und dem Prüfzeitpunkt ein. Es kann nicht beweisen, dass ein entferntes Gerät offline oder eine Firewall-Regel korrekt ist.
Schlussfolgerung auf Basis der Prüfergebnisse
Halte nach den Prüfungen in einem Satz fest, was die Ergebnisse tatsächlich zeigen. Zum Beispiel: „Die Verwaltungsseite des Geräts war zu diesem Zeitpunkt aus dem Verwaltungs-LAN erreichbar, aber die lokale ARP-Erkennung kam nicht über den Router hinaus.“ Oder: „Für das entfernte Präfix fehlte eine Rückroute, deshalb ließ sich die Verfügbarkeit des Geräts mit dieser Prüfung nicht feststellen.“ Keine dieser Schlussfolgerungen erfordert einen umfassenden Umbau des Netzes.
Bewahre diese Notiz für die nächste Störung auf. Ein geroutetes Subnetz ist oft bewusst vom Haupt-LAN getrennt und nicht einfach ein fehlerhafter Teil davon. Sobald du Adressen, Route, Zugriffsregeln und die genaue Prüfmethode geklärt hast, kannst du entscheiden, ob du einen zulässigen Scan-Bereich anpasst, eine Konfiguration korrigierst oder eine gewollte Trennung beibehältst.