CHƯƠNG IV: HỆ THỐNG QUẢN TRỊ MẠNG DỰA TRÊN MÔ HÌNH TÁC TỬ NGƯỜI SỬ DỤNG VÀ CHỨC NĂNG CỦA DỊCH VỤ
4.3. Giải pháp giám sát chức năng của dịch vụ
Các thiết bị không hỗ trợ SNMP không cho phép các thiết bị khác có thể giám sát các thiết bị thông qua thiết bị này. Các thiết bị này sẽ tạo ra một vùng đen không thể giám sát được. Mặt khác, việc khai thác và sử dụng các thiết bị hỗ trợ SNMP các phiên bản khác nhau, của các nhà sản xuất khác nhau cũng gặp rất nhiều khó khăn. Để giải quyết vấn đề này, trong Mục 4.2 của luận văn đã đưa ra một giải pháp dựa trên tác tử người sử dụng đầu cuối, cho phép có thể xác định được chất lượng của hạ tầng mạng tại vị trí của người sử dụng. Điều này đã giải quyết được vấn đề liên kết giữa địa chỉ IP, ID của tác tử người sử dụng với vị trí và vai trò của người sử dụng.
Dựa trên tác tử người sử dụng – EUA, đã khắc phục được ảnh hưởng của các thiết bị không hỗ trợ SNMP, cho phép có thể xác định được lỗi hạ tầng mạng đến máy của người sử dụng. Ngoài ra, khi theo dõi một tập hợp các máy tính cùng kết nối và có thông tin về vị trí địa lý của các máy tính, có thể có các chẩn đoán chính xác hơn về các sự cố của hạ tầng mạng. Tuy nhiên, tác tử người sử dụng chỉ cho phép phát hiện sự cố mạng tự động, không cho phép phát hiện tình trạng các dịch vụ mạng (mail, web, webmail,...) có đảm bảo được các chức năng dịch vụ hay không.
Nếu các tác tử người sử dụng có thể kiểm tra được các chức năng của các dịch vụ, quản trị mạng sẽ có khả năng phát hiện được các lỗi liên quan đến chức năng của các dịch vụ trước người sử dụng, có thể khắc phục trước khi người sử dụng phát hiện ra lỗi này. Đứng trên quan điểm người sử dụng, mức độ sẵn sàng và tin cậy của hệ thống sẽ tăng lên.
Hệ thống giám sát triển khai 2 giải pháp chính:
1. Xây dựng các mô đun phần mềm cho phép giám sát chức năng của dịch vụ mạng và dịch vụ người sử dụng.
2. Xây dựng các agent cho phép các mô đun phần mềm nói trên có thể được cài đặt trong bối cảnh của người sử dụng. Các agent này còn thực hiện thêm chức năng bổ sung là cung cấp các thông tin về vị trí xảy ra sự cố.
Để có thể kiểm tra một dịch vụ có đang được cung cấp một cách bình thường hay không, cần có các yếu tố sau:
Qui trình sử dụng dịch vụ.
Mô đun phần mềm mô phỏng qui trình dịch vụ.
Tài khoản (account/profile) của người sử dụng.
Mô đun ghi nhận kết quả thử nghiệm dịch vụ với account và profile nói trên.
Tuy nhiên, với nhu cầu của người sử dụng, cần xây dựng các kịch bản để có thể giám sát các dịch vụ có chức năng phức tạp hơn. Như vậy với mỗi một dịch vụ cung cấp cho người sử dụng cần xây dựng:
Qui trình sử dụng dịch vụ bao gồm các tương tác giữa phần mềm client và server với sự tham gia của người sử dụng.
Kịch bản thử nghiệm dịch vụ.
Các mô đun phần mềm thử nghiệm dịch vụ.
Mô tả quy trình hoạt động của giao thức POP3:
Hình 20: Mô hình gửi/nhận mail qua Internet.
Trong Hình 14 khi User (địa chỉ IP là 10.0.0.55) muốn nhận mail của người gửi, nó gửi một yêu cầu đồng bộ [SYN] tới mail server (địa chỉ IP là 67.19.193.26).
Mail server nhận được yêu cầu đồng bộ từ user sẽ gửi lại một bản tin [SYN,ACK] báo rằng mail server chấp nhận kết nối.
Phía user nhận được bản tin chấp nhận kết nối này từ mail server thì gửi một bản tin [ACK] trả lời tới mail server là đã nhận được bản tin chấp nhận kết nối.
Ba bước trên là quá trình thiết lập phiên kết nối trong giao thức TCP mà POP3 sử dụng tại cổng 110.
Các bước được thực hiện tiếp theo là:
Mail server sử dụng giao thức POP3 trả lời tới user rằng mail server sẵn sàng truyền mail tới user bằng một bản tin “OK POP3 nhanhoa03”.
User gửi yêu cầu nhận mail là từ một địa chỉ email có account là abc@gmail.com.
Mail server gửi lại một [ACK] sử dụng giao thức TCP báo là đã nhận được yêu cầu của user và phản hồi một yêu cầu (sử dụng giao thức POP3) về phía user phải cung cấp một password.
User cung cấp password cho mail server.
Sau khi mail server nhận được pass của user sẽ phản hồi tới user một bản tin [OK] cho phép user nhận mail.
Sau khi quá trình nhận mail đã hoàn thành thì user sử dụng giao thức TCP gửi bản tin [FIN,ACK] báo với mail server rằng đã nhận được mail và xin kết thúc phiên kết nối, các quá trình tiếp theo đó chính là quá trình kết thúc phiên kết nối trong giao thức TCP.
Ví dụ truy cập POP3 Yahoo mail qua telnet:
Truy cập vào yahoo để xem mail, thực hiện lệnh:
telnet pop.mail.yahoo.com 110
Nếu thành công, bạn sẽ nhận được dòng thông tin sau:
+OK hello from popgate-0.8.0.357900 pop104.mail.gq1.yahoo.com
<nhập tên user>
USER bravery_vn2003 +OK password required.
<nhập mật khẩu>
PASS chbkhn2011b
+OK maildrop ready, 3600 messages (335405983 octets) (410510969)
<Server thông báo đăng nhập thành công, hiển thị số lượng thư là 3600>
Ví dụ về gửi mail sử dụng giao thức SMTP qua telnet Yahoo:
Truy cập vào yahoo để gửi mail, thực hiện lệnh:
telnet smtp.mail.yahoo.com 25
Nếu thành công, bạn sẽ nhận được dòng thông tin sau:
220 smtp203.mail.gq1.yahoo.com ESMTP
<Mail server trả lời với mã 220 báo cho máy gửi biết dịch vụ SMTP đã sẵn sàng>
<Client liên lạc với server và cho biết muốn thiết lập một phiên gửi mail, khi đó client sẽ gửi câu lệnh EHLO đến server>
EHLO
<Server nếu đồng ý sẽ gửi trả lại cho client một code là 250 để cho biết đã sẵn sàng nhận mail>
250-smtp203.mail.gq1.yahoo.com
250-AUTH LOGIN PLAIN XYMCOOKIE 250-PIPELINING
250-SIZE 41697280 250 8BITMIME
<Client gửi câu lệnh để bắt đầu quá trình xác thực Username và Password người gửi>
AUTH LOGIN
<Nếu thành công, mail server sẽ gửi lại code 334 yêu cầu nhập Username>
334 VXNlcm5hbWU6
<Client nhập Username đã mã hóa dưới dạng Base64>
YnJhdmVyeV92bjIwMDM=
<Nếu thành công, mail server sẽ gửi lại code 334 yêu cầu nhập Password>
334 UGFzc3dvcmQ6
<Client nhập Password đã mã hóa dưới dạng Base64>
ZGtia2huY2gyMDExYg==
<Mail server gửi lại code 235 thông báo quá trình đăng nhập thành công>
235 OK, go ahead
<Client dùng lệnh MAIL để khởi động phiên giao dịch. Cú pháp như trên cho bên nhận biết địa chỉ bên gửi (mailbox của bên gửi) để bên nhận gửi thông báo lỗi (nếu có) về bên gửi>
MAIL FROM:<bravery_vn2003@yahoo.com.au>
<Server trả lời với mã 250 cho biết sẵn sàng>
250 OK , completed
<Client muốn gửi cho bao nhiêu người sẽ dùng bấy nhiêu lệnh RCPT kèm theo địa chỉ nhận, bên nhận nếu đúng sẽ trả về mã 250 kèm theo OK>
RCPT TO:<braveryvn2003@gmail.com>
250 OK , completed
<Client báo cho bên nhận biết dữ liệu bắt đầu từ sau từ DATA>
DATA
<Mã 354 báo cho biết đã sẵn sàng nhận mail, kết thúc mail với ký tự CRLF.CRLF>
354 Start Mail. End with CRLF.CRLF
<Nội dung mail, kết thúc bằng ký tự . trên một dòng riêng>
Kiem tra gui mail qua giao thuc SMTP .
250 OK , completed
<Phát lệnh báo kết thúc phiên giao dịch>
QUIT
<Mã 221 đóng kết nối đã thiết lập>
221 Service Closing transmission
Trong ví dụ trên sau khi phiên làm việc kết thúc, mail sẽ được gởi tới địa chỉ mail braveryvn2003@gmail.com.
Các kịch bản sau đây đã được thử nghiệm trên server: mail (POP, IMAP, SMTP), web (login/error/success). Các quá trình thử nghiệm được thực hiện trên
phần mềm Zabbix và được lưu trữ bằng các kịch bản trên server. Việc thực hiện các kịch bản này định kỳ cho phép kiểm tra định kỳ các dịch vụ có được cung cấp đúng theo đặc tả và qui trình hay không. Tuy nhiên, việc kiểm tra các dịch vụ được thực hiện từ phía máy chủ quản trị dịch vụ, nên vẫn chưa phản ánh thực sự khung cảnh sử dụng dịch vụ của người sử dụng, nên vẫn chưa bao trùm được một số kịch bản sự cố. Cần thiết có một cách thức cho phép thực hiện các kịch bản nói trên tại máy tính của người sử dụng. Mô hình tác tử người sử dụng (EUA) có thể được thay đổi để thực hiện được các kịch bản, tuy nhiên cần bổ sung một cơ chế cho phép cập nhật các kịch bản theo kịch bản sử dụng của các dịch vụ. Phần tiếp theo sẽ trình bày giải pháp cho vấn đề này.