해당 글에서는 실제로 TCP연결 간 발생한 패킷을 확인하고 이에 대한 분석을 해보고자한다.
아래는 nc명령을 이용해서 1.1.1.1:433에 접속하는 과정에서 발생한 핸드쉐이크 과정이다.
tcpdump: listening on en1, link-type EN10MB (Ethernet), snapshot length 524288 bytes
16:38:10.697437 f2:f9:32:6a:10:8c > 04:09:a5:40:20:49, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
192.168.45.206.57950 > 1.1.1.1.443: Flags [SEW], seq 2944625920, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 260541411 ecr 0,sackOK,eol], length 0
0x0000: 0409 a540 2049 f2f9 326a 108c 0800 4500 ...@.I..2j....E.
0x0010: 0040 0000 4000 4006 4a40 c0a8 2dce 0101 .@..@.@.J@..-...
0x0020: 0101 e25e 01bb af83 6d00 0000 0000 b0c2 ...^....m.......
0x0030: ffff a9bb 0000 0204 05b4 0103 0306 0101 ................
0x0040: 080a 0f87 8be3 0000 0000 0402 0000 ..............
16:38:10.705547 04:09:a5:40:20:49 > f2:f9:32:6a:10:8c, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 60)
1.1.1.1.443 > 192.168.45.206.57950: Flags [S.E], seq 2320305316, ack 2944625921, win 65535, options [mss 1460,sackOK,TS val 1782207096 ecr 260541411,nop,wscale 13], length 0
0x0000: f2f9 326a 108c 0409 a540 2049 0800 4500 ..2j.....@.I..E.
0x0010: 003c 0000 4000 3606 5444 0101 0101 c0a8 .<..@.6.TD......
0x0020: 2dce 01bb e25e 8a4d 0ca4 af83 6d01 a052 -....^.M....m..R
0x0030: ffff 6784 0000 0204 05b4 0402 080a 6a3a ..g...........j:
0x0040: 5278 0f87 8be3 0103 030d Rx........
16:38:10.705710 f2:f9:32:6a:10:8c > 04:09:a5:40:20:49, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
192.168.45.206.57950 > 1.1.1.1.443: Flags [.], seq 2944625921, ack 2320305317, win 2059, options [nop,nop,TS val 260541420 ecr 1782207096], length 0
0x0000: 0409 a540 2049 f2f9 326a 108c 0800 4500 ...@.I..2j....E.
0x0010: 0034 0000 4000 4006 4a4c c0a8 2dce 0101 .4..@.@.JL..-...
0x0020: 0101 e25e 01bb af83 6d01 8a4d 0ca5 8010 ...^....m..M....
0x0030: 080b 8e82 0000 0101 080a 0f87 8bec 6a3a ..............j:
0x0040: 5278 Rx
이제 이를 분석해보자.
Ethrnet 분석
Ethernet 헤더는 IEEE라는 기관에서 정의하는데, 다음과 같은 형태로 구성된다.
아마 내가 캡쳐한 패킷은 Frame부분에 해당하는 것으로 보인다. (Packet에 해당하는 부분은 이전 Layer에서 확인된 후 벗겨진게 아닌가 생각된다)
따라서 처음 14바이트는 각각 DA, SA, Type에 해당한다.
0409 a540 2049 f2f9 326a 108c 0800
이를 분해하여 본다면. 다음과 같다.
| 바이트 | 값 | 의미 |
|---|---|---|
| 0–5 | 04 09 a5 40 20 49 | 04:09:a5:40:20:49 |
| 6–11 | f2 f9 32 6a 10 8c | f2:f9:32:6a:10:8c |
| 12–13 | 08 00 | 0x0800 → IPv4 |
IPv4 분석
IPv4 프로토콜은 문서 RFC791에 정의돼있는데 이를 기반으로 헤더가 어떻게 파싱되는지 확인해보자.
참조(https://www.rfc-editor.org/rfc/rfc791.html)
구체적인 해설은 IPv4 헤더 필드와 옵션 정리를 참조.
가장 처음 보낸 패킷인 클라이언트 → DNS 서버로 향하는 패킷의 IPv4헤더를 분해하면 다음과 같다.
45 Version + IHL
00 ToS
00 40 Total Length
00 00 Identification
40 00 Flags + Fragment Offset
40 TTL
06 Protocol
4a 40 Header Checksum
c0 a8 2d ce Source IP
01 01 01 01 Destination IP
Version + IHL
45이므로 IPv4를 사용하며, 헤더가 5개의 워드 즉, 20바이트를 사용하는 것을 알 수 있다.
ToS
0으로 일반 트레픽으로 처리됐다.
Total Length
0x40 즉, 64바이트의 크기로 헤더 + 페이로드가 구성됨을 의미한다.
Identification
이 필드는 IP fragmentation이 발생했을 때, 여러 조각이 같은 원본 datagram에서 나온 것인지 식별하기 위한 값이다. 여기서는 IP fragmentation이 발생하지 않았기에, 0으로 표시된다.
Flags + Fragment Offset
여기서는 DF플레그만 1로 설정되는데 이는 Don’t Fragment를 의미하며 위 Identification에서 언급한 IP fragmentation이 발생하지 않도록 주는 플레그이다.
DF플레그가 존재하는것으로 유추할 수 있는데, IP fragmentation은 전송 이후에 라우터에 의해서 발생할 수 있고, 해당 옵션은 이러한 것을 막기 위해 설정된다.
TTL
라우터 간 이동마다 줄어드는 TTL값이다. 여기서는 64로 값을 세팅하여 보내는 것으로 보인다.
TTL값이 존재하는 이유는 라우터 루프가 발생하여 패킷이 라우터 내에서 무한이 도는것을 방지하기 위함이다.
Protocol
해당 값은 어떤 상위 계층 프로토콜이 들어있는지를 알려준다. 0x6의 값은 TCP프로토콜을 의미한다. 이에 따라 다음에 TCP헤더가 나오고 그렇게 해석된다.
Header Checksum
one’s complement sum 계산 방식을 이용하여 계산된 값이 들어간다.
Source IP / Destination IP
이름 그대로 보내는 클라이언트 즉, 전송자의 IP 주소와 도착지 수신자의 IP 주소가 담긴다.
예제의 값과 그것을 알아보기 쉬운 형태로 변환한 것은 다음과 같다.
c0 a8 2d ce → Source IP = 192.168.45.206
01 01 01 01 → Destination IP = 1.1.1.1
여기서
Source IP가 사설 IPv4 주소인데, 공유기를 거쳐서 NAT가 이루어지기 이전의 패킷을 캡쳐한 것이기에 그렇다.