베하 ! -
안녕하세요 BTC 쭈콩입니다 !
오늘은 지난 번 포스팅에서 생성한 tcpdump 파일을 가지고 wireShark를 사용해
패킷을 분석해보도록 하겠습니다 !
미리 말씀드리자면 이 포스팅에서는 ALB의 idle timeout을 분석해보고자 하였지만
실습 진행 도중 그건 제 원대한 꿈이었음을 직감하고
처음부터 차근차근 궁금증을 풀어나가게 되었음을 알려드립니다.
그럼 wireShark 가보시죠 -!
(적당한 정보제공과 굉장한 궁금증으로 작성되었습니다)
wireShark 기본적인 사용법
일전에 포스팅했던 tcpdump 패킷 파일 생성하기에서 생성된 파일을 wireShark로 불러오기 해보겠습니다.
- 먼저 wireshark를 설치하면 상단 폴더 버튼을 눌러 파일을 선택해줍니다.
그리고 파일을 열면 이렇게 화면이 뜨게 되는데, 이 화면을 크게 세가지로 나누어 볼 수 있습니다.
- 제일 상단에 패킷리스트,
- 왼쪽 하단에 패킷 디테일
- 우측 하단에 패킷 바이트로 다 다르게 패킷을 나타내고 있습니다.
- 패킷리스트를 먼저 살펴보겠습니다.
- NO : 패킷이 수집되는 순서
- Time : 패킷이 수집된 시간
- Source / Destination : 패킷을 보낸 주소와 패킷이 도착한주소
- Protocol : 패킷 프로토콜 정보
- Length : 패킷의 길이
- info : 패킷의 상세 정보
패킷 디테일에는 패킷 하나하나를 와이어샤크가 보기좋게 정리하여 상세한 정보를 보여줍니다.
패킷 바이트는 가공되거나 정리되지 않은 실제 패킷 데이터를 나타냅니다.
와이어 샤크의 좋은 기능 중 하나는 ! 하나의 패킷을 프로토콜별로 볼 수 있는 스트림도 제공합니다.
예를들어 HTTP 패킷의 스트림을 확인하고 싶을 때는
패킷을 우클릭 → Follow → HTTP Stream 을 클릭하면 확인 할 수 있습니다.
스트림은 와이어샤크의 유용한 분석 기능 중 하나로 TCP 스트림을 쉽게 읽을 수 있는 형태로 재조립하여 보여줍니다.
스트림 내용은 색으로 구분할 수 있습니다 .
빨간 부분은 발신지 → 목적지
파란부분은 목적지 → 발신지로의 트래픽을 보여줍니다.
HTTP 패킷의 경우에는 호스트의 기종 뿐 아니라 브라우저의 정보까지 확인이 가능합니다.
아래는 예시로 열어본 HTTP 패킷입니다.
(예시로 열어보고 갑자기 미궁에 빠져 혼란스러워 하다가 결국 답을 찾게되는 과정입니다)
예시로 열어본 패킷은 바로 이 패킷입니다.
위 패킷을 보면 User-agent가 ELB-HealthChecker/2.0으로 되어 있습니다. 처음엔 도대체 이건 왜 헤더가 따로 없고 브라우저에서 접속하는것과 달리 나타날까 의문이 들었는데, chat gpt에게 힌트를 얻어 해당 ELB-HealthChecker/2.0 가 ELB가 상태 체크 (Health Check)를 할 때 통신하는 패킷인 것 같아 aws 공식문서에서 ELB의 Health Check Interval 시간을 확인해보니 대상이 인스턴스 또는 아이피일 경우 기본 값이 30초로 설정되어 있다는 것을 알게 되었습니다.
그리고 나서 비슷한 패킷이 발견되는 시간을 확인 했을 때, 전부는 아니지만 30초 간격으로 아래와 같은 패킷이 오고 간 것을 확인 할 수 있었습니다. 결국 해당 패킷은 어떤 클라이언트의 요청으로 생긴게 아니라 ELB가 스스로 대상의 상태를 체크하기 위해서 보내는 요청이었습니다.
(네 다음 미궁입니다.)
그런데 의문이 들었던 점은 사실 첫번째 헬스체크와 두번째 헬스체크 사이에 30초가 아니라 12초 18초 12초 이런식으로 불규칙한 인터벌이 나타났는데 처음엔 내가 알게된 내용이 틀렸나? 생각했지만 sourceIP를 보고 확신이 들었습니다 !
15:09:34 Sourceip 10.0.0.194
15:09:46 Sourceip 10.0.1.93
15:10:04 Sourceip 10.0.0.194
15:10:16 Sourceip 10.0.1.93
15:10:34 Sourceip 10.0.0.194
15:10:46 Sourceip 10.0.1.93
15:11:04 Sourceip 10.0.0.194
ALB는 동적인 공인 IP를 가지고 있습니다. 그래서 nslookup으로 ALB의 DNS를 확인하면 두개의 공인아이피를 확인할 수 있는데 그 두개의 아이피에 대한 사설 아이피로 2개의 각기 다른 요청이 오고간 것을 확인할 수 있었습니다.
(아마도 저희 눈에 보이지는 않지만 AWS 내부적으로 임의의 사설 IP가 있는것 같습니다!)
위 내용은 헬스체크 요청 패킷의 시간과 sourceIP를 확인한 결과입니다.
순서대로 보면 체크 시간 사이에 불규칙한 인터벌로 보이지만 source IP 별로 확인하면 딱 30초 간격으로 요청한 것으로 확인할 수 있었습니다. 너무 신이나네요 별것도 아니지만 ㅎㅎㅎㅎㅎㅎㅎㅎㅎ
헬스체크 패킷에 대한 내용은 여기까지만 쓰도록 하겠습니다 !
그리고 테스트 진행할 때 여러 사람들에게 ALB DNS 주소를 보내며 접속을 부탁했습니다. 확인된 IP중에는 동일한 공인 아이피가 많았는데 그건 저희 회사 와이파이 공유기 IP였습니다. 이외에도 회사 외부에 있는 분들에게도 부탁했을 때, 여러 SourceIP에서 요청이 들어오고 통신이 이루어진 것을 확인할 수 있었습니다.
그리고 에러페이지를 만들어준다는 분들도 많았는데! 그중 어떤 경로로 들어와서 Not found 가 발생하는지를 확인할 수 있었습니다. 바로 ALB DNS 주소 뒤에 /error라는 경로를 추가하여 요청했을 때 웹서버의 경로와 맞지 않아 해당 페이지를 찾을 수 없는 현상이 일어났습니다 !
/error /manager 등등 에러를 내주기 위해 노력하셨네요 다들 ㅎㅎㅎ
(오 그런데 그 다음 미궁입니다.)
304 not modified 에러 왜,,? 에러가 나는 건지 ! 확인해보았습니다
304 not modified 란 요청된 자원이 변경되지 않았으므로 클라이언트에서 캐시 된 자원을 사용하도록 권하는 상태코드라고 합니다.
다시 말해 서버에서는 요청된 자원을 다시 재전송하지 않아도 됨을 뜻하며 자원을 효율적으로 쓰라는 권고의 상태코드 인것 같습니다.
(진짜 마지막 미궁입니다.)
HTTP 요청 패킷중에 스트림을 확인하면, User-Agent 가 클라이언트마다 다르게 들어오는데
Windows 인건 회사 분들 노트북인것 같았는데
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko)
이런 에이전트 이름으로 들어와서 뭔가하고 찾아보니 보통 안드로이드에서 데스크탑 보기 설정시 사용되는 유저 에이전트라고 합니다. 아마 누군가 휴대폰으로 들어와서 데스크탑 보기로 제 하찮은 웹서버를 본것 같아요 ㅎㅎㅎ,,
생각보다 스트림 보면서 말이 길어졌습니다 !
너무 짦을까봐 앞에 3way hand shaking 도 설명해야겠다고 생각했었는데,,,
아쉬우니 써봅니다ㅎㅎ!
3 Way-Handshake 란, 전송제어 프로토콜(TCP)에서 통신을 하는 장치간 서로 연결이 잘 되어있는지 확인하는 과정/방식이다. 더 쉽게 말해서 송수신자(데이터를 주고 받는 2사람이라고 생각하면 쉬울 것 같다)사이에 연결을 확인하는 과정이다.
알고 계신것처럼 TCP는 연결지향적 프로토콜이기 때문에 상대와 내가 신호를 서로 주고 받을 수 있는지 검증하는 절차라고 생각하면 쉬울 것 같습니다.
wireshark에서도 오늘 내내 HTTP 스트림을 보며 떠들었지만, HTTP요청을 하기전 서버에서 미리 TCP로 3way handshake로 연결 하는 패킷을 확인할 수 있었습니다 !
사실 분석하면서 ALB idle timeout에 대해 분석해보고 문제 해결을 위한 솔루션을 만들어보고 싶었지만,,
그건 너무 큰 꿈이었고, wireShark를 다루고 보는 법을 아는 것 조차 공부가 필요했으므로 이번 포스팅은,,,,
여기서 마치도록 하겠습니다 ~~~
유익한 시간이었길 바라요 모두 !
그럼 다음 포스팅에서 만나요
베 빠 !
'Network' 카테고리의 다른 글
| 3계층 구조 (3-Tier) (0) | 2023.10.27 |
|---|---|
| 3-way Handshake & 4-way Handshake (1) | 2023.10.19 |
| [Network] tcpdump로 네트워크 패킷 파일 생성하기 (0) | 2023.09.08 |
| [네트워크] 오류 검출 방식 (0) | 2023.07.24 |
| TCP/IP 5계층 (0) | 2023.06.12 |
댓글