요즘 퇴근 후, ChatGPT하고 노느라고 집에서 PC 사용이 부쩍 늘어나, 인터넷이 간헐적으로 끊기는 상태를 즉각 느낄수 있었다. 예전에 사용한 무선 공유기 ipTIME은 이럴 때마다 재부팅 한번으로 해결되긴 했는데, 천장형 AP는 살펴보니 전원공급 어댑터 연결이 없는 것이 아닌가?
그래서 신발장 네트워크 단자함을 열어 일단 라우터를 재부팅하였으나, 여전히 천장형 무선 공유기 AP1100은 동작하지 않았다. 여기서부터 오늘 사건의 시작이었다. 여전히 AP가 동작하지 않아 디오넷 AP1100 모델 전면부에 리셋 버튼을 실행하였는데, 예상치 못한 결과가 발생하였다.
이상한 초기화
리셋으로 인해 기존에 설정한 SSID가 삭제된 것은 예상범위였고, WIFI_2G / WIFI_5G 추가되고 비밀번호 없이 사용이 가능한 AP였다. 그런데 문제는 AP에 연결한 디바이스가 첨부한 이미지와 같이 192.168.200.xxx 아이피로 할당 받은 것이 아니라 27.116.167.xxx로 할당 받은 것이 아닌가...?
이것도 중요하지 않았다. 파일공유나 스트리밍을 사용할 일이 거의 없기 때문에 내부아이피를 쓰지 않아도 상관없는데, AP SSID와 패스워드를 설정 못하는 것은 이해가 되지 않았다. 그리고 집 모든 가전제품이 기존 사용했던 SSID로 설정되어 있기 때문에 모든 가전제품의 네트워크 연결을 다시하는 것도 상당히 귀찮은 일이었고, 무엇보다도 AP에 보안인증이 걸리지 않다는 것이 용납되지 않았다.
그리고 나는 문서 읽는 것이 귀찮아 ChatGPT에게 AP 메뉴얼 2개를 전달한 것으로 인해 오늘 블로그에 올린 계기를 만들게 되었다. 맥미니에선 WIFI_2G에서 아이피 할당을 받지 못해 급한대로 윈도우 노트북에 WIFI_2G SSID로 연결하였는데 AP DHCP 서버에서 할당받은 아이피도 이상하고 여전히 인터넷도 불안한 상태였다.
잘못된 추론의 시작
AP1100 문서에는 관리자 주소가 192.168.200.254로 적혀 있었고, 동작 모드에는 게이트웨이 설정이 있었다. 제품 자료에는 NAT, DHCP Server/Client, HTTP Web Management 기능도 명시돼 있었다. 현재 현상과 너무 잘 맞았다. 정상 상태에서는 상위 라우터에서 AP1100으로 연결되고, AP1100이 NAT와 DHCP를 통해 Wi-Fi 단말에 192.168.200.xxx를 할당한다. 그런데 RESET 이후 Windows가 상위 네트워크의 27.116.167.xxx를 직접 받는다. 나와 ChatGPT는 비슷한 결론에 도달했다.
공장초기화 이후 NAT가 풀리고 AP가 브리지처럼 동작하는 것 아닐까?
가설을 검증할수록
먼저 Windows 노트북을 WiFi_2G에 연결한 상태에서 192.168.200.xxx 대역의 Secondary IP를 추가하려고 했다. AP의 관리 인터페이스가 그대로 살아 있다면 같은 무선 인터페이스에서 접근할 수 있지 않을까 생각했다. 결과는 실패였다. 오히려 Windows 네트워크 설정이 꼬여 다시 DHCP 설정을 복구해야 했다.
여기서 멈추지 않았다. 그렇다면 공장초기화된 AP1100 자신도 상위 DHCP에서 27.116.167.xxx 주소를 하나 받은 것은 아닐까? 같은 대역을 훑고 ARP 테이블을 확인했다. 그러다 27.116.167.14라는 장비를 찾았다. MAC 주소가 AP1100의 무선 BSSID와 매우 비슷했다. Ping도 정상적으로 응답했다.
찾은 것 같은데...?
관리 웹 포트를 확인했다. 80번 포트가 열려 있었다. 제품 자료에는 실제로 HTTP Web Management 기능이 있었다. 우리 가설은 점점 더 완벽해 보였다. 그런데 브라우저에서는 페이지가 열리지 않았다. 포트를 더 확인했다. 443, 8080, 8443, 8000 등 흔히 사용하는 관리 포트를 확인했지만 80번만 열려 있었다.
이번에는 curl로 직접 HTTP 요청을 보냈다. TCP 연결은 성공했지만 HTTP 응답은 0 byte였다. /login.htm도 직접 호출했다. 안 됐다. 오래된 임베디드 웹서버라 HTTP/1.1을 제대로 처리하지 못하는 것 아닐까 싶어 HTTP/1.0으로도 요청했다. 그래도 안 됐다. 원래 관리 주소를 Host header로 요구하는 것은 아닐까 싶어 Host: 192.168.200.254까지 넣어봤다. 여전히 안 됐다. 여기서 멈췄어야 했다....
우리는 오히려 가설을 더 정교하게 만들었다.
WAN 쪽에서는 TCP 80만 열어두고 실제 Web Management는 LAN 쪽에서만 허용하는 구조 아닐까...?
그렇다면 AP를 상위 네트워크와 분리해 관리 인터페이스에 직접 붙어야 하는 것 아닐까..? 그러다 한 가지 의문이 생겼다. 천장에 붙어 있는 AP1100에는 왜 전원선이 없을까? 케이블을 따라가고 장비 구조를 확인하면서 AP1100이 Ethernet 케이블을 통해 데이터와 전원을 함께 공급받는 PoE 방식이라는 것도 알게 됐다. AP1100 뒷면을 다시 보니 RJ45 포트 하나뿐이었다. 제품 라벨에는 관리자 주소 192.168.200.254도 적혀 있었다.
이제는 PoE 인젝터를 이용해 노트북과 AP1100을 1:1로 격리하면 관리페이지에 들어갈 수 있지 않을까 하는 방법까지 검토했다. 우리는 집 네트워크 구조를 거의 다 알아냈다. 문제만 못 고쳤다.
상황을 더 복잡하게 만든 사건도 있었다. AP 문제를 분석하던 중 유선으로 연결된 Mac mini의 인터넷까지 갑자기 불안정해졌다. 상위 게이트웨이까지는 Ping이 되는데 외부로 나가지 못했다. 잠시 살아났다가 다시 끊겼다. Google의 8.8.8.8은 장시간 측정에서 높은 packet loss를 보이다가 100% loss가 됐고, Cloudflare의 1.1.1.1은 한동안 2~5ms로 정상 응답하다 갑자기 연속 timeout이 발생했다. 어떤 사이트는 잘 열리고, 어떤 사이트는 로딩이 매우 느렸다.
처음 AP가 이상하다고 생각했던 원인 자체가 사실은 인터넷 회선 쪽의 간헐 장애였을 가능성이 커졌다. AP1100 공장초기화 문제와 실제 외부망 장애가 같은 시간대에 겹치면서 상황은 완전히 미궁으로 들어갔다.
제품을 보내주세요
결국 다음 날 오전 반차를 쓰고 디오넷 고객센터에 전화했다. 증상을 설명했다. Factory Reset 후 기본 SSID인 WiFi_2G, WiFi_5G가 나타나지만 NAT가 복구되지 않은 것처럼 상위 네트워크의 27.116.167.xxx를 직접 받고, 관리자 페이지에도 접근할 수 없다고 했다.
담당자의 설명은 의외로 단순했다. 원칙적으로 공장초기화가 정상적으로 완료되면 NAT까지 리커버리되어야 하는데, 현재 상태는 정상적인 리커버리가 되지 않고 브리지 상태 비슷하게 올라온 것 같다는 취지였다. 그리고 제품을 택배로 보내면 펌웨어를 다시 넣어 복구해주겠다고 했다. 여기서 한 가지를 다시 물었다.
특정 상황에서 공장초기화가 제대로 안 된 거라면 RESET을 다시 하면 정상적으로 될 수도 있지 않나요?
가능할 수도 있지만 확실히 모르겠다는 답을 들었다. 제품을 보내기 전에 마지막으로 한 번만 더 해보기로 했다.
가장 싼 검증
이번에는 조건을 바꿨다. 공장초기화 후 생성되는 WiFi_2G, WiFi_5G는 비밀번호가 없는 Open SSID다. 첫 번째 초기화 때 주변 디바이스들이 이 SSID에 접속을 시도하면서 NAT/Gateway 복구 과정에 영향을 줬을 가능성이 문득 떠올랐다. 정확한 원인은 확인할 수 없다. 이걸 원인이라고 단정하면 확증편향에 대한 글을 쓰면서 또 다른 확증편향으로 끝내는 셈이다.
다만 이번에는 연결된 모든 디바이스에서 WiFi_2G, WiFi_5G 연결 정보를 지웠다. 주변 장비가 자동으로 접속하지 못하게 한 뒤 다시 RESET을 실행했다. 그리고 아무것도 하지 않고 약 10분을 기다렸고... AP 연결후 할당받은 아이피를 확인하니 192.168.200.xxx였다. 그리고 당연히 관리자 페이진 192.168.200.254에 접속이 되었다. 즉 NAT가 정상적으로 복구가 된 것이다.
난 ChatGPT에 농간에 놀아난 것인가...?
함께 도달한 결론
돌이켜보면 우리가 확인한 사실 상당수는 실제로 맞았다. 27.116.167.xxx를 받은 것도 사실이었다. 관리자 페이지가 열리지 않은 것도 사실이었다. AP와 연관돼 보이는 MAC 주소를 찾은 것도 사실이었고, 80번 포트도 실제로 열려 있었다. 제조사 문서에 NAT, DHCP, HTTP Web Management가 적혀 있던 것도 사실이었다. 우리가 근거 없이 상상한 것은 아니었고, 문제는 그 모든 사실을 하나의 전제 위에서 해석했다는 점이었다.
첫 번째 Factory Reset은 정상적으로 완료됐다.
이 전제가 틀렸는데, 나는 관찰 결과를 ChatGPT에게 전달했고, ChatGPT는 그 결과를 설명하는 기술적인 가설을 만들었다. 다시 나는 그 가설을 검증했고, 실제로 그럴듯한 증거가 계속 나왔다. 그러면 ChatGPT는 더 정교한 다음 가설을 만들었다. 우리는 서로를 말리지 않았다.
오히려 서로에게 다음 삽을 건넸다. 이번 경험은 ChatGPT가 혼자 만들어낸 환각이라고 부르기에도 조금 다르다. 우리는 없는 사실을 본 것이 아니라, 실제 사실들을 우리가 세운 전제에 맞춰 연결했다. 나와 ChatGPT가 함께 만든 확증편향에 가까웠다.
그래도 배운 것
이 모든 삽질이 완전히 헛된 것은 아니었다. 천장에 붙은 AP1100에 왜 별도의 전원선이 없는지 알게 됐다. RJ45 케이블 하나로 데이터와 전원을 함께 공급하는 PoE(Power over Ethernet)라는 방식이었다. AP1100 역시 IEEE 802.3at PoE+를 지원하는 제품이었다.
덕분에 PoE가 무엇인지는 확실히 배웠다. 굳이 이렇게까지 배울 필요가 있었는지는 모르겠다.