모듈의 시간을 정확하게 설정하는 것은 로그 동기화 및 보안 인증서 유효성 검증을 비롯한 모든 작업에 있어 매우 중요합니다. 15.1 버전부터 VOS에는 네트워크 시간 프로토콜(NTP) 데몬(ntpd)의 포팅 버전이 포함되어 제공되므로, 이를 실행할 것을 강력히 권장합니다.
일반적으로 ntpd를 실행하려면 시간 서버 목록을 지정해야 합니다. 시간 서버란 네트워크 상에서 ntpd를 실행하며, 요청하는 모든 호스트에 시간을 제공하는 호스트를 말합니다. 인터넷에는 사용할 수 있는 수많은 시간 서버가 있습니다. 지역별로 서버를 정리해 둔 http://www.pool.ntp.org/en/를 참고해 보세요.
서버를 하나 또는 세 개(혹은 그 이상) 지정하는 것이 좋으며, 절대로 두 개만 지정해서는 안 됩니다. ntpd는 서버들의 응답을 비교하여 어떤 서버를 사용하는 것이 가장 좋은지 판단합니다. 서버를 두 개만 지정하면 ntpd가 판단을 내리지 못해 결국 어느 쪽도 사용하지 않게 될 가능성이 있습니다.
하지만 회사 정책으로 인해 인터넷상의 시간 서버에 접속할 수 없고, 회사에서 지정한 시간 서버도 없는 경우에는 어떻게 해야 할까요? 이 경우 로컬 Microsoft Windows 도메인 컨트롤러(DC)나 백업 도메인 컨트롤러(BDC)를 사용할 수 있습니다. 대부분의 DC와 BDC는 시간 서비스를 제공합니다.
그렇다면 VOS 관리자로서 로컬 DC나 BDC를 어떻게 찾을 수 있을까요? 가장 간단한 방법은 직접 물어보는 것이지만, 그게 불가능하다면 패킷 모니터를 실행하여 직접 찾아볼 수 있습니다. 워크스테이션과 도메인 컨트롤러 모두 UDP 138번 포트를 통해 주기적으로 브로드캐스트를 전송합니다.
명령어
>system>stcp>command_library>packet_monitor -interface#인터페이스 -numeric
-time_stamp -verbose -pkt_hdr -hex_header -hex_dump -length 1500 -filter -port 138
|
| 그림 1 – packet_monitor 명령어 |
이 명령어를 실행하면 해당 브로드캐스트가 표시됩니다( INTERFACE 부분을 사용자의 IP 인터페이스 이름으로 반드시 교체해 주세요). 안타깝게도 타임 서버를 찾으려면 패킷 내의 16진수 데이터를 확인해야 하며, 처리해야 할 패킷이 많을 가능성이 높으므로 패킷을 파일로 덤프해야 합니다. 제 pm.cm 명령 매크로(매크로는 여기에서 확인할 수 있습니다)는 출력 파일을 자동으로 생성하고, 트레이스를 백그라운드 프로세스로 실행합니다. 출력 파일의 이름은 pm.(날짜).(시간).out이 됩니다. 명령어는 다음과 같습니다.
pm#INTERFACE -no_arp -no_icmp -port 138 |
| 그림 2 – pm 명령어 매크로 |
추적 작업을 어떤 방식으로 시작하든, 15~20분 동안 실행하면 네트워크에 있는 각 DC 및 BDC로부터 브로드캐스트를 수신할 수 있을 것입니다. 다음으로 ‘c0 3’ 및 ‘c0 2’라는 문자열이 포함된 줄을 찾으십시오. 즉, 소문자 C, 0, 공백 4개, 그리고 3 또는 2 중 하나가 포함된 줄입니다. 이 숫자는 오프셋 c0에 있는 바이트의 상위 니블에 해당합니다. 해당 바이트는 다음과 같이 디코딩할 수 있습니다.
ABCD EFGH; ^^^^ ^^^^; |||| ||||-- 호스트는 워크스테이션입니다; |||| |||--- 호스트는 서버입니다; |||| ||---- 호스트는 SQL 서버가 아닙니다; |||| |----- 호스트는 도메인 컨트롤러가 아닙니다; ||||------- 호스트는 백업 도메인 컨트롤러입니다; |||-------- 호스트는 시간 서버입니다. ||--------- 호스트는 Apple 호스트가 아닙니다. |---------- 호스트는 Novell 호스트가 아닙니다. |
| 그림 3 – 서버 유형 바이트 디코딩 |
보시다시피 처음 두세 개를 검색한다고 해서 모든 타임 서버를 찾을 수 있는 것은 아니지만, 노벨이나 애플 전용 사이트를 운영하지 않는 한 적어도 하나의 DC나 BDC는 찾을 수 있을 것입니다.
d pm.11-02-06.17:25:06.out -match 'c0 2'
ready 17:47:13
d pm.11-02-06.17:25:06.out -match 'c0 3'
%phx_vos#m15_mas>SysAdmin>Noah_Davids>pm.11-02-06.17:25:06.out 11-02-06 17:47
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
ready 17:47:29
|
| 그림 4 – 타임 서버 및 백업 도메인 컨트롤러와 일치하는 packet_monitor 기록 |
단순히 “c0” 행을 찾는 것만으로는 충분하지 않습니다. 패킷을 보낸 호스트의 주소도 찾아야 합니다. >system>gnu_library>bin 디렉터리에 있는 grep 명령어를 사용하면 여러 행을 일괄 검색할 수 있습니다.
grep -e 'c0 3' -e 'c0 2' -e UDP pm.11-02-06.17:25:06.out
. . . .
UDP from 192.168.33.180.138 to 192.168.33.255.138 Cksum 7ca3, 220 data bytes.
UDP from 192.168.33.249.138 to 192.168.33.255.138 Cksum c89a, 209 data bytes.
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
. . . .
UDP from 192.168.33.50.138 to 192.168.33.255.138 Cksum 9526, 193 data bytes.
UDP from 192.168.33.248.138 to 192.168.33.255.138 Cksum d05f, 209 data bytes.
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
. . . .
UDP from 192.168.33.202.138 to 192.168.33.255.138 Cksum cf35, 219 data bytes.
UDP from 192.168.33.253.138 to 192.168.33.255.138 Cksum 9505, 209 data bytes.
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
. . . .
UDP from 192.168.33.131.138 to 192.168.33.255.138 Cksum aa35, 222 data bytes.
UDP from 192.168.33.252.138 to 192.168.33.255.138 Cksum 7343, 209 data bytes.
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
. . . . .
|
| 그림 5 – 탐지된 타임 서버를 보여주는 packet_monitor 출력 결과 |
타임 서버의 주소는 “c0” 줄 바로 위에 표시되어 있습니다. 위 그림에서는 192.168.33.249, 192.168.33.248, 192.168.33.253, 192.168.33.252를 확인했습니다.
자신을 타임 서버로 표시하는 호스트들을 확인했으니, 이제 이들이 제대로 작동할지 어떻게 확인할 수 있을까요? ntpdate 명령어를 사용하여 각 타임 서버에 수동으로 쿼리를 보낼 수 있습니다. “-q” 옵션을 사용하면 타임 서버에 쿼리만 보낼 수 있으며, 이 단계에서는 ntpdate가 모듈의 시간을 설정하지 않도록 해야 합니다.
ntpdate -q 192.168.33.248
호스트 192.168.33.248 및 서비스 ntp를 검색 중...
호스트 발견: dc48.noahslab.stratus.com
서버 192.168.33.248, stratum 4, 오프셋 -0.117418, 지연 0.04202
2월 6일 17:53:10 ntpdate[1427079382]: 시간 서버 192.168.33.248 오프셋 -0.117418초 조정
17:53:10 준비 완료
ntpdate -q 192.168.33.249
호스트 192.168.33.249 및 서비스 ntp 검색 중
호스트 발견: dc49.noahslab.stratus.com
서버 192.168.33.249, stratum 4, 오프셋 -0.038709, 지연 0.04355
2월 6일 17:53:25 ntpdate[1427079382]: 시간 서버 192.168.33.249 오프셋 -0
+.038709 초 조정 완료
준비 완료 17:53:25
ntpdate -q 192.168.33.252
호스트 192.168.33.252 및 서비스 ntp 검색 중
호스트 발견: dc52.noahslab.stratus.com
서버 192.168.33.252, 계층 3, 오프셋 0.015733, 지연 0.04216
2월 6일 17:53:38 ntpdate[1427079382]: 시간 서버 192.168.33.252의 오프셋 0.
+015733 초 조정 완료.
준비 완료 17:53:38
|
| 그림 6 – ntpdate를 사용하여 검색된 시간 서버 테스트 — 정상 작동하는 서버 |
서버 중 하나에 시간을 알리기는 하지만 실제로는 시간을 제공하지 못하도록 막는 방화벽 정책이 설정되어 있다고 가정하면, ntpdate는 다음과 같은 내용을 표시합니다.
ntpdate -q 192.168.33.254
호스트 192.168.33.254 및 서비스 ntp를 검색 중
호스트 발견: dc54.noahslab.stratus.com
서버 192.168.33.254, stratum 0, offset 0.000000, delay 0.00000
2월 6일 17:54:00 ntpdate[1427079382]: 동기화에 적합한 서버를 찾지 못했습니다.
+d
준비됨 17:54:00
|
| 그림 7 – ntpdate를 사용하여 검색된 시간 서버 테스트 — 작동하지 않는 서버 |
사용할 수 있는 시간 서버를 파악했으니, 이제 >system>ntp>ntp.conf 파일을 다음과 같이 작성할 수 있습니다. 검은색으로 표시된 내용은 sample_ntp.conf.17.0 파일에서 가져온 것이며, 새로 추가된 내용은 초록색로 표시되어 있습니다. “server foo.bar.somewhere.com” 줄 앞에 추가된 주석 문자를 확인하십시오 . restrict 문은 다른 호스트가 ntp 데몬에 대해 시간과 무관한 쿼리를 보내는 것을 방지함으로써 시스템의 보안 상태를 강화합니다.
# 서버 지시어는 시간을 어디서 가져올지 지정합니다.
# 각 지시어마다 DNS 또는 IP 값을 하나씩 지정할 수 있습니다.
# server foo.bar.somewhere.com
server 192.168.33.248 burstiburst
server 192.168.33.249 burst iburst
server 192.168.33.252 burstiburst
# 로그 파일의 저장 위치. 적절한 상대 경로를 선택하십시오 - VOS 절대 경로
# 경로명이 올바르게 해석되지 않을 수 있습니다.
logfile >system>ntp>ntp.logfile
# 드리프트 파일 저장 위치.
driftfile >system>ntp>ntp.drift
# 다음 설정은 로컬 호스트를 제외한 모든 호스트의 비시간 쿼리를 차단합니다.
restrict default noquery
restrict 127.0.0.1
|
| 그림 8 – 업데이트된 >system>ntp>ntp.conf 파일 |
ntpd 명령을 실행합니다(>system>ntp 디렉터리에 sample_start_ntpd.17.0 파일이 있습니다). 몇 분 후 다음과 같은 화면이 표시될 것입니다. 192.168.33.252 앞의 “*”는 ntpd가 시간을 동기화할 서버로 해당 주소를 선택했음을 나타냅니다. 192.168.33.248 앞의 “+”는 192.168.33.252에서 응답이 없을 경우를 대비한 또 다른 후보 서버를 나타냅니다. 첫 번째 열에 “*”가 표시된 행이 하나라도 있다면 모듈의 시간이 시간 서버와 동기화될 것임을 알 수 있습니다. 단, 모듈과 시간 서버 간의 초기 시간 차이가 클 경우, 시간이 수렴하는 데 다소 시간이 걸릴 수 있다는 점을 기억하십시오.
ntpq -n
ntpq> peer
remote refid st t when poll reach delay offset jitter
==============================================================================
+192.168.33.248 192.168.33.252 4 u - 1024 377 1.312 -1549.3 639.489
192.168.33.249 192.168.33.252 4 u 626 1024 377 132.423 15.202 27.797
*192.168.33.252 192.168.33.51 3 u 802 1024 377 0.964 -27.486 2.993
|
| 그림 9 – ntpq를 사용하여 시간 동기화 확인 |
마지막으로, ntpd는 클라이언트와 서버 역할을 모두 수행하므로, 한 VOS 모듈에서 실행되면 다른 모듈이나 네트워크상의 다른 모든 장치에 대한 시간 서버 역할을 할 수 있습니다.