1. ping
Ping은 IP 주소를 가진 기기 간의 네트워크 연결을 테스트하는 데 사용되는 가장 일반적인 도구이다. 항상 발신자가 수신자에게 ICMP 에코 요청 패킷(ICMP type 8 code 0)을 전송하면서 통신확인이 시작되며 수신자는 ICMP 에코 응답 패킷(ICMP type 0 code 0)으로 응답하게된다.
ping의 동작이 항상 정확 할 수는 없다. 발신자와 수신자 사이의 경로에 방화벽이 있다면 방화벽이 ICMP 패킷을 필터링해 통신을 차단할 수도 있기 때문이다. 따라서 반대 편에 있는 호스트가 ICMP에 응답하지 않는다고 해서 호스트가 네트워크 상에 없다고 가정할 수는 없는 것이다.
Ping은 운영 체제에 따라 다르게 동작하며 Windows OS에서 ping은 기본 4개의 패킷을 보내고 자체적으로 종료된다. 만약 Windows에서 핑 패킷을 연속적으로 보내고 쉽다면 -t 옵션을 사용하면 된다.
C:\Users\jdoe>ping 192.168.0.1
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
Unix/Linux 기반 시스템 및 MacOS에서 ping은 중지할 때까지 실행되며 CTRL+C 키보드 조합 사용을 사용해야 연속 핑 룹에서 빠져나올 수 있다. Window 운영체제와 반대로 만약 4개의 핑 패킷을 보내고 싶다면 -c 옵션과 보내고 싶은 패킷 수를 표시해 주면 된다. 예) ping -c 4 192.168.0.1
[jdoe@centos8 ~]$ ping -c 4 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=128 time=2.30 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=128 time=1.49 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=128 time=1.92 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=128 time=1.89 ms
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.485/1.898/2.295/0.291 ms
위의 출력에서 볼 수 있듯 4개의 ICMP 에코 요청 패킷이 전송되었고 4개의 ICMP 에코 응답 패킷이 다시 수신되었다. 즉, 패킷 손실은 0%며 통신이 원활이 이뤄지고 있다는 것을 알 수 있다. 타임이 3006ms 인 것이 현제 사용하는 가상머신이 조금 느려서 그런 것이니 여기서는 신경을 안쓰도 된다. 또 다른 유용한 정보는 패킷이 발신자를 떠나 수신자로 갔다 다시 돌아오는 데 걸린 시간을 알려주는 왕복 시간(RTT)이다. 위 예에서 가장 아래 줄에 나와 있는 내용은 최소 소모 시간 (빠른) 1.485ms, 평균 1.898ms, 최대 소모 시간 (느린) 2.295ms 그리고 중앙 편차 0.291ms로 읽으면 된다. 이 정보를 사용하여 발신자와 수신자 간의 링크 품질을 진단할 수 있다. 일반적으로 표준편차(stddev)가 정말 높은 경우를 제외하고는 평균 RTT시간에 주의를 기울여야 한다.
ping이 실행 중일 때 Wireshark를 사용하여 패킷을 캡처하는 경우 ICMP 에코 요청 및 응답 패킷이 표시된다. 아래는 192.168.30.50에서 라우터 주소인 192.168.0.1로 핑 패킷 4개를 보내 캡쳐한 스크린샷이며 보다시피 4개의 요청(request) 메세지와 4개의 응답 (reply) 패킷 메세지로 총 8개의 메세지가 보인다면 패킷 손실이 0%인 것이다.
마지막으로 ping 을 이용하면 DNS가 정상적으로 동작하고 있는지 간단하게 확인이 가능해진다. DNS가 정상적으로 작동하고 있다면 아래와 같이 웹 주소를 먼저 IP로 변경한 후 ICMP 패킷을 내보낼 것이다.
[jdoe@centos8 ~]$ ping www.google.com
PING www.google.com (142.250.66.164) 56(84) bytes of data.
64 bytes from syd09s22-in-f4.1e100.net (142.250.66.164): icmp_seq=1 ttl=128 time=13.0 ms
64 bytes from syd09s22-in-f4.1e100.net (142.250.66.164): icmp_seq=2 ttl=128 time=17.3 ms
64 bytes from syd09s22-in-f4.1e100.net (142.250.66.164): icmp_seq=3 ttl=128 time=12.3 ms
64 bytes from syd09s22-in-f4.1e100.net (142.250.66.164): icmp_seq=4 ttl=128 time=14.7 ms
^C
--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3016ms
rtt min/avg/max/mdev = 12.281/14.334/17.302/1.926 ms
만약 DNS가 재대로 설정이 되어 있지 않든 동작이 정상적으로 되지 않을 경우 아래와 같은 에러 메세지들을 확인할 수 있다.
[jdoe@centos8 ~]$ ping www.google.com
ping: www.google.com: Name or service not known
2. traceroute
Traceroute는 ping과 약간 다르게 작동한다. ping이 장치가 네트워크 상에 존재하는지 여부를 알려준다면 traceroute는 발신자와 수신자 간에 패킷이 통과하는 경로를 알려준다. 특히 전체 네트워크가 본인의 관리 제어 하에 있는 경우 매우 유용하게 사용된다. 예를 들어, 사내 인터넷이 두개의 다른 통신사(ISP)와 연결이 되어 있지만 네트워크 정책에 따라 모든 트래픽은 먼저 첫번째 ISP로만 통신을 해야 한다고 가정했을 경우 이를 확인하기 위해 traceroute를사용하여 간단한 사실 여부를 확인할 수 있다.
일반적인 라우터(홉 장치)는 패킷을 수신하면 TTL(Time-to-Live)을 감소시키고 패킷을 다음 홉으로 전달하려고 시도하게된다. 하지만 TTL이 0에 도달하면 장치는 패킷을 삭제하고 ICMP 시간 초과 오류 패킷(ICMP type 11 code 0)을 보낸 장비에게 되돌려 보내게된다. Traceroute는 이 동작을 사용하여 다음과 같이 발신자와 수신자 간의 홉을 결정한다.
첫 번째 패킷에서 TTL은 1로 설정한 다음 첫번째 홉에 도달하면 해당 장치는 TTL을 0으로 감소시킨 후 패킷을 삭제하고 ICMP 시간 초과 오류 메시지를 발신자에게 반환 해 준다. 따라서 traceroute를 통해 ICMP 메세지를 보낸 장비는 traceroute를 통해 첫 번째 장치까지 가는 경로를 파악하게된다. 그런 다음 Traceroute는 TTL 값이 2인 두 번째 패킷을 내보낸다. 다음 홉은 이 패킷을 수신하여 1을 줄여 TTL을 1로 만든다.
다음 홉은 패킷(현재 TTL이 1임)을 다음 장치로 전달한다. 해당 장치는 TTL을 0으로 감소시키고 패킷을 삭제하고 ICMP 시간 초과 오류 메시지를 발신자에게 반환한다. 이제 traceroute를 통해 두 번째 장치까지 가는 경로를 알게된 것이다. 목적지에 도착할 때까지 이 과정을 반복하게된다. ping과 마찬가지로 Traceroute도 RTT를 측정하지만 이는 발신자와 경로의 각 장치 간에 수행되므로 ping 에서와는 다른 의미를 가지고 있다.
참고: *nix 기반 시스템에서 Traceroute는 발신자에서 대상으로 UDP 패킷을 보낸다. Windows 시스템에서 Traceroute는 ICMP 에코 요청 패킷을 사용한다. Windows에서는 tracert로 입력하고 *nix 계통의 운영체제에서는 traceroute로 입력을 해서 사용한다. 아래는 구글로 traceroute를 실행 해 본 예이다.
C:\Users\jdoe>tracert www.google.com
Tracing route to www.google.com [2404:6800:4006:80f::2004]
over a maximum of 30 hops:
1 2 ms 1 ms <1 ms 2001:8003:220b:200::1
2 11 ms 13 ms 129 ms 2001:8003:0:bdf:f0:2:13:0
3 123 ms 11 ms 12 ms ae10.chw-ice401.sydney.telstra.net [2001:8000:0:2030:228:235:0:2]
4 * * 11 ms bundle-ether35.chw-core20.sydney.telstra.net [2001:8000:0:2030:228:235:0:1]
5 * 10 ms * bundle-ether1.chw-edge803.sydney.telstra.net [2001:8000:0:2030:228:22e:0:2]
6 11 ms 10 ms 10 ms goo2503079.lnk.telstra.net [2001:8000:103:d9::2]
7 * 12 ms * 2001:4960::12:0:a152
8 16 ms * 11 ms 2001:4960:0:1::424d
9 12 ms 10 ms 11 ms syd09s25-in-x04.1e100.net [2404:6800:4006:80f::2004]
Trace complete.
위의 출력에서 traceroute는 발신자와 수신자 사이의 경로에 있는 모든 장치와 발신자와 해당 장치 사이의 RTT를 발견한다. 기본적으로 traceroute는 각 장치에 3개의 패킷을 전송하므로 각 장치에 대해 3개의 RTT 값을 가진다. 또한 장치 중에 세 개의 별표(*)가 표시된다면 이는 장치가 ICMP트래픽을 필터링하도록 구성되었기 때문일 것이다. 위 예에서는 IP버젼 6를 사용하는 것을 알수 있으며 이 말은 곧 icmp도 버젼 6를 사용한다는 말이다. 마지막으로 일부 IP 주소가 호스트 이름으로 확인되는 것을 볼 수 있다. 이것은 역방향 DNS의 동작으로 traceroute를 실행할 때 기본적으로 활성화된다.
위 동작을 wireshark에서 캡쳐해 보았을 경우는 아래와 보일 것이다. 만약 wireshark가 현제 본인 PC에 설치되어 있다면 한번 실행해 직접 눈으로 확인하길 추천한다.
3. mtr
MTR은 사실상 ping과 traceroute를 구성하는 두 가지 유틸리티이다. MTR이 무엇인지 한번 살펴보자. 대부분의 시스템에서 기본적으로 활성화되어 있는 Ping 및 Traceroute와 달리 MTR를 사용하려면 시스템에 먼저 설치를 해야한다.
참고: 다양한 운영 체제에 대한 설치 가이드는 아래 링크에서 찾을 수 있다.
https://docs.nexcess.net/article/how-to-install-and-launch-mtr.html
ping 및 Traceroute와 마찬가지로 mtr 명령 다음에 대상 주소/호스트 이름을 사용하여 MTR을 실행하면된다.
참고: *nix 계통 시스템에서는 root 권한(sudo/wheel)을 사용하여 mtr 명령을 실행해야 할 수도 있다.
기본적으로 MTR을 실행하면 대상(및 경로의 장치)을 지속적으로 폴링하여 연결에 대한 실시간 정보를 제공해준다. 동작을 중지하려면 CTRL+C 조합을 사용하거나 q 키를 누르면된다.
CentOS8리눅스 서버에 mtr 설치 커멘드
[jdoe@centos8 ~]$ sudo yum install mtr
[sudo] password for jdoe: **********
mtr 사용 예
[jdoe@centos8 ~]$ mtr www.google.com
위 출력에서 볼 수 있듯 MTR은 ping(RTT 및 패킷 손실)과 traceroute(발신자와 수신자 사이의 경로에 있는 장치)를 결합한 결과를 주기적으로 업데이트하며 보여준다. 이 정보를 사용하여 네트워크에서 다음을 확인할 수 있다.
목적지 장치에 대한 연결: MTR이 목적지에 성공적으로 도착하면 출발지와 목적지 사이에 통신이 되는 것을 알수 있다. 경로에 traceroute를 차단하는 무언가가 있을 수 있다는 것이 염두해두자.
패킷 손실: 패킷 손실 열은 출발지와 도착지 간의 링크 품질을 알려준다. 패킷 손실이 너무 많으면 추가 문제 해결이 필요할 수 있으며 일부 장치가 ping/traceroute/mtr에서 사용하는 패킷의 속도를 제한(또는 필터링)할 수 있으므로 출발지와 목적지 사이의 경로를 따라 패킷 손실이 날 경우가 종종 발생한다.
왕복 시간: 패킷이 출발지에서 목적지로 이동하는 데 너무 오래 걸리면 링크 품질에 문제가 있다고 볼 수 있다. 만약 출발지와 목적지가 나라 또는 바다를 끼고 다른 대륙에 위취하고 있다면 이 사이의 거리가 상당히 멀 수 있기때문에 왕복 시간이 늘어 날 것이다.