Today Keys : traceroute, tracert, tcptraceroute, tcp, syn, icmp, ttl, hop, troubleshooting, windows, linux, mac os
이번 포스팅은 운영체제(OS)에 따라 traceroute 계열 명령이 어떻게 다르게 동작하는지, 그리고 왜 어떤 환경에서는 traceroute는 * * *만 찍히는데 tcptraceroute는 끝까지 보이는지에 대해서 알아보기 위한 포스팅입니다.
현업에서는 “경로 추적”을 한다고 하면 traceroute를 떠올리지만, 실제로는 OS마다 기본 구현이 다르고(Windows는 tracert),
보안 정책(특히 ICMP 차단)이나 방화벽 정책 때문에 TCP 기반 경로 추적이 더 유효한 상황이 많습니다.
이번 포스팅에서는 Windows / Linux / macOS에서 다음을 다룹니다.
- traceroute(또는 tracert)의 기본 동작 방식(무슨 패킷을 보내는지)
- TCP 기반 추적이 필요한 이유
- traceroute의 TCP 옵션과 tcptraceroute의 차이
- 실무에서 어떤 상황에 어떤 도구를 써야 하는지
traceroute 계열 명령의 공통 개념 (TTL / Hop / * * *)
먼저 traceroute가 공통적으로 사용하는 개념은 다음과 같습니다.
- traceroute는 TTL(Time To Live) 값을 1부터 증가시키면서 패킷을 보냅니다.
- 중간 라우터와 같은 L3 장비에서 TTL이 0이 되면 패킷을 폐기하고, 대신 ICMP Time Exceeded(type 11) 를 응답합니다.
- traceroute는 이 ICMP 응답을 보고 “몇 번째 홉이 어떤 IP인지”를 출력합니다.
즉, traceroute가 hop을 출력한다는 것은:
“그 홉에서 TTL이 만료되었고”
“그 홉이 ICMP Time Exceeded를 내게 보내줬다”
라는 뜻입니다.
하지만, ICMP 응답을 받지 못하는 경우도 있습니다.
이 경우에는 해당 홉의 IP 주소가 아니라 * 로 출력됩니다.
운영체제(OS)에 따른 traceroute 기본 동작 차이
Windows (tracert)
Windows는 기본 명령이 tracert이며, ICMP Echo Request 기반이며 다음과 같이 동작합니다.
- TTL 1부터 증가
- ICMP Echo Request 전송
- 중간 홉에서 ICMP Time Exceeded 응답
즉, Windows는 trarcert가 ping과 같은 ICMP 기반이라 내부망에서 ping과 같이 ICMP가 제한되면 응답을 받을 수 없습니다.
또한, tracert에서는 TCP 포트 기반으로 trace를 할 수 있는 옵션이 존재하지 않기 때문에,
tcp 기반의 trace를 위해서는 별도 툴이 필요 합니다.
Linux (traceroute)
Linux의 traceroute는 기본이 UDP 기반으로 동작하며, -T 옵션으로 TCP 기반도 지원합니다.
- 기본: UDP high port로 전송 → 목적지에서 ICMP Port Unreachable로 종료
- TCP 모드: -T → TCP SYN 기반 (half-open 방식)
mac OS (traceroute)
macOS의 traceroute는 BSD 계열 구현이며, 기본 동작은 UDP 기반이며 아래와 같이 동작합니다.
- UDP probe를 TTL 1부터 증가시키며 전송
- 중간 홉: ICMP Time Exceeded(type 11)
- 목적지: (대부분 해당 UDP 포트가 열려있지 않으므로) ICMP Port Unreachable(type 3 code 3)로 “도착” 판정
추가로, TCP 옵션(-P tcp)을 통해서 TCP로도 traceroute 수행이 가능합니다.
TCP 기반의 tcptraceroute
tcp 기반의 traceroute가 필요한 이유?
내부망에서는 보안상, traceroute에서 사용되는 ICMP나 UDP를 보안상 허용하는 정책이 두지 않는 경우가 많습니다.
보안 정책 뿐 아니라, 장비를 보호하기 위한 CoPP나 ratelimit에서 의해서 응답을 받지 못할 수도 있습니다.
반대로, traceroute는 성공하였지만 실제 서비스가 열리지 않을 때, 어느 경로에서 해당 서비스 포트가 막혔는지에 대해서 확인해야 할 수도 있습니다.
따라서, 실제 서비스가 사용하는 tcp 기반으로 traceroute를 수행하면 실 서비스의 경로 추적이 좀 더 용이해집니다.
traceroute(TCP 옵션) vs tcptraceroute의 차이
두 가지 모두 TCP Syn으로 경로를 추적하는 점에서는 동일하지만, 다음과 같은 이유로 결과가 다를 수 있습니다.
- 목적지 도착을 판단하는 방식(응답 처리 방식)
- 응답 패킷을 받아오는 방식(수신 경로)
목적지 도착을 판단하는 방식(응답 처리 방식)
TCP 기반으로 수행하는 경로 추적에서, 목적지의 도착은 다음 중에 하나로 판단합니다.
- 포트가 열려 있는 경우(open) → 목적지가 SYN/ACK 응답
- 포트가 열리지 않은 경우(closed) → 목적지가 RST 응답
- 보안 설정에 의한 드롭(blackhole) → 응답 없음(타임아웃)
이러한 동작은 traceroute(TCP)도 tcptraceroute와 동일 하지만, 응답을 처리 하는 방식에 따라서 결과가 다를 수 있습니다.
tcptraceroute는 “TCP 응답 자체”를 도착 신호로 매우 명확하게 사용합니다.
그래서 결과도 아래처럼 직관적으로 보여줍니다.
이 한 줄이 의미하는 건 딱 2가지입니다.
TTL=8이면 목적지까지 도달했고
목적지가 SYN/ACK를 줬으니 1022 포트는 열려 있다(open)
즉, “도달 + 포트 상태”를 같이 알려주는 방식입니다.
반면 traceroute의 TCP 옵션은 OS/구현체에 따라 도착 판정이 흔들릴 수 있습니다.
특히 macOS(BSD traceroute)에서 종종 발생하는 데,
SYN/ACK 또는 RST가 실제로는 와도 traceroute가 그 응답을 “내가 보낸 probe에 대한 것”으로
매칭하지 못하면 결과를 *로 처리하고 다음 TTL로 넘어가기도 합니다.
그래서 네트워크는 실제로 살아있는데, traceroute 결과만 *가 길어지는 상황이 생길 수 있습니다.
응답 패킷을 받아오는 방식(수신 경로)
1. traceroute(TCP 옵션): “소켓 기반” (커널을 통해 받음)
traceroute는 보통 OS의 네트워크 스택(커널)을 통해 응답을 받습니다.
흐름을 아주 쉽게 말하면:
- traceroute가 SYN을 보냄
- 응답 패킷이 맥에 들어옴
- 커널이 먼저 보고 “이 패킷을 traceroute에게 넘겨줄지” 결정
- 넘어오면 traceroute가 출력, 아니면 *
즉, traceroute는 커널이 전달해줘야만 응답을 볼 수 있습니다.
- 여기서 PF(방화벽), Application Firewall, EDR/보안SW(Network Extension)가 개입하면
- 패킷은 들어왔는데 사용자 프로그램(traceroute)까지 전달이 안 되거나,
- 전달되더라도 매칭이 꼬여서 출력이 흔들릴 수 있습니다.
그래서 “실제 응답이 있어도 traceroute 화면에는 *” 같은 현상이 가능해집니다
2. cptraceroute: “캡처 기반(pcap)” (들어오는 패킷을 직접 봄)
tcptraceroute는 구현에 따라 다르지만,
일반적으로는 네트워크 인터페이스로로 들어오는 패킷을 pcap(tcpdump 같은 방식)으로 직접 관측하는 성격이 강합니다.
즉, 커널이 어떤 소켓에 전달하느냐와 상관 없이 일단 패킷이 네트워크 인터페이스로 오면,
tcptraceroute가 그걸 보고 판정할 수 있는 경우가 많습니다.
그래서 실무에서는 traceroute(TCP)는 *가 길게 나오는데
tcptraceroute는 [open]으로 목적지 도착이 확인되는 경우가 발생합니다.
