네트워크계의 CCTV - wireshark 로 network trouble shooting 한방에 끝내기

 

youtube 영상

화면조작이 많기에 영상버전 시청을 권장합니다.

https://youtu.be/v7vAoqGXe8I

 

https://youtu.be/H1SdVrBKccw

네트워크 관련 흔히 접하는 문제들

"TCP 3 way handshake 는 3개의 패킷을 주고 받으면서 통신을 셋업한다" 와 같은 말이나 그림을 보면 적당히 이해는 가지만 완전히 내것으로 만들기가 어렵습니다. 패킷은 눈에 보이지 않으니까요.

=> 아닙니다! #wireshark 라는 툴을 이용하면 오고 가는 패킷들을 눈으로 볼 수 있습니다.

​

"양쪽에서 통신을 하다가 몇분 지나면 연결이 끊어집니다. client, server 중 어느쪽이 연결 끊기를 시도한건지 알수가 없네요"

=> wireshark 를 이용하면 연결 끊어진 시점에 어떤 패킷을 주고 받았는지를 볼 수 있어 범인(?)을 잡을 수 있습니다.

​

"HTTP 헤더에 값을 세팅해서 보냈는데 상대방이 헤더에 그 값이 없다고 합니다. 누구 말이 맞는거죠?"

=> 서버나 클라이언트 로그는 로깅시점과 프로그램 자체 버그로 인해 100% 신뢰할 수 없기에 wireshark 로 실제 보낸 패킷 혹은 실제 받은 패킷을 잡아서 확인하면 됩니다.

​

IT 관련 일을 하다보면 위와 같은 케이스를 종종 만나게 됩니다. 만약 여러분이 wireshark 를 몰랐다면 문제해결에 많은 시간이 소요되겠으나 이글을 통해 wireshark 를 알게된 순간 가장 명확한 증거인 패킷캡쳐를 통해 네트워크에 대한 이해도 향상, 장애/오류시의 원인 분석을 쉽게 할 수 있을 거라 확신합니다.

​

패킷캡쳐툴

#wireshark 라는 툴을 이용하면 윈도우즈 에서 쉽게 오고 가는 패킷을 캡쳐하고 분석할 수 있습니다. 리눅스에서는 #tcpdump 라는 툴을 이용해서 패킷 캡쳐를 할 수 있습니다. tcpdump 로 캡쳐된 파일을 만든 후 이를 wireshark 에서 열어서 GUI 화면에서 좀 더 편하게 분석도 할 수 있습니다. 

wireshark 설치방법 자체는 인터넷에 널려있으므로 아래 링크로 대체합니다. 

https://200301.tistory.com/22

[Wireshark(와이어샤크)] 설치방법

요약하면

https://www.wireshark.org/  이곳에서 다운로드 한 후 , PC 에 설치, 설치시 기본 설정된 옵션 건드리지 말고 계속 ok, next 를 누르면 설치완료 입니다.​

 

사용법 - 기본

설치 완료된 wireshark 를 실행하면 아래와 같은 화면이 나옵니다. 저는 PC에 이것저것 설치한게 많아서 네트워크 인터페이스가 많이 보이는데, 각자 PC 환경에 따라 다릅니다. wifi 도 된다면 "무선네트워크" 혹은 "wifi" 와 같은 네트워크 인터페이스도 보일겁니다.

wireshark만 실행하고 따로 웹서핑을 하지 않지 않아도 기본적으로 주고 받는 패킷들이 있습니다. 그래서 아래에 심장박동같은 그래프가 실시간으로 변화됩니다.  저는 "이더넷" 으로 적힌게 실제 인터페이스이므로 이걸 더블 클릭합니다.

아래처럼 실시간으로 현재까지 주고 받은 패킷들이 모두 보여집니다. 그대로 두면 계속 패킷을 잡아서 언젠가는 PC가 버벅거리므로 빨간색 네모를 눌러 정지시킵니다.

UI가 잘 되어 있어서 쉽게 내용을 알 수 있습니다. No. 는 패킷 캡쳐한 순서를 표시하며, Time 은 캡쳐 시작한 시점으로부터 얼마후에 잡힌 패킷인지, source, Destination 은 IP 주소를 나타냅니다. 나머지도 네트워크 기본지식이 있으며 금방 이해됩니다.

 

지금 캡쳐한 것을 나중에도 보고 싶을수 있고 다른 사람에게 공유하고 싶을 수 있습니다.

파일로 저장하면 되겠군요. 아래처럼 File 메뉴 하단에 open 과 save, save as 가 있으니 이걸 이용합니다.

 

 

사용법 - 응용

필터링

특정 서버와 주고 받은 패킷만 보고 싶을때가 많습니다. 그런데 그외 패킷들도 모두 다 캡쳐가 됩니다. 내가 원하는 IP 나 PORT 등으로 필터링해서 보고 싶겠지요.

 

아래처럼 책갈피 처럼 생긴아이콘을 클릭하면 필터링 옵션 샘플들이 보입니다. 눈으로 읽어보면 대충 이해가 갑니다.

 

주로 ip address 정도만으로 필터링해도 거의 다 되기에 아래처럼 입력하는걸 추천합니다. 아래 예시에서 실제 ip주소는 여러분이 원하는 값을 넣어야 합니다. 

 

 

ip.addr == 192.168.0.2

 

​TCP 세션/스트림 

TCP의 경우 3 way handshake 로 세션/스트림을 열고,  4 way handshake 로 세션/스트림을 닫습니다.

세션, 스트림은 하나의 TCP 커넥션으로 묶인 것들.. 이라고 생각하면 됩니다. 

HTTP 를 비롯해서 대부분 TCP 를 사용하기에 하나의 세션/스트림에서 보낸 패킷들만 필터링 하고 싶을수 있습니다.

아래처럼 protocol 이 TCP 혹은 TCP 기반으로 HTTP, FTP 등의 패킷에 대해 마우크 우 클릭하면 상세 메뉴가 나오고 Follow > TCP Stream 을 클릭합니다.

 

아래처럼 해당 스트림의 패킷들만 모아서 보여주고, 추가적으로 실제 주고 받은 payload 들도 보여줍니다. 빨간색이 PC 에서 나간 payload,  파란색은 PC로 들어온 payload 를 말합니다. payload 란 TCP 헤더와 같이 헤더 정보를 제외한 payload 를 뜻합니다. 

 

TCP 스트림만 보고 싶을 경우, 아래처럼 tcp.stream eq 3 처럼 숫자 부분을 하나씩 올리거나 내린 후 엔터를 칩니다.

그러면 해당 순서에 매칭되는 패킷들이 보여집니다. 

 

단일 패킷 상세 정보

특정 패킷을 클릭하면 화면 하단에 아래처럼 각 Layer 별로 상세 정보가 보입니다.

실전 디버깅

몇 가지 케이스에 대해 실전 디버깅 방법을 알려드립니다.

SSL 오류 찾아내기

case: SSL 통신을 하는데 연결 오류가 납니다. 

예상원인: client, server 의 SSL 버전 등이 너무 달라서 오류,  잘못된 서버 인증서로 인한 오류

테스트를 위해 잘못된 SSL 지원되는 서버가 필요한데, https://badssl.com/  라는 사이트를 이용하면 쉽게 테스트가 가능합니다.

아래처럼 여러 오류 종류를 선택할 수 있는데, 저는 인증서 기간 만료를 선택하겠습니다. 

클릭하면 아래처럼 크롬에서는 잘못된 인증서 라는 걸 알아내서 경고 문구를 보여줍니다.

크롬 브라우저 자체적으로 SSL 오류에 대한 예외처리가 잘 되어 있어서 위와 같은 페이지가 나오는것이지만 여러분의 app 은 예외처리가 잘 되어 있지 않을수도 있고, 예외처리 로직상의 버그로 인해 그걸 그대로 믿기가 어려울수도 있습니다. 따라서 패킷 캡쳐로 증거를 잡아봅시다.

아래처럼 파란색 상어 지느러미 모양을 클릭하면 새로운 패킷 캡쳐가 시작됩니다.

패킷 캡쳐 시작 후 위 오류난 웹페이지를 refresh 해서 관련 패킷을 주고 받도록 재현합니다.

refresh가 완료된 후 wireshark 의 stop 버튼을 눌러서 정지시켜 줍니다. ( 패킷캡쳐된게 적어야 찾기 쉬우므로)

위에서 배운 기술을 바탕으로 아래처럼 SSL 통신 스트림을 찾아낸 후 패킷들을 유심히 살펴보면 Alert 라는 게 보이고 상세 정보를 보면 Certificate Unknown 이라고 오류 메시지를 보여줍니다. 즉 인증서 오류 가 확실해 졌습니다.

HTTP payload 확인

case: rest api 서버에서 HTTP payload 로 아래처럼 name, age 를 key 로 가진 json 을 보낸다고 합시다.

{
  "name": "AA",
  "age": 12
}

그런데 client 에서 json 을 받아보니 age 부분의 value가 숫자가 아닌 "12" 와 같은 문자열로 수신된다고 합시다. 서버 담당자에게 이렇게 말했더니 "서버 로그에는 숫자로 잘 나간다. " 라면서 신경을 쓰지 않는다고 합시다. 클라이언트 로그에는 문자열로 찍히고 있는데도요. 이렇게 양단의 로그메시지가 서로 다르면 난감합니다. 서버단 문제라면,  아마도 서버측 로그찍고나서 payload 를 어딘가에서 수정한 후 전송을 했을 겁니다. wireshark 로 증거를 잡아봅시다.

http://jsonplaceholder.typicode.com/  이 사이트는 rest api 테스트용 서버로 많이들 사용하고 있으니 이걸 사용해봅시다.

 

http://jsonplaceholder.typicode.com/posts/1

브라우저에서 위 url 로 들어가면 아래처럼 json 응답을 받을 수 있습니다. 

패킷 캡쳐를 통해 위 http payload 를 확인해보도록 해봅시다. 

주의: 위 사이트는 https 로도 접속할수 있으나 암호화때문에 테스트가 어렵습니다. 또한 크롬 브라우저로 테스트하면 브라우저설정값에 의해 payload 가 binary 로 전송되므로 , #curl  을 통해 테스트를 합니다. 

wireshark 캡쳐 시작버튼을 누른 후 cmd 창에서 아래처럼 요청을 보냅니다. ( posts 뒤의 숫자 7은 임의의 값이니 다른걸로 변경해도 됩니다. )

curl http://jsonplaceholder.typicode.com/posts/7

이제 wireshark 캡쳐 중지를 누른 후 해당 패킷을 찾아서 내용을 보면 payload 부분을 확인할 수 있습니다. 가장 확실한 증거가 잡혔으니 이걸로 서버, 클라이언트 중 어느쪽 문제인지 확실히 알 수 있으며, 소모적인 논쟁을 피할 수 있습니다.

방화벽 or 서비스 하지 않는 요청

방화벽에 의해 막혀있는 경우, 혹은 서비스 하지 않는 포트로 요청을 보낸 경우 통신 오류가 나게 됩니다.

TCP 3 way handshake 조차 실패한건지, 아니면 TCP 연결은 성공했으나 그 이후 응답이 없는건지 명확히 할 필요가 있습니다. 테스트를 위해 아래처럼 curl 로 8888 포트로 요청을 보내 봅니다. 

C:\Users\second>curl http://jsonplaceholder.typicode.com:8888

8888 포트로는 서비스를 하지 않는 서버이므로, 3 way handshake 조차 이루어지지 않을 겁니다. 

패킷 캡쳐를 보면 아래처럼 처음에 SYN flag 가 설정된 TCP 패킷을 보낸 이후 아무런 응답이 없어서

1초 지난 후 재요청, 이후 2초 지난 후(처음 패킷 보낸 시간기준으로는 3초 지난 후 ) 재요청 하는걸 알 수 있습니다. 

이건 방화벽 문제거나 8888 포트번호로 보내면 안되는걸 알 수 있습니다. 또한 브라우저는 응답이 없으면 여러번 재요청 패킷을 보내는 방식으로 동작하는것도 덤으로 알게 되었습니다.

 

제약사항

완전 좋은 것처럼 제가 말을 했으나 제약사항이 있습니다. 바로 암호화된 패킷은 암호화된 알수 없는 payload 만 보이기에 TCP 까지의 정보만 의미있고 SSL(TLS) 윗계층은 캡쳐된걸 봐도 별 다른 도움이 되지 못합니다. 사실 제약사항이라고 하기도 좀 그런게 암호화된 패킷이라는 것 자체가 암호화 채널 양 쪽만 복호화를 할 수 있도록 의도된 것이므로 wireshark 가 아니라 다른 툴을 써도 복호화를 하지 못하니 방법이 없습니다.

제가 wireshark를 처음 접했던 15년전만 해도 HTTPS 를 아주 제한적으로만 사용하고 있었습니다. 그러나 요즘엔 네이버, 다음, 지마켓, .... 거의 다 HTTPS 를 사용합니다. 그래서 이런 유명한(?) 사이트에서 주고 받는 HTTP payload 는 wireshark 로 볼수가 없습니다. 하지만 그 대안으로 chrome 의 개발자 도구를 통해 HTTP payload 를 확인할 수 있습니다. 아니 HTTPS는 암호화된건데 어떻게 복호화된 payload 를 눈으로 볼 수 있는거죠? 라고 궁금할 수 있습니다. 복호화 할수 있는건 client 와 server 뿐입니다. server 는 네이버, 다음과 같은 서버들이며, client 는 누구일까요? 크롬 브라우저에서 네이버에 들어갔다고 했을때, 클라이언트는 크롬 브라우저 입니다 . 즉 크롬 브라우저는 암호화된 패킷을 복호화 할 수 있습니다. 따라서 복호화된 패킷을 보여줄 수 있는 겁니다. 다른 말로 하자면 자신이(=크롬 브라우저) 통신 주체이자 패킷 캡쳐 주체이기에 암호화된 것도 볼 수 있습니다. wireshark는 통신 주체는 아니고 패킷 캡쳐 주체일 뿐이기에 암호화된 것은 복호화할 방법이 없는것입니다.

 

ps. 크롬 개발자 도구를 통한 https 트래픽 확인

크롬 개발자 도구는 훌륭하나 패킷 하나하나를 캡쳐해서 보여주는게 아니라 payload 부분만 보여지므로 TCP 3 way handshake 등 연결자체가 안될 경우에는 이를 디버깅할 방법이 없으며, 크롬 브라우저가 client 로 동작할 때만 트래픽 확인할 수 있다는 제약이 있습니다. 

 

* 도움이 되었다면 "좋아요" 부탁드립니다.