server 노드와 client 노드로 제공되는 제품이 일을 안한다고 한다. client 가 보내는 api 를 server 에서 특정 조건이 충족되면 받지를 못한다고 한다. 참 여러가지 상황이 있었는데 이것들을 대응하면서 생긴 생각을 적어보도록 하겠다.
버전 확인
auto-update 가 제공이 되는 제품이라면 문제가 되지 않겠지만, 수동 업데이트를 해야하는 상황이라면 두가지 node 가 모두 최신 버전으로 깔려 있는지부터 확인을 해야한다. 여기서 포인트는 '두가지 모두' 이다. server 에 문제가 있어서 표기가 안되는거 같지만 그거는 너의 생각일 뿐이고 실상 문제는 client 에 있을 확률도 아주 높다. 따라서 양쪽 노드 모두가 최신 버전임을 확인하는 것을 맨 첫번째로 가져가야 한다.
패킷 캡쳐
자 양쪽 노드가 최신 버전임을 확인한다면은 이제는 네트워크가 문제일 확률에 대해서 생각을 해봐야 한다. 각 기업의 망구성은 아주아주 복잡하고 server-client 사이에 얼마나 많은 스위치와 방화벽 게이트웨이가 있을지 짐작도 안되는 환경일 수 있다. 그래서 망 구성의 문제, 방화벽의 문제로 인해서 우리 제품의 패킷이 아예 도착을 안했을 확률도 높다. 따라서 client 의 패킷이 server 에 들어왔는지를 확인해주면 방화벽 문제인지 아닌지가 확인된다. 패킷 캡쳐는 wireshark 로 ip.src==<client IP> 를 server 쪽에서 캡쳐를 해주면은 된다. 안잡힌다? 그러면은 이 사람들의 방화벽 정책의 문제 망 구성의 문제. 잡힌다? 그러면 우리 제품이 어딘가 하자가 있어서 생기는 문제. wireshark 는 윈도우일때 진행해주면 되고 linux 일때는 tcpdump 를 사용해주면 된다.
네트워크 CMD
경우에 따라서 패킷캡쳐 프로그램 설치를 못하게 할 수 있다. 그렇다면은 tracert(linux 일경우 traceroute) 를 해주거나 curl <ip:port> 를 쏴주면 된다. tracert는 client 에서 server 로 어떤 게이트웨이를 통과해 가는지를 기록해주는 명령어이다. 만일 client 에서 server 측 IP 가 잡힌다? 그러면은 패킷은 잘 가고 있는 것이다. 안나오고 중간에 잘린다? 그러면은 방화벽이 중간에 막거나 어디선가 스위치나 허브가 끊겨 있어서 생기는 문제이다. curl 도 비슷한데 client 에서 <server IP:PORT> 로 보낸 요청이 잘 돌아 오는지를 확인할 수 있도록 해주는 아이다.
여기까지가 네트워크 에러를 대응하는 방법이었다. 이걸 모두 통과해 우리쪽 문제라는게 밝혀진다면? 그 다음은 QA 편에서 이어서 얘기해보도록 하겠다.
