네트워크 방화벽으로인한 라우터(AP) 통신불가 이슈 -OPENWRT

 

IoT 기반 기술을 개발하던 중 클라우드와 라우터 간 통신이 불가능한 문제와 부딪혔습니다

내부망으로 해당 포트로 정상적으로 통신이 가능한 부분을 확인하였고 이후 외부 클라우드에서 요청을 보내도록 하여

라우터가 응답을 하도록 구성했는데 500 또는 404에러는 커녕 아무 반응이 없는 것 무엇이 문제일까? 방화벽을 내가 잊었나? 생각하고 다시 해당포트의 방화벽을 개방! 그래도 무반응! 그래서 서버가 동작하는 OS 방화벽 비활성화하고 OPENWRT의 포트포워딩

설정이 잘 되어있는지 확인했으나 네트워크 설정은 모두 완벽 그 자체인데 안되면 드는 생각

 

"상위 네트워크에서 막고 있는 게 아닌가?"

회사는 건물 운영사무실로부터 고정아이피를 할당받아 사용 중이었는데 ISP에서 직접 내려오는 회선이 아니니 충분히 가능성 이 있다고 판단하여 우선 패킷을 추적해 보기로 했습니다 "sudo tcpdump -i any port 8000 -n"를 통해 8000번으로 들어오는 네트워크 패킷을 확인해 봤는데 아무 패킷도 들어오지 않고 있었습니다 ssh 22번 포트로는 정상적으로 패킷을 수신하는데

 

8000번만 안 들어온다?.. 이상합니다

그래서 집에서 개인적으로 운영하고 있는 리눅스 서버로 접속하여 같은 환경을 구성하고 클라우드에서 요청을 보내도록 해보니 매우 우 잘되는 것!

 

원인은 둘 중 하나였습니다 이전 라우터를 개발하면서 방화벽 관련 설정을 많이 건드렸는데 나름 설정한 걸 초기화한다고 이것저것 설정을 했으나 이 설정이 꼬여서 WAN으로 들어오지 못하고 있는 것(이것도 패킷을 추적하면 떠야 하지 않나?.. 싶기도 했습니다) 하지만 아직 네트워크에 대해 심도 있게 알지 못했기 때문에 추정이었습니다

 

두 번째는 상위 네트워크인 건물 L4와 같은 장치의 방화벽이 막고 있는 것 유력하다 생각했습니다 GPT도 이 의견이 더 확실하다고 하였으니

 

결론은 상위 네트워크에서 클라우드에서 요청을 보내려는 포트가 차단되어 있는 상태였고 그래서 WAN으로 받지를 못해 패킷조차 출력되지 않는 문제였습니다 OS에서 패킷을 확인해 보는 게 최후의 보루인데 이 패킷조차 안 나온다는 것은 상위 네트워크에 문제가 있다는 것으로 앞으로 네트워크를 구성할 때 문제가 발생하면 확신이 생기는 문제에 대해 좀 더 자신감 있게 부딪혀 보자는 생각을 갖게 된 계기가 되었습니다