네트워크/네트워크 기초
3계층 ②: 멀리 있는 컴퓨터와 통신하는 방법 (IPv4, ICMP, 라우팅)
절차탁마
2025. 4. 9. 02:00
[들어가며]
이제 다른 네트워크, 즉 '멀리 있는' 컴퓨터와 통신하는 방법을 알아볼 차례입니다. 이때 핵심 역할을 하는 것이 바로 3계층(네트워크 계층)의 대표 주자, IPv4 프로토콜과 경로를 찾아주는 라우팅 개념입니다. 통신 상태를 점검하는 ICMP도 함께 살펴보죠.
1. IPv4 프로토콜: 인터넷 세상을 누비는 데이터 택배 상자
- 역할: 네트워크 상에서 데이터를 주고받기 위한 핵심 프로토콜. 데이터를 패킷(Packet) 단위로 쪼개고, 각 패킷에 출발지/목적지 IP 주소라는 '주소 라벨'을 붙여 전송합니다.
- 중요 특징: "최선형 서비스 (Best-Effort)"
- 데이터가 정확하게, 순서대로 도착하는 것을 보장하지 않습니다. 마치 일반 우편처럼, 최선을 다해 보내지만 중간에 분실되거나(패킷 유실), 순서가 뒤바뀌거나, 같은 내용이 중복 전달될 수도 있습니다.
- (사례) 만약 패킷 순서가 뒤바뀌거나 유실되면 이미지 파일이 깨져 보이거나, 동영상 재생이 끊길 수 있습니다. 악의적으로 특정 대상에게 대량의 불필요한 패킷을 보내면 서비스 거부(DoS) 공격이 될 수도 있죠.
- 데이터의 신뢰성(정확성, 순서 보장)은 상위 계층인 4계층(전송 계층)의 TCP 프로토콜이 책임집니다. IPv4는 일단 목적지까지 '어떻게든 보내는 것'에 집중합니다.
- IPv4 헤더 구조 (기본 20바이트): 패킷을 제어하기 위한 중요한 정보들이 담겨 있습니다.
- (사례 - TTL) 운영체제마다 TTL 기본값이 다릅니다 (Linux: 64, Windows: 128 등). ping 명령어로 상대방에게 ICMP Echo 요청을 보내고 응답의 TTL 값을 확인하면, 초기 TTL 값에서 몇 개의 라우터를 거쳐왔는지(홉 수)를 빼서 상대방의 운영체제를 추측해볼 수 있습니다. (물론 중간 라우터가 TTL을 조작할 수도 있습니다.)
-
필드명 크기(비트) 설명 Version 4 IP 프로토콜 버전 (IPv4 = 4) Header Length (HLEN) 4 IP 헤더의 전체 길이. 4바이트 단위로 표시. (예: 기본 20바이트 헤더는 5 (20/4)로 저장) DSCP/ECN (구 TOS) 8 서비스 품질(QoS) 관련 필드. 과거 TOS 필드였으나 현재는 DSCP/ECN으로 사용됨 (보통 0으로 채워지기도 함). Total Length 16 IP 헤더 + 데이터(페이로드)를 포함한 패킷 전체 길이 (바이트 단위). 최대 65,535 바이트. Identification 16 패킷 조각화(Fragmentation) 시, 원래 하나의 패킷이었음을 나타내는 고유 ID. Flags 3 패킷 조각화 제어 플래그. (첫 비트: 예약, D: Don't Fragment, M: More Fragments) Fragment Offset 13 조각화된 패킷에서, 원래 데이터의 어느 위치부터 시작하는 조각인지 표시. 8바이트 단위로 저장. (순서 맞추기용) TTL (Time To Live) 8 패킷이 네트워크 상에 살아있을 수 있는 시간(홉 수). 라우터(3계층 장비)를 하나 거칠 때마다 1씩 감소, 0이 되면 패킷 폐기. (무한 루프 방지) Protocol 8 IP 패킷 안에 담긴 상위 계층 데이터가 어떤 프로토콜인지 표시. (예: ICMP=1, TCP=6, UDP=17) Header Checksum 16 IP 헤더 자체의 오류 검출용. Source Address 32 (4바이트) 출발지 IP 주소. Destination Address 32 (4바이트) 목적지 IP 주소. IP Options 가변 (선택 사항) 추가적인 제어 정보. 거의 사용되지 않음.
2. ICMP 프로토콜: 네트워크 상태 점검 및 오류 보고서
- ICMP (Internet Control Message Protocol): IP 통신 과정에서 발생하는 오류를 보고하거나, 네트워크 장비 간 상태를 확인(진단)하는 데 사용되는 제어용 프로토콜. IP 자신은 오류 보고 기능이 없으므로 ICMP의 도움을 받습니다.
- 주요 기능:
- 오류 보고: 목적지에 도달할 수 없음(Destination Unreachable), TTL 초과(Time Exceeded) 등 IP 패킷 전달 실패 시 오류 원인을 출발지에 알려줌.
- 진단: 특정 목적지까지 통신이 가능한지 확인 (예: ping 명령어 - ICMP Echo Request/Reply 사용).
- ICMP 메시지 구조:
-
필드명 크기(바이트) 설명 Type 1 메시지의 종류 (대분류). 어떤 종류의 제어 메시지인지 나타냄. Code 1 Type에 대한 세부 코드 (소분류). 오류의 구체적인 원인 등을 나타냄. Checksum 2 ICMP 메시지 자체의 오류 검출용. 기타 정보 가변 Type/Code에 따라 추가적인 정보 포함 (예: 오류 발생 패킷의 IP 헤더 등) - 주요 ICMP Type/Code 예시:
- Type 8 / Code 0: Echo Request (Ping 요청) - "거기 잘 있니?"
- Type 0 / Code 0: Echo Reply (Ping 응답) - "어, 나 잘 있어!"
- (흥미로운 점) 왜 요청(8)보다 응답(0) 번호가 더 작을까요? 설계자의 의도는 알 수 없지만, 흔히 볼 수 있는 순서와 달라 기억해 둘 만합니다.
- Type 3: Destination Unreachable (목적지 도달 불가) - "거기 가는 길 없어/막혔어!"
- Code 0: Network Unreachable (네트워크 자체에 도달 불가)
- Code 1: Host Unreachable (네트워크는 찾았으나 해당 호스트 없음/응답 없음)
- Code 3: Port Unreachable (호스트는 찾았으나 해당 포트(서비스)가 열려있지 않음) - 방화벽 등에서 자주 발생
- Type 11: Time Exceeded (시간 초과) - "가는데 너무 오래 걸려서(TTL=0) 포기했어!"
- Code 0: TTL expired in transit (라우터 거치다 TTL 0 됨) - traceroute 명령어가 이 원리를 이용
- Type 5: Redirect (경로 재지정) - "이쪽 길 말고 저쪽 길이 더 빨라!" (보안 문제로 현재 거의 사용 안 함)
- (보안 이슈) 악의적인 공격자가 이 메시지를 위조하여 특정 트래픽을 자신에게 오도록 경로를 변경시킬 수 있는 위험이 있었습니다.
3. 라우팅 테이블: 네트워크의 길 안내 표지판
- 라우팅 테이블이란? 컴퓨터나 라우터가 IP 패킷을 어디로 보내야 할지 결정하기 위해 참조하는 경로 정보 목록. 일종의 '네트워크 길 안내 표지판' 또는 '지도'입니다.
- 확인 방법 (Linux/macOS): netstat -rn 또는 ip route 명령어.
- 주요 항목:
-
항목 설명 Destination 목적지 네트워크 주소. 이 네트워크로 가려면 아래 규칙을 따르라는 의미. Genmask/Netmask 목적지 네트워크의 서브넷 마스크. Destination 주소와 함께 네트워크 범위를 정의. Gateway 해당 목적지로 가기 위해 패킷을 전달해야 할 다음 라우터(홉)의 IP 주소. 0.0.0.0이면 직접 연결된 네트워크. Iface 패킷을 내보낼 로컬 네트워크 인터페이스(랜 카드) 이름 (예: eth0, en0). Metric/Priority 경로 우선순위. 여러 경로가 있을 때 값이 낮은 경로를 선호. (관리자가 설정하거나 프로토콜이 계산) Flags 경로의 상태 정보 (U: Up, G: Gateway 사용, H: Host 특정 경로 등) - 라우팅 테이블 예시:
- 첫 번째 줄 (0.0.0.0 / 0.0.0.0): 기본 경로 (Default Route)
- 의미: 라우팅 테이블에 명시된 다른 경로에 해당하지 않는 모든 목적지는 일단 게이트웨이(192.168.1.1)로 보내라!
(인터넷으로 나가는 통로)
- 의미: 라우팅 테이블에 명시된 다른 경로에 해당하지 않는 모든 목적지는 일단 게이트웨이(192.168.1.1)로 보내라!
- 두 번째 줄 (192.168.1.0 / 255.255.255.0): 로컬 네트워크 경로
- 의미: 192.168.1.x 네트워크 대역은 게이트웨이를 거치지 않고 직접 연결되어 있으니(Gateway가 0.0.0.0), eth0 인터페이스를 통해 바로 통신하라!
-
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
- 첫 번째 줄 (0.0.0.0 / 0.0.0.0): 기본 경로 (Default Route)
- 라우팅 동작 원리 (가장 구체적인 경로 우선 - Longest Prefix Match):
- 패킷의 목적지 IP 주소를 확인합니다.
- 라우팅 테이블의 모든 항목과 비교하여, 목적지 IP 주소가 해당 네트워크 범위(Destination + Netmask)에 속하는지 확인합니다.
- 여러 항목에 해당될 경우, 가장 구체적인(가장 긴 Prefix 길이, 즉 Netmask의 1 개수가 가장 많은) 경로를 선택합니다.
- 선택된 경로의 Gateway와 Iface 정보를 이용해 패킷을 다음 홉으로 전달합니다.
(만약 Gateway가 0.0.0.0이면 ARP를 통해 목적지 MAC 주소를 찾아 직접 전달, 아니면 Gateway의 MAC 주소를 찾아 전달)
- 사례: 다른 네트워크와 통신하는 상세 과정 (A → B)
- 네트워크 구성:
- PC A: 192.168.10.10/24 (게이트웨이: 192.168.10.1)
- PC B: 192.168.20.20/24 (게이트웨이: 192.168.20.1)
- 라우터 R1: 인터페이스 1 (192.168.10.1), 인터페이스 2 (192.168.20.1) - 두 네트워크 연결
- A의 라우팅 테이블 (간략화):
-
Destination Gateway Genmask Iface 0.0.0.0 192.168.10.1 0.0.0.0 eth0 // 기본 경로 192.168.10.0 0.0.0.0 255.255.255.0 eth0 // 로컬 경로
-
- 통신 과정:
- A → B (192.168.20.20) 패킷 생성: A가 B에게 보낼 IP 패킷을 만듭니다 (출발지 IP: 192.168.10.10, 목적지 IP: 192.168.20.20).
- A: 경로 결정: A는 목적지 IP(192.168.20.20)가 자신의 로컬 네트워크(192.168.10.0/24) 범위 밖임을 확인합니다. 라우팅 테이블을 참조하여, 192.168.20.20은 로컬 경로에 해당하지 않으므로 기본 경로(0.0.0.0/0)를 선택합니다.
- A: 다음 홉(게이트웨이) MAC 주소 확인: 기본 경로의 게이트웨이는 192.168.10.1입니다. A는 이 게이트웨이(라우터 R1의 인터페이스 1)의 MAC 주소를 알아내기 위해 ARP 캐시를 확인합니다. 없으면 ARP 요청을 보내 알아냅니다.
- A → R1 패킷 전송: A는 IP 패킷을 이더넷 프레임으로 캡슐화합니다. 이때 이더넷 목적지 MAC 주소는 라우터 R1(192.168.10.1)의 MAC 주소로 설정하고, 출발지 MAC은 자신의 것으로 설정하여 eth0 인터페이스로 전송합니다.
- ⭐ IP 주소는 그대로 A → B, MAC 주소는 A → R1
- R1: 패킷 수신 및 경로 결정: R1은 프레임을 받아 이더넷 헤더를 제거하고 IP 패킷을 확인합니다. 목적지 IP(192.168.20.20)를 보고 자신의 라우팅 테이블을 참조합니다. R1은 192.168.20.0/24 네트워크가 자신의 인터페이스 2(192.168.20.1)에 직접 연결되어 있음을 확인합니다.
- R1: 최종 목적지(B) MAC 주소 확인: R1은 이제 최종 목적지인 B(192.168.20.20)의 MAC 주소를 알아내기 위해 ARP 캐시를 확인합니다. 없으면 인터페이스 2를 통해 ARP 요청을 보냅니다.
- R1 → B 패킷 전송: R1은 새로운 이더넷 프레임을 만듭니다. 출발지 MAC 주소는 R1의 인터페이스 2 MAC 주소, 목적지 MAC 주소는 B의 MAC 주소로 설정합니다. IP 패킷(출발지 A, 목적지 B)은 그대로 담아 인터페이스 2로 전송합니다.
- ⭐ IP 주소는 그대로 A → B, MAC 주소는 R1 → B
- B: 패킷 수신: B는 프레임을 받아 이더넷 헤더를 제거하고, IP 패킷의 목적지 IP가 자신임을 확인 후 상위 계층(TCP/UDP)으로 데이터를 전달합니다.
- 💡 핵심 정리:
- 패킷이 다른 네트워크로 전달될 때, IP 헤더의 출발지/목적지 IP 주소는 변하지 않습니다.
- 하지만 각 라우터를 거칠 때마다(홉마다) 이더넷 헤더의 출발지/목적지 MAC 주소는 계속 바뀝니다.
(바로 다음 장비의 MAC 주소로 설정됨)- 이게 매우 중요한 핵심 동작입니다!!!
- 라우팅 테이블은 목적지까지 가는 다음 단계(Next Hop)를 알려주는 역할을 합니다.
- 네트워크 구성:
4. IPv4 패킷 조각화 (Fragmentation): 큰 짐 나눠 보내기
- 조각화란? IP 패킷이 라우터를 통해 전달될 때, 라우터가 연결된 다음 네트워크의 전송 단위(MTU - Maximum Transmission Unit)가 현재 패킷 크기보다 작으면, 패킷을 여러 개의 작은 조각으로 나누어 보내는 과정입니다.
- MTU: 하나의 링크(예: 이더넷, PPP 등)에서 한 번에 보낼 수 있는 최대 데이터(페이로드) 크기. (예: 일반적인 이더넷 MTU는 1500 바이트)
- 라우터는 각기 다른 종류의 네트워크를 연결할 수 있으므로, MTU 크기가 다른 구간을 만날 수 있습니다. (주의)
- 조각화 과정:
- 라우터는 패킷 크기가 다음 링크의 MTU보다 크면 조각화를 결정합니다.
(단, IP 헤더의 DF 플래그가 1이면 조각화 불가 → ICMP 오류 메시지 반환) - 원래 패킷의 IP 헤더를 복사하여 각 조각마다 붙입니다
(Total Length, Flags, Fragment Offset, Checksum 등은 조각에 맞게 수정). - Identification 필드: 모든 조각에 동일한 값을 부여하여, 나중에 수신 측에서 "아, 얘네들은 원래 한 몸이었구나!" 하고 알 수 있게 합니다.
- Flags 필드 (MF - More Fragments): 마지막 조각을 제외한 모든 조각은 MF 플래그를 1로 설정하여 "뒤에 조각 더 있음!"을 알립니다. 마지막 조각은 MF 플래그를 0으로 설정하여 "내가 마지막 조각이야!"를 알립니다.
- Fragment Offset 필드: 각 조각이 원래 데이터의 어디부터 시작하는 부분인지 알려줍니다. 8바이트 단위로 표시합니다. (첫 번째 조각은 Offset=0)
- 라우터는 패킷 크기가 다음 링크의 MTU보다 크면 조각화를 결정합니다.
- 조립 (Reassembly): 조각화된 패킷들은 최종 목적지 시스템에 도착해서야 비로소 원래의 완전한 패킷으로 재조립됩니다. 중간 라우터는 조립하지 않습니다. (쪼개기만 합니다.)
- 사례: 큰 Ping 패킷 조각화
- PC A에서 PC B로 3000 바이트 크기의 데이터를 담은 Ping(ICMP Echo Request)을 보낸다고 가정해 봅시다 (ping -s 3000 <B의 IP>). 이더넷 MTU는 1500 바이트입니다.
- 1. 원본 패킷 생성:
- ICMP 데이터: 3000 바이트
- ICMP 헤더: 8 바이트
- IP 헤더: 20 바이트
- 총 IP 패킷 크기: 3028 바이트 (3000 + 8 + 20)
- 2. 조각화 발생: 3028 바이트는 이더넷 MTU(1500)보다 큽니다. 따라서 출발지 A 또는 중간 라우터에서 조각화가 일어납니다. (여기서는 A에서 발생한다고 가정)
- 최대 데이터 크기: 1500(MTU) - 20(IP 헤더) = 1480 바이트. 단, Fragment Offset은 8바이트 단위이므로, 8의 배수인 1480이 최대 데이터 크기가 됩니다.
- 3. 조각 생성:
- 조각 1:
- IP 헤더 (20 바이트): ID=12345, Flags(MF=1), Offset=0, Total Length=1500
- 데이터: 원본 데이터의 첫 1480 바이트 (ICMP 헤더 8바이트 + ICMP 데이터 1472바이트 포함)
- 조각 2:
- IP 헤더 (20 바이트): ID=12345, Flags(MF=1), Offset=185 (1480 / 8), Total Length=1500
- 데이터: 원본 데이터의 다음 1480 바이트
- 조각 3:
- IP 헤더 (20 바이트): ID=12345, Flags(MF=0), Offset=370 (1480 * 2 / 8), Total Length=68 (남은 데이터 48 + IP 헤더 20)
- 데이터: 원본 데이터의 나머지 48 바이트
- 조각 1:
- 4. 전송 및 재조립: 이 세 조각은 각각 별도의 이더넷 프레임에 담겨 B로 전송됩니다. B는 동일한 ID(12345)를 가진 조각들을 모으고, Fragment Offset과 MF 플래그를 이용해 순서대로 재조립하여 원래의 3028 바이트 ICMP Echo Request 패킷을 복원합니다.
- (참고) 일반적으로 첫 번째 조각(Offset=0)에만 상위 계층(ICMP, TCP, UDP)의 헤더가 포함됩니다. 이후 조각들은 데이터 부분만 담고 있죠. 그래서 네트워크 분석 도구(Wireshark 등)로 보면 첫 번째 조각만 ICMP 프로토콜로 인식되고, 나머지는 그냥 'Fragmented IP protocol' 데이터로 보일 수 있습니다.
- 캡슐화 순서: 원래의 IP 패킷은 [IP 헤더] [상위 계층 헤더] [상위 계층 데이터] 순서로 구성됩니다.
- 조각화 대상: IP 조각화는 IP 헤더를 제외한 페이로드 부분([상위 계층 헤더] [상위 계층 데이터])을 나누는 과정입니다.
- 첫 번째 조각: 따라서 페이로드의 가장 앞부분, 즉 상위 계층 헤더와 데이터의 일부가 첫 번째 조각(Offset=0)에 담기게 됩니다.
- 이후 조각: 두 번째 조각부터는 상위 계층 헤더 없이, 나누어진 상위 계층 데이터의 나머지 부분들만 포함됩니다.
- 조각화의 단점:
- 조각 중 하나라도 유실되면 전체 패킷을 버리고 재전송해야 할 수 있습니다 (TCP의 경우).
- 라우터와 최종 호스트에 부하를 줍니다.
- 일부 방화벽은 보안상의 이유로 조각화된 패킷을 차단하기도 합니다.
- 최근에는? 경로 MTU 탐색(Path MTU Discovery) 기능을 사용하여 애초에 조각화가 발생하지 않도록 패킷 크기를 조절하는 방식을 더 선호합니다.
[궁금할 수 있는 포인트 🤔]
- Q: "IP는 왜 신뢰성을 보장하지 않나요? 중요한 데이터가 유실되면 어떡하죠?"
- A: IP 설계 철학은 '최대한 빠르고 단순하게' 목적지까지 전달하는 데 집중하는 것입니다. 신뢰성 보장을 위한 복잡한 기능(순서 확인, 재전송 등)은 상위 계층(TCP)에 맡겨 역할을 분담한 것이죠. UDP처럼 신뢰성보다 속도가 중요한 서비스도 있기 때문에, IP 자체는 신뢰성을 강제하지 않습니다.
- Q: "라우팅 테이블은 누가 만들어주나요?"
- A: 직접 연결된 네트워크 정보는 운영체제가 자동으로 인식하여 추가합니다. 기본 게이트웨이 정보는 보통 네트워크 설정 시 수동으로 입력하거나 DHCP를 통해 자동으로 받아옵니다. 복잡한 네트워크 환경에서는 관리자가 수동으로 경로를 추가(Static Routing)하거나, 라우팅 프로토콜(RIP, OSPF, BGP 등)을 이용해 라우터끼리 경로 정보를 교환하여 동적으로 테이블을 생성/갱신(Dynamic Routing)합니다.
- Q: "ICMP는 해킹에 사용될 수도 있나요?"
- A: 네, 악용될 수 있습니다. 예를 들어, ICMP Echo 요청/응답을 대량으로 보내 네트워크 대역폭이나 시스템 자원을 고갈시키는 Smurf 공격이나 Ping Flood 공격(DoS의 일종)이 있습니다. ICMP Redirect 메시지를 위조하여 트래픽 경로를 바꾸거나, ICMP 메시지 자체의 취약점을 이용하는 공격도 존재했습니다. 그래서 많은 네트워크에서 ICMP 메시지를 필터링하거나 제한적으로 허용합니다.
- Q: "조각화는 왜 최종 목적지에서만 재조립하나요? 중간 라우터가 하면 안 되나요?"
- A: 중간 라우터는 패킷을 최대한 빨리 다음 홉으로 전달하는 것이 주 역할입니다. 모든 조각이 도착할 때까지 기다렸다가 재조립하는 것은 라우터에 큰 부담을 주고 지연 시간을 늘립니다. 또한, 조각들이 서로 다른 경로로 전달될 수도 있기 때문에 중간에서 재조립하는 것은 비효율적이고 복잡합니다.
[마무리하며]
3계층은 IP 주소를 이용해 전 세계 어디든 경로를 찾아 데이터를 전달하는 핵심적인 역할을 합니다. IPv4 헤더의 다양한 필드들은 이 과정을 제어하고, ICMP는 통신 상태를 점검하며, 라우팅 테이블은 실제 경로를 안내합니다. 때로는 MTU 제약으로 인해 조각화가 발생하기도 하죠. 이러한 요소들이 어떻게 상호작용하는지 이해하는 것은 네트워크 동작 원리를 파악하는 데 매우 중요합니다.