지난 포스팅에서는 NTP 서버의 원리와 간략한 구축 방법에 대해 알아보았다. 그리고 이번 포스팅은 - 무려 한 달이 넘는 기간만에 다시 작성한다.. - NTP와 관련된 리눅스 명령어와 ntpd 설정 파일에서 restriction에서 사용하는 기타 옵션에 대해 조금 더 알아보려 한다.
1. ntpstat
ntpstat 명령어는 현재 Linux 시스템에서 NTP 연동 상태를 확인하는 명령어다. 필자는 실제 노트북의 Linux가 상위 Stratum NTP 서버로부터 시간 동기화를 받고 있고, 가상 머신에서 동작중인 Linux가 실제 리눅스의 NTP 정보를 참조하고 있다. 따라서 가상 서버에서 ntpstat 명령어를 사용하면, 다음과 같이 정상적으로 NTP가 동작중이라는 문구가 출력된다.
이번에는 클라이언트인 가상 Linux에서 ntpd 서비스를 중지한 뒤, ntpstat 명령어를 사용해보자. ntpd 서비스가 중지되는 경우, ntpstat의 결과는 다음과 같이 ntpd 서버가 동작중이냐는 물음으로 끝나게 된다.
다시 ntpd 서비스를 시작하고 ntpstat 명령어를 치면, 의외로 동기화가 진행되지 않았다는 문구가 출력된다. 이는 ntpd 서비스가 가동이 시작되면 상위 Stratum NTP로 질의를 던지고 이 질의에 대한 답변을 받는데 시간이 걸리기 때문이다.
참고로, Linux 자체 방화벽에서 NTP 통신 포트인 UDP/123을 막아놓은 경우, 아무리 시간이 지나도 NTP 동기화는 진행되지 않는다.
2. ntpdate 명령어
ntpd 클라이언트 서버에서 시간 동기화를 진행하는 방식은 다음과 같다. 먼저, 클라이언트에서 시간 동기화를 요청하는 query 패킷을 상위 NTP 서버로 전달한다. 이 패킷을 Request 패킷이라고 하며, NTP 서버에서는 클라이언트로부터 전달받은 Request 패킷에 대한 답신으로 Transmit 패킷을 돌려준다. 이 Transmit 패킷의 내용을 토대로 클라이언트는 시간을 보정하는 작업을 진행하게 된다.
클라이언트 서버에서 Request 패킷을 전송하는 주기는 ntp.conf에 정의할 수 있다. 별도로 설정이 되어 있지 않다면 64초에 한 번씩 Request 패킷을 전송하여 시간을 동기화하려고 시도한다. 하지만, 이 주기가 매우 길게 설정이 되어 있는 경우, ntpd 서비스를 막 구동한 상태이거나 재시작을 시작한 상태라면 즉각적으로 시간 정보를 받아오지 않고 설정 주기가 끝날때까지 기다려야되는 경우가 발생한다.
위의 경우는 클라이언트 서버에서 ntpd를 재시작 하기 전 시스템 시간을 변경하고, ntpd 재시작 이후 시간이 보정되었는지 확인한 결과이다. 필자가 현재 Request 패킷 전송 주기를 512초로 설정해놓은 탓에, 클라이언트가 아직 NTP 서버에게 Request를 날리지 못한 상황이다. 이 상태에서 ntpdate 명령어를 사용하면 다음과 같이 시간이 보정되는 것을 확인할 수 있다.
특이하게도, 시간 간극이 맞지 않는 상황에서 이 명령어를 사용하면 자동으로 NTP 서버의 시간과 동기화가 된다는 글이 많은데, 실제 필자가 테스트한 결과 ntpdate 명령어는 NTP 서비스가 재시작되는 경우에 한해서만 제대로 작동되는듯 하다.
*** 주의!! rdate 명령어
rdate 명령어는 옵션이 적어서 사용법은 매우 간단하다. 다만 주의해야 할 점이 하나 있는데 rdate 명령어로 전달되는 쿼리의 통신 프로토콜과 포트는 일반 NTP 통신에서 사용하는 프로토콜/포트와 다르다는 점이다. NTP가 UDP/123을 이용하여 통신을 하는 반면 rdate는 TCP 또는 UDP 37번을 사용한다.
이 말이 무슨 말이냐 하면, rdate 명령어는 ntpd 서비스와 관계가 없는 명령어라는 소리다. rdate 명령어를 ntpd 서비스로 운영하는 NTP 서버에 열심히 날려봐야 아래와 같이 Connection Refused 라는 문구만 계속 나타나는 것을 확인할 수 있다(심지어 방화벽이 다 열려 있음에도)
찾아본 바로, rdate 명령어가 ntpdate보다 훨씬 이전에 나온 명령어라 ntpd를 사용하는 서버와는 호환이 되지 않는듯 하다. 그래도 국내에서 제공하는 대부분의 공인 NTP 서버들은 rdate 명령어를 사용하여 시간 동기화를 하는 것이 가능하다. rdate -s {NTP 서버 IP}를 입력하면 동기화가 진행된다.
3. ntpq -p 명령어
ntpq 명령어는 NTP 서버에 쿼리를 날리는 명령어다. ntpq 명령어를 직접 입력해보면 아래와 같이 ntpq 내의 명령어를 사용할 수 있는 Interactive 모드로 전환되는 것을 알 수 있다.
그러나 ntpq의 Interactive 모드로 쿼리를 날릴 일이 흔치는 않다. 사실상 NTP 서버라는 것이 진짜 전문적으로 사용하는 것이 아닌 이상 그냥 서비스만 구동시켜놓고 클라이언트를 연동하는 것이 전부인지라... 개인 영역으로 서버를 구축하면서 ntpq 쿼리를 사용할 일은 아예 없다고 봐도 된다.
하지만, ntpq 명령어 입력 시, 옵션 -p와 함께 사용하면 이야기가 조금 달라지는데, 이 p(print) 옵션을 통해, 현재 내가 접속중인 서버가 어떤 NTP에 연결되어 있는지를 확인할 수 있기 때문이다. 아래와 같이.
상단의 사진은 필자가 내부망에 사용할 용도로 외부 NTP 서버와 연동한 Linux 서버에서 뜬 ntpq -p 명령어 결과이고, 아래는 이 Linux NTP 서버와 연동된 가상머신 Linux에서 얻은 ntpq -p 명령어 결과이다. 필드값이 얼마 되지 않으니 하나씩 살펴보자.
(1) remote
먼저 명령어 결과의 가장 좌측은 remote라고 적혀있는 필드다. 이 필드는 현재 서버가 NTP 클라이언트로 동작하고 있다면, 시간 정보를 참조하는 상위 NTP 서버의 호스트명이 무엇인지를 나타내어준다. 첫 번째 Linux에서 필자는 time.bora.net과 time.nist.gov 두 곳에서 시간 정보를 받도록 설정해놓았기 때문에 두 서버의 정보가 모두 표시된 것을 확인할 수 있다. 반면 가상 머신은 이 Linux(172.30.1.51) 하나로부터만 시간 정보를 제공받도록 ntp.conf에 설정해놓았다. 따라서 그 결과값 역시 하나만 출력되는 것을 알 수 있다.
remote 필드의 앞부분에는 하나의 결과에 * 표시가 달려있는 것을 볼 수 있는데, 이 * 표시는 여러 대의 상위 NTP 서버가 등록되어 있는 경우, 현재 시간 연동을 진행한 NTP 서버를 나타낸다. * 대신 + 표시가 뜨는 경우, 연동을 진행할 수 있는 상태이나 이미 먼저 연동된 서버가 존재하기 때문에 직접 연동이 진행되지 않았다는 의미다. 아무것도 표시가 되지 않는 경우도 있는데 이는 ntp.conf에 등록된 서버이다. network 문제나 다른 원인으로 인해 해당 NTP 서버와 연결이 진행되지 않음을 의미한다. 보통 ntpd 서비스를 재기동한 직후 ntpq -p 명령어를 입력해보면 아무것도 표시가 되어 있지 않는 결과를 확인할 수 있다.
(2) refid
refid 필드는 서버가 시간 정보를 참조하는 상위 NTP 서버가 바라보는, 그러니까 두 단계 상위의 NTP 서버 IP 주소를 나타낸다. 가상 리눅스 서버는 172.30.1.51의 NTP 서비스로부터 시간을 제공받고 있고, 그 상위의 NTP는 132.163.96.3 주소를 가지는 NTP 서버라는 말이다. 실제 이 아이피를 인터넷에서 검색해보면 아래와 같이 NTP 서버임을 알 수 있다.
만약, 가상 서버 상단의 NTP 서버에서 time.nist.gov가 아닌 time.bora.net으로 시간 참조 서버를 변경하게 되면, 가상 서버에서 ntpq -p 명령어 결과 역시 refid 값이 변경되어 표시되게 된다.
(3) st(stratum)
다음 필드는 st라고 적혀있는 필드인데 이는 stratum을 의미한다. 현재 연동된, 또는 등록된 NTP 서버의 Stratum 레벨을 표시한다.
잘 보면 알겠지만, 가상 서버 Linux 가 참조하는 NTP 서버의 stratum 레벨은 2이다. 그리고 그 NTP 서버가 참조하는 time.nist.gov 의 stratum 레벨은 1이다. refid와 마찬가지로, 만약 가상 서버 상위의 NTP 서버가 time.bora.net을 참조하게 된다면 가상 머신의 ntpq -p 결과 역시 172.30.1.51 NTP 서버의 Stratum 레벨이 4로 변하게 된다.
(4) t(type)
다음 t 필드는 type의 약자인데, 시간 정보의 제공 방식에 대해 기술된 필드다. Unicast, multicast, broadcast 그리고 multicast 중 하나를 표시하는데, 이는 ntp.conf의 설정을 어떻게 하느냐에 따라 다르게 나타나는 듯 하다. 필자가 이 부분은 제대로 된 자료를 찾지 못한 탓에 조금 부실하게 작성하고 넘어가야 할 듯 하다(추후 정리가 되는데로 업데이트 할 예정이다).
(5) when
when 필드는, 클라이언트 서버가 NTP서버와 시간이 동기화 된 이후 얼마나 시간이 지났는지 나타낸다.
위의 사진은 필자가 가상 Linux에서 ntpq -p 명령어를 1초마다 입력한 결과이다. 자세히 보면 when 값이 56초에서 1로 변경된 것을 알 수 있는데, 이 사이에 NTP 서버로 쿼리를 날려 시간 동기화를 진행했기 때문이다. 보통 상위 NTP 서버와의 통신에 문제가 없는 경우, 대부분 when 값은 바로 우측의 poll 값을 초과하여 나타나지 않는다(물론, Network 문제가 있는 경우, 초과할 수 있다).
(6) poll
poll 필드는 현재의 서버가 상위 NTP 서버로 쿼리를 날리는 빈도를 표시한다. 바로 위의 사진을 보면 172.30.1.51 NTP 서버로 쿼리를 날리는 주기인 poll 값이 64로 되어 있는데, 이는 최소 64초에 한 번 쿼리를 날리도록 설정되어 있다는 의미이다.
이 poll 값은 ntp.conf 파일에서 변경할 수 있다.
상위 NTP 서버 설정을 진행하는 단락을 보면, iburst 옵션 뒤에 "minpoll 숫자 maxpoll 숫자"가 적혀있는 것을 볼 수 있다. 이 문구가 의미하는 바는 다음과 같다.
" 최소 2^6 초마다 한 번 씩 상위 NTP 서버로 쿼리를 날리고, 그게 불가능하다면 최대 2^12초 내에 쿼리를 날려라"
2^6이면 64라는 값이 나오며, 이는 우리가 ntpq -p의 poll 필드에서 보았던 값과 정확히 일치한다. maxpoll 값은 출력되지 않지만, 2^12초는 대략 68분이 나온다. 즉, 64초에 한 번 씩 NTP와 동기화를 진행하되, 그게 불가능하다면 68분 내에 동기화를 진행하라는 의미이다. 일반적으로 *표시가 되어 있음에도 when 값이 minpoll 값을 초과한 경우, NTP 연동이 제대로 이루어지지 않는 것으로 판단한다.
ntp.conf 파일에 입력가능한 minpoll의 최소값은 3(8초), maxpoll은 최대 17(36시간)이다. minxpoll과 maxpoll을 정의하지 않은 경우 기본값은 6(64초), 10(1024초)로 설정된다. 너무 빈번하게 쿼리를 날리면 시간은 정확하게 보정할 수 있으나, NTP 서버는 물론 클라이언트도 빈번한 쿼리 생성으로 인해 부하가 생성될 가능성이 많아진다. 반면, 쿼리를 날리는 빈도가 적어지면 부하는 적어지지만 시간이 틀어질 가능성이 조금 더 높아진다.
(7) Reach
Reach 값은 NTP 서버와의 최근 8번 동기화 진행 시 성공 여부를 8진법으로 표시한 결과를 나타낸다. 말이 조금 어려운데, 만약 위의 사진에서 클라이언트 서버가 time.bora.net와 최근 8번의 동기화 성공 여부를 다음과 같이 표시한다고 해보자.
1: 성공
0: 실패
그리고 8번 모두 성공했을 때, 결과는 아래와 같을 것이다.
1111 1111
이를 10진수로 변경했다가 8진법으로 바꾸면
1111 1111 -> 255(10진) -> 377(8진, 64 * 3 + 8 * 7 + 7)
이 된다. 즉, 377이라는 값은 최근 8번의 동기화에서 실패가 단 한 차례도 없었음을 의미한다.
이제 아래의 결과를 보자. 값이 320이다.
320(8진법) -> 192 + 16 = 208 -> 1000 1000(2진법)
4번에 한 번 꼴로 동기화에 성공했음을 알 수 있다. NTP는 UDP 프로토콜을 사용하기 때문에 중간에 소실될 수도 있어 Network 상태가 좋지 않다면 이런 결과가 나타날 수도 있다. 뭣 때문인지는 몰라도 time.nist.gov는 시간 동기화가 잘 진행되지 않는듯 하다
즉, reach 필드의 결과는 0부터 377 사이의 값이 출력되며 377 값이 나오면 아무런 이상없이 연동이 잘 진행되고 있다고 생각하면 된다.
(8) Delay와 Offset
Delay와 Offset은 시간 차이를 표시하는 필드다. 시간 동기화를 진행했는데 시간 차이가 있다니 의외라고 생각하시는 분들이 있을 듯 한데, 실제 NTP 서버, 그리고 로컬 컴퓨터와 시간은 약간 차이가 있다.
먼저 로컬 컴퓨터부터 보자. 로컬 컴퓨터는 하드웨어 자체의 시간과 운영체제 시간이 별도로 운영된다. 아무런 설정을 하지 않은 상태라면 보통 운영체제(Linux라고 가정하자)가 하드웨어 시간을 따라간다. 그러나 date 명령어로 시간을 하루 이상 변경하게 되면, 운영체제의 시간은 하드웨어 시간과 24시간 차이가 발생하게 된다. 보통 재부팅을 진행하면 운영체제의 시간이 다시 하드웨어 시간을 참조하여 정상적인 시간으로 돌아온다. 궁금하신 분들은 시간 변경했다가 재부팅한 뒤 시간이 원래대로 복구되는지 확인해보시면 되겠다.
NTP 서버와의 연동도 마찬가지다. 클라이언트에서 NTP 서버로 쿼리를 날리고, 그 응답을 받는 과정 역시, 신호가 케이블을 타고 전달되었다가 돌아오는 시간이 분명 존재한다. 물리적 거리가 멀면 멀수록 더 차이가 날 것이고 가까우면 그 차이가 조금은 줄어들 것이다.
Delay 필드는 NTP로 동기화된 클라이언트의 시간과, 실제 NTP 서버의 시간 차이 * 2를 의미한다. 단위는 millisecond이며 위의 결과로만 보면 실제 NTP 서버와 클라이언트 운영체제의 시간이 약 0.003초 차이가 나는 것을 알 수 있다.
time.bora.net과 time.nist.gov 의 delay 결과를 보면 그 차이가 극명한데, 아까 time.nist.gov의 경우 미국에 위치한 NTP 서버이다. 따라서 국내에 위치한 time.bora.net 서버보다 도달하는데 극히 오랜 시간이 걸린다.
Offset의 경우, NTP로 동기화된 클라이언트 시간과, 클라이언트의 하드웨어 시간 사이 차이를 나타낸다. 즉, 위의 스크린샷 역시, 하드웨어 시간과 NTP 동기화된 운영체제 시간 사이 차이가 0.002초 정도 차이가 난다는 말이다.
이번 포스팅에서는 NTP 서버 구축 후, 수동으로 시간을 동기화하는 명령어 및 NTP 서버와의 동기화 상태에 대해 확인하는 명령어(ntpstat, ntpq -p)에 대해 알아보았다. 필자가 이 쪽 업계에 발을 들이기 전에 NTP와 관련된 내용은 전혀 배운바도 없었던데다가, 연말이라 일이 미친듯이 몰려 바쁜 탓에 무려 한 달 넘는 기간에 걸쳐 작성한 포스팅을 이제서야 올리게 되었다(사장님, 내년 연봉은 많이많이 인상해주세요). 그러다보니 내용적인 면도 다른 포스팅에 비해 많이 부실한 편이다. 글을 읽어주시는 분들께 양해부탁드린다.
다음 포스팅은... 시간이 되는대로 메일 서버 구축 및 메일 전송을 진행해보려 한다.
Fin.
'IT Security > LINUX Basic' 카테고리의 다른 글
| 36. Linux - 메일서버 구축 및 메일 전송2 - Postfix 설정 및 메일 전송 (0) | 2021.05.02 |
|---|---|
| 35. Linux - 메일서버 구축 및 메일 전송 1, 개요 (0) | 2021.01.23 |
| 33. Linux - NTP 서버 설치 및 시간 동기화1 (0) | 2020.10.25 |
| 32. Linux - rpm 명령어 기본 사용법3(의존성 외) (0) | 2020.10.25 |
| 31. Linux - rpm 명령어 기본 사용법2(설치/삭제) (0) | 2020.10.24 |
댓글