와이어샤크로 LAN → WAN → LAN 구조 살펴보기

실습 동기

https://github.com/esc-beep/TIL/blob/main/Network/2.%EC%9D%B8%ED%84%B0%EB%84%B7-%EA%B3%84%EC%B8%B5.md

TIL/Network/2.인터넷-계층.md at main · esc-beep/TIL

 

저번처럼 인터넷 계층에 대한 내용을 이론뿐만 아니라 실습으로, 직접 패킷을 잡아서 헤더에 들어 있는 정보들을 확인해보면 좋을 것 같다는 생각이 들어서 실습을 진행하였다.

 

WireShark로 패킷 캡처

LAN → WAN → LAN 구조를 살펴보기 위해서 외부 호스트인 Google DNS(8.8.8.8)에 ping을 날렸다.

ping google.com

 

이 ping을 날리기 전에 와이어샤크로 미리 Wi-Fi(en0) 패킷 캡처를 하고 있어야 한다.

 

LAN 내부 통신 - ARP 확인

ARP는 IP 주소를 이용해 MAC 주소를 알아내는 프로토콜이다.

 

Wireshark 캡처 화면에서 ARP 요청(Request)과 ARP 응답(Reply)이 오가는 과정을 확인할 수 있다.
조금 더 자세히 확인해보자.

 

패킷 No 531

 

이 패킷은 Who has 192.168.0.103? Tell 192.168.0.1 패킷의 헤더 부분 상세 정보이다.

라우터가 LAN 내부에서 IP 주소 192.168.0.103의 MAC 주소를 모르는 상태라서 전체 네트워크에 누가 192.168.0.103인지 묻는 상황이다.

전체 LAN에게 전달하기 때문에 Destination은 Broadcast(ff:ff:ff:ff:ff:ff)이고, Type은 ARP(0x0806), 요청이기 때문에 Opcode는 request(1)이라는 것을 확인할 수 있다.

 

패킷 No. 1564

 

목적지 컴퓨터가 자신의 MAC 주소를 알려주는 응답 패킷이다.
응답을 받은 라우터는 ARP 캐시 테이블에 이 정보를 저장하고, 다음부터는 브로드캐스트 없이 바로 이 MAC 주소로 프레임을 보낼 수 있다.

Destination은 요청 패킷을 보낸 Source, Type은 ARP(0x0806), 응답이기 때문에 Opcode는 reply(2)이라는 것을 확인할 수 있다.

 

IP 패킷 전달 확인 (LAN → WAN)

기본 게이트웨이는 출발지 컴퓨터의 이더넷 프레임을 열어 IP 패킷의 목적지 IP 주소를 확인하고, 라우팅 테이블을 참조해 다음 라우터로 전송할 경로를 결정한다.

 

Wireshark 캡처 화면에서는 ICMP 프로토콜을 확인할 수 있다. 이것은 아까 입력한 ping google.com의 실제 통신 과정이다.

9번의 ping을 보냈기 때문에 9개의 request-reply 쌍, 즉 18개의 ICMP 프로토콜이 있다.
조금 더 자세히 확인해보자.

 

패킷 No. 3

이 패킷은 Echo (ping) request 패킷이다.

github에 정리해둔 IPv4 헤더의 값들(버전, 헤더 길이, 플래그, TTL 등)을 확인할 수 있다.

id=0x9b77로, 이것으로 같은 ping 세션을 식별할 수 있다.

 

패킷 No. 4

 

위의 패킷과 짝이 되는 Echo (ping) reply 패킷이다.

id=0x9b77로 동일한 값을 갖는 request 패킷과 짝인 것을 확인할 수 있다.

 

ttl=64로, 패킷이 통과한 라우터 수에 따라 ttl 값이 줄어든다.

ping이 google에 매우 빠르게 도달해서 TTL이 거의 줄지 않았다. 즉, google.com에 접속하기까지 거치는 라우터의 수가 매우 적었다는 의미이다.

 

PPP 프레임은 일반 LAN에서는 볼 수 없다.

 

이렇게 ARN으로 MAC 주소를 찾는 과정과 ping을 이용해 외부 통신을 어떻게 하는지 확인할 수 있었다.

DNS 프로토콜들도 있었는데 이건 다음 내용을 정리하고 함께하는 것으로...