통신이 안 될 때 CMD에서 tracert 명령어를 사용하면 어떤 지점에서 문제가 생기는지 유추할 수 있다. tracert는 TCP/IP 통신은 아니고 ICMP 패킷을 보내고 돌려받는 테스트라 100% 신뢰하긴 어렵지만 그래도 왠만한 환경에선 통하고 쓸만하다.
tracert 사용법
tracert [도메인 or IP]
옵션도 여러 가지 있긴 하지만 나는 보통 옵션 없이 쓰고 있다. 딱히 옵션의 필요성은 없다고 느낀다.
tracert 분석
tracert 구글링 해보면 네트워크 속도에 문제가 있을 때 어떤 구간이 느린지 확인하고 조치할 수 있다는 내용이 많은데 딴 세상 이야기 같다. 실제 현장에선 “속도가 좀 느린 거 같군.. 한번 tracert로 확인해볼까?”하는 사람 거의 못봤고 통신이 전혀 안 되는 상황에 이르러서야 써보는 게 tracert다.
예시)
naver.com 도메인으로 ICMP 패킷을 보내는 테스트를 해보자.
tracert naver.com
끝에 결과가 * * * 이렇게 나오면 패킷이 naver.com(233.130.195.95)까지 못 갔다는 뜻이다.
맨 왼쪽부터 보면 1부터 시작해서 30까지 증가하는 숫자는 홉(hop)이라고 한다. 패킷이 이동하는 단계를 나타낸다.
연속으로 나열된 ms 단위의 숫자는 출발지에서 해당 홉까지 ICMP 패킷을 주고받는 속도를 의미한다. 패킷을 3번 보내기 때문에 3번 찍힌다. 3번의 속도가 천차만별이면 안정성이 떨어진다고 볼 수 있겠다.
마지막에 보이는 IP는 해당 홉에서 패킷을 보낸 장비의 IP다. 1번홉은 기본 게이트웨이 IP다.
결과를 보면 8번 홉부터 패킷을 돌려받지 못하고 있다. 그럼 저 구간에 어떤 장비가 있는지 확인해보면 된다. 예를 들어 한번은 사설망과 사설망 간 VPN으로 통신하는 환경에서 통신이 되지 않은 적이 있었는데 tracert로 어떤 구간에서 패킷이 안 가는지 확인해보니 방화벽이 막혀 있는 걸 확인한 적이 있다. 이런식으로 활용이 가능하다.
하지만 이번 naver.com 예시의 경우는 실제론 통신이 잘 되는데 네이버 서버가 ICMP 패킷을 주고 받는 걸 막아놔서 응답이 안 되는 케이스다. 이런 케이스가 있기 때문에 통신 유무를 100% 신뢰할 수는 없다고 처음에 언급했던 것이다.
Recent Comments