리눅스 traceroute 명령어 사용법 - 네트워크 경로 추적과 별표(*) 해석

이 명령어를 언제 쓰는가

DNS는 정상이고 IP도 맞는데 접속이 안 될 때, 다음 질문은 "패킷이 어디까지 갔나"다. traceroute는 목적지까지 거치는 라우터를 순서대로 찍어주기 때문에, 우리 쪽 게이트웨이에서 막힌 건지, 중간 통신망 구간인지, 상대 방화벽 앞인지를 가른다.

지연이 심할 때도 쓴다. 어느 홉에서 응답 시간이 갑자기 몇 배로 뛰는지 보면 병목 위치의 힌트를 얻는다. 다만 아래 함정 절에서 설명하듯 중간 홉의 응답 시간은 그 홉의 실제 부하가 아니다. 이걸 모르고 읽으면 엉뚱한 결론에 도달한다.

동작 원리는 단순하다. TTL을 1부터 하나씩 올려가며 패킷을 보내고, TTL이 0이 되는 지점의 라우터가 돌려주는 ICMP Time Exceeded 응답으로 그 홉의 주소를 알아낸다.

기본 형식

traceroute [옵션] 목적지

목적지 — 도메인 또는 IP. 도메인을 주면 먼저 DNS로 푼 뒤 그 IP로 추적한다.
기본 프로브는 리눅스·BSD 모두 UDP다. 고포트(33434번대)로 보낸다.
홉마다 기본 3번씩 보내고, 각각의 왕복 시간을 밀리초로 찍는다.

자주 쓰는 옵션

옵션	의미	예시
`-n`	역방향 DNS 조회 생략. 훨씬 빠르다	`traceroute -n 8.8.8.8`
`-m`	최대 홉 수(기본 30 또는 64)	`traceroute -n -m 15 8.8.8.8`
`-q`	홉당 프로브 횟수(기본 3)	`traceroute -q 1 8.8.8.8`
`-w`	응답 대기 시간(초). 별표 구간을 빨리 넘긴다	`traceroute -w 1 8.8.8.8`
`-I`	UDP 대신 ICMP Echo 사용	`sudo traceroute -I 8.8.8.8`
`-T` (리눅스)	TCP SYN 사용. 방화벽을 통과할 확률이 가장 높다	`sudo traceroute -T -p 443 devin.kr`
`-P TCP` (BSD/macOS)	리눅스의 `-T`에 해당	`sudo traceroute -P TCP -p 443 devin.kr`
`-p`	목적지 포트 지정	`sudo traceroute -T -p 3306 db01`
`-s`	출발지 IP 지정(NIC가 여러 개일 때)	`traceroute -s 10.0.0.5 8.8.8.8`

실전 예제

1. 경로를 빠르게 훑는다. -n은 거의 항상 붙인다. 역방향 DNS가 느린 구간이 있으면 이것만으로 몇십 초가 갈린다.

traceroute -n -m 12 -q 2 -w 1 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 12 hops max, 40 byte packets
 1  192.168.0.1  1.336 ms  0.614 ms
 2  192.168.219.1  1.000 ms  0.759 ms
 3  182.222.121.225  1.758 ms *
 4  10.203.171.81  2.674 ms  1.621 ms
 5  10.203.152.69  1.291 ms
    10.203.152.77  1.270 ms
 6  100.125.3.33  1.927 ms
    100.125.12.33  2.123 ms
 7  * *
 8  * *
 9  100.66.51.25  7.812 ms
    100.65.52.17  10.834 ms

5·6번 홉처럼 한 홉에 주소가 두 개 찍히는 것은 정상이다. 프로브마다 다른 경로(ECMP)로 갈렸다는 뜻이다. 7·8번의 별표 뒤에 9번이 정상으로 나오는 것도 정상이다. 그 구간 라우터가 응답을 안 할 뿐 패킷은 지나갔다.

2. 웹 서버에 실제로 붙는 포트로 추적한다. UDP가 차단된 경로에서 UDP 기본 모드는 중간부터 전부 별표가 된다. 실제 트래픽과 같은 TCP 443으로 보내면 방화벽 정책을 그대로 타므로 훨씬 정확하다.

sudo traceroute -T -p 443 -n devin.kr

macOS·FreeBSD에는 -T가 없다. 대신 sudo traceroute -P TCP -p 443 -n devin.kr 를 쓴다.

3. 어느 회선으로 나가는지 확인한다. 인터페이스가 여러 개인 서버에서 라우팅이 의도대로 되는지 볼 때다.

traceroute -n -s 10.0.0.5 -m 5 8.8.8.8

1번 홉이 예상한 게이트웨이가 아니면 라우팅 테이블부터 봐야 한다.

4. 내부망 대상은 짧게 끊는다. 같은 대역이면 홉은 하나거나 둘이다. -m을 줄여 불필요한 대기를 없앤다.

traceroute -n -m 3 -w 1 192.168.0.50

5. 정방향과 역방향을 모두 본다. 인터넷 경로는 비대칭이 기본이다. A에서 B로 가는 길과 B에서 A로 오는 길은 다르다. 한쪽만 보고 판단하면 틀린다. 양쪽 서버에서 서로를 향해 각각 실행하고 결과를 비교한다.

함정과 주의점

별표(*)는 대부분 장애가 아니다. 라우터가 ICMP Time Exceeded 응답을 아예 안 만들도록 설정돼 있거나, 그 응답을 방화벽이 버린 것뿐이다. 중간에 별표가 있어도 마지막 홉이 목적지 IP로 도달했다면 경로는 정상이다. 진짜 문제는 별표가 나온 뒤 끝까지 아무것도 안 나오고 종료되는 경우다. 이때는 마지막으로 응답한 홉이 문제 구간의 출발점이다.

중간 홉의 응답 시간은 경유 지연이 아니다. 그 라우터가 자기 CPU로 ICMP 오류 패킷을 만들어 보낸 시간이다. 라우터는 이 작업을 최하 우선순위로 돌리기 때문에, 5번 홉이 100ms인데 10번 홉이 30ms인 상황이 흔하게 나온다. 진짜 지연은 마지막 홉의 값으로 판단한다. 중간 값이 튀는 것만으로 그 구간 장애라고 보고하면 안 된다.

마지막 홉이 목적지가 아닌데 끝날 수 있다. 서버 앞단 방화벽이 UDP 고포트를 막으면 목적지 직전 홉까지만 나오고 멈춘다. 서버는 멀쩡한데 경로가 끊긴 것처럼 보인다. 이때 -T -p 서비스포트로 다시 돌리면 목적지까지 도달한다.

TCP/ICMP 모드는 root 권한이 필요하다. raw 소켓을 열기 때문이다. 일반 사용자로 -T를 치면 권한 오류가 난다. 리눅스에서는 실행 파일에 cap_net_raw 능력이 부여돼 있으면 sudo 없이도 동작한다.

배포판별 차이가 있다. 리눅스는 traceroute 패키지(Debian/Ubuntu), traceroute(RHEL/Rocky)를 설치해야 하고 기본 프로브 크기는 60바이트다. macOS/BSD는 기본 40바이트에 옵션 이름도 일부 다르다. 컨테이너 이미지에는 대개 없다.