Đề tài Tổng quan về quản trị mạng

à message sử dụng cho Remote Telemetry Units (RTUs) khi có các cảnh báo. Và sẽ thông báo đến SNMP manager ngay sau khi có sự cố xảy ra thay vì phải chờ manager yêu cầu (hỏi). 43 Hình 2.7 Kiến trúc quản trị mạng SNMP a) Kiểm soát theo Trap Nếu một trạm quản trị, quản trị số lượng lớn các Agent, và nếu mỗi Agent duy trì một số lượng lớn các đối tượng, thì sẽ không thực tế khi các trạm quản trị kiểm soát theo kiểu “bỏ phiếu” tất cả các Agent với các đối tượng dữ liệu có thể đọc. Do vậy, SNMP và MIB liên quan được thiết kế sử dụng một kỹ thuật được gọi là kiểm soát theo Trap. Tại thời điểm ban đầu, và tại các khoảng thời gian theo chu kỳ như một lần trong ngày, trạm quản trị kiểm soát theo kiểu “bỏ phiếu” tất cả các Agent để biết vài thông tin mấu chốt như các đặc tính giao tiếp; một vài thống kê về tính năng giới hạn như là số lượng trung bình các gói tin gửi và nhận trên mỗi giao tiếp trong một khoảng thời gian. Khi các giới hạn này được xác lập, trạm quản trị ngừng kiểm soát theo kiểu “bỏ phiếu” và mỗi Agent có trách nhiệm thông báo cho trạm quản trị về các sự kiện không bình thường. Các sự kiện này được truyền trong thông báo SNMP và được gọi là Trap. Khi trạm quản trị được thông báo do điều kiện bất thường, nó sẽ thực hiện một vài hành động như: kiểm tra trực tiếp Agent vừa thông báo hoặc các Agent lân cận để phát hiện lỗi. Kỹ thuật kiểm soát Agent sẽ tiết kiệm năng lực mạng và thời gian xử lý Agent. b) Uỷ quyền (Proxy) Agen uỷ quyền Thiết bị được uỷ quyền 44 Trạm quản trị Tiến trình quản trị SNMP UDP IP Các giao thức phụ thuộc mạng Hình 2.8 Kiến trúc của Agent ủy quyền Việc sử dụng SNMP đòi hỏi các Agent, cũng như các trạm quản trị, cần phải hỗ trợ một giao thức chung phù hợp như là UDP và IP. Điều này hạn chế trực tiếp đến việc quản trị các thiết bị như modem hoặc bộ nối mà không hỗ trợ giao thức TCP/IP phù hợp. Hơn nữa có thể có nhiều hệ thống nhỏ (các máy tính cá nhân, workstation, các bộ điều khiển có thể lập trình ) phải thực hiện TCP/IP để hỗ trợ các ứng dụng của nó nhưng không muốn phải thêm gánh nặng của SNMP và việc duy trì MIB. Để các thiết bị như vậy không phải thực hiện SNMP, người ta đã đưa ra khái niệm uỷ quyền. Hình 2.8 thể hiện dạng cấu trúc giao thức của một Agent SNMP hoạt động như một thống kê uỷ quyền cho một hoặc nhiều các thiết bị khác, có nghĩa là một SNMP Agent hoạt động thay mặt cho các thiết bị được uỷ quyền. Mọi yêu cầu và trả lời giữa một trạm quản trị và một thiết bị uỷ quyền đều được chuyển thông qua Agent của nó. Agent chuyển đổi các yêu cầu và trả lời hoặc Trap thành dạng giao thức quản trị phù hợp. c) Các toán tử SNMP SNMP chỉ hỗ trợ các toán tử là sửa đổi và duyệt các biến. Đặc biệt, ba toán tử sau có thể được thực hiện trên các đối tượng vô hướng: • Get: một trạm quản trị nhận một giá trị của đối tượng vô hướng từ một trạm bị quản trị. Chức năng ánh xạ Tiến trình Agent Cấu trúc giao thức được thiết bị uỷ quyền sử dụng SNMP UDP IP Các giao thức phụ thuộc mạng Các giao thức phụ thuộc mạng Tiến hành quản trị Các giao thức được thiết bị uỷ quyền sử dụng Các giao thức phụ thuộc mạng 45 • Set: một trạm quản trị cập nhập một giá trị của đối tượng vô hướng cho một trạm bị quản trị. • Trap: một trạm quản trị gửi một giá trị của đối tượng vô hướng không được yêu cầu tới một trạm quản trị. Các toán tử này không có khả năng thay đổi cấu trúc của một MIB bằng cách thêm hoặc bớt các phiên bản đối tượng (thêm hoặc bớt một dòng trong bảng) nhưng có khả năng đưa ra các lệnh để thực hiện các hoạt động. Ngoài ra chúng chỉ cung cấp các khả năng truy cập vào các đối tượng “lá” trong cây nhận dạng đối tượng. Các giới hạn này làm đơn giản việc thực hiện của SNMP song cũng giới hạn khả năng của hệ thống quản trị mạng. d) Truyền thông SNMP Quản trị mạng có thể xem như là một ứng dụng phân tán, nó yêu cầu sự tương tác của một số phần tử ứng dụng mà được một giao thức ứng dụng hỗ trợ. Trong SNMP, các phần tử ứng dụng là các ứng dụng trạm quản trị và các ứng dụng khác mà sử dụng giao thức được hỗ trợ SNMP. Ta có thể coi SNMP là một liên hệ giữa một Agent SNMP và một tập các quản trị SNMP được định nghĩa cục bộ tại trạm bị quản trị do vậy có thể có nhiều Agent cùng sử dụng một tên. Nên trạm quản trị phải duy trì dấu vết của tên truyền thông hoặc tên liên quan với mỗi Agent mà nó muốn truy cập. Mỗi trạm quản trị điều khiển một MIB cục bộ của mình và phải có khả năng điều khiển việc sử dụng MIB đó của một số các trạm điều khiển. Có ba hướng cho việc điều khiển này: • Dịch vụ xác nhận: trạm bị quản trị muốn giới hạn việc truy cập vào MIB với các trạm quản trị cho phép. Trong SNMP, nó khẳng định rằng thông báo là từ nơi nó được yêu cầu. Mọi thông báo từ một trạm quản trị đến một Agent bao gồm cả tên truyền thông. Tên này được khoá mã và thông báo được coi là xác nhận khi người gửi biết khoá mã. • Chính sách truy cập: trạm bị quản trị có thể đưa ra quyền truy cập khác nhau cho các trạm quản trị khác nhau. Bằng cách định nghĩa một truyền thông, một Agent giới hạn việc truy cập vào MIB của nó với một tập các trạm quản trị. Bằng cách 46 dùng nhiều đường truyền thông, một Agent có thể cung cấp nhiều dạng truy cập MIB cho trạm quản trị khác nhau. • Dịch vụ uỷ quyền: một trạm quản trị có thể hoạt động như một uỷ quyền cho các trạm bị quản trị khác. Điều này có thể yêu cầu dịch vụ xác nhận hoặc chính sách truy cập cho các trạm bị quản trị khác trong hệ thống uỷ quyền e) Phiên bản nhận dạng Mọi đối tượng trong MIB có một nhận dạng kèm theo, được định nghĩa bởi vị trí của đối tượng đó trong cấu trúc hình cây của MIB. Khi thực hiện một truy cập vào một MIB, qua SNMP, nó là một phiên bản cụ thể của một đối tượng mà nó muốn. • Các đối tượng cột (colummar Object): với các đối tượng xuất hiện dưới dạng bảng, ta xem như là các đối tượng cột. Các đối tượng cột một mình nó không đủ để nhận dạng đối tượng nên cần có một phiên bản của mỗi đối tượng và một tập các giá trị của các đối tượng INDEX sẽ mô tả một đối tượng vô hướng nhất định trong một hàng nhất định trong bảng. • Các đối tượng hàng (row Objects): Vì đây không phải là các đối tượng “lá” nên không có nhận dạng phiên bản và SNMP không truy cập được. Trong định nghĩa MIB về các đối tượng này, đặc tính ACCESS của chúng được gán là “non- accessible”. • Các đối tượng vô hướng (scalar Objects): để phân biệt sự khác nhau giữa dạng đối tượng và phiên bản đối tượng, SNMP quy định nhận dạng phiên bản của đối tượng vô hướng theo bảng gồm nhận dạng của nó kết hợp với 0. f) Trật tự theo thứ tự Một nhận dạng đối tượng là một chuỗi các số nguyên thể hiện trật tự hoặc cấu trúc nhánh cây của các đối tượng trong MIB, vì vậy chúng thể hiện một trật tự theo thứ tự. Một trật tự của các nhận dạng đối tượng và phiên bản đối tượng là rất quan trọng vì trạm quản trị mạng có thể không biết chính xác cách sắp xếp của MIB mà một Agent đưa cho nó mà cần một cách để tìm kiếm và truy cập các đối tượng mà không cần chỉ rõ tên đối tượng. 2.1.3 Mô tả giao thức SNMP 47 Trong SNMP, thông tin trao đổi giữa một trạm quản trị và một Agent theo dạng thông báo SNMP. Mỗi thông báo bao gồm số hiệu phiên bản thể hiện phiên bản SNMP, Protocol Data Unit (PDU) là định dạng thông điệp mà các nhà quản lý và các đại lý sử dụng để gửi và nhận thông tin. SNMP định dạng PDU chuẩn: • get • getnext • getbulk (SNMPv2 (xem 2.2.1/a) và SNMPv3) • set • getresponse • trap • notification (SNMPv2 (xem 2.2.1/b) và SNMPv3) • inform (SNMPv2 (xem 2.2.1/c) và SNMPv3) • report (SNMPv2 (xem 2.2.1/d) và SNMPv3) Ngoài việc sử dụng các công cụ hỗ trợ thao tác bằng lệnh có những gói thực hiện các thao tác của SNMP, các lệnh set và get được sử dụng như sau: $/usr/sbin/tethereal -i lo -x -V -F libpcap -f "port 161" Lệnh trap sử dụng như sau: $/usr/sbin/tethereal -i lo -x -V -F libpcap -f "port 162" a) Get request Get request là yêu cầu từ NMS, NMS sẽ gửi một yêu cầu đến agent, khi agent nhận được yêu cầu này nó sẽ xử lý với năng lực tốt nhất có thể, nếu một thiết bị như router chẳng hạn nó không đủ tài nguyên để xử lý yêu cầu này thì nó sẽ bỏ qua yêu cầu, còn nếu thiết bị nào vẫn đáp ứng được việc xử lý yêu cầu nó sẽ trả về một getResponse cho NMS. Các đối tượng mà NMS yêu cầu được thể hiện trong 48 getrequest lưu trong biến rằng buộc (binding). Biến này lưu danh sách các đối tượng mà NMS muốn biết theo cú pháp OID=value. Ví dụ: $snmpget cisco.ora.com public .1.3.6.1.2.1.1.6.0 system.sysLocation.0 = "" Đây là một câu lệnh ”snmpget” trên Unix. “cisco.ora.com” là tên của thiết bị, “public” là chuỗi ra, chỉ đây là yêu cầu chỉ đọc (read-only), “.1.3.6.1.2.1.1.6.0” là OID. “.1.3.6.1.2.1.1” chỉ tới nhóm “system” trong MIB. “.6” chỉ tới một trường trong “system” là “sysLocation”. Trong câu lệnh này ta muốn truy vấn Cisco router rằng việc định vị hệ thống đã được cài đặt chưa. Câu trả lời system.sysLocation.0 = "" tức là chưa cài đặt. Câu trả lời của “snmpget” theo dạng của varbind: OID=value. Còn phần cuối trong OID ở “snmpget” là “.0” nằm trong quy ước của MIB. Khi truy vấn một đối tượng trong MIB ta cần chỉ rõ 2 trường “x.y’, ở đây là “.6.0”. “x” là OID thực tế của đối tượng. Còn y được dùng trong các đối tượng có hướng như một bảng và y xác định hàng nào của bảng, với trường hợp đối tượng vô hướng như trường hợp này “y” = “0”. Các hàng trong bảng được đánh số từ số 1 trở đi. Câu lệnh ”get” hữu ích trong việc truy vấn một đối tượng riêng lẻ trong MIB. Khi muốn biết thông tin về nhiều đối tượng thì ”get” tốn khá nhiều thời gian. Câu lệnh “getnext” giải quyết được vấn đề này. Hình 2.9 Trình tự xử lý yêu cầu Get b) getnetxt getnext đưa ra một dãy các lệnh để lấy thông tin từ một nhóm trong MIB. Agent sẽ lần lượt trả lời tất cả các đối tượng có trong câu truy vấn của getnext tương tự như get, cho đến khi nào hết các đối tượng trong dãy. Ví dụ ta dùng lệnh snmpwalk. snmpwalk tương tự như snmpget nhưng không chỉ tới một đối tượng cụ thể nào mà chỉ tới một nhánh nào đó: 49 $snmpwalk cisco.ora.com public system system.sysDescr.0="Cisco IOS Software, C2600 Software(C2600-IPBASE- M), Version 12.3(8)T3, RELEASE SOFTWARE (fc1) Technical Support: Copyright (c) 1986-2004 by Cisco Systems, Inc. Compiled Tue 20-Jul-04 17:03 by eaarmas" system.sysObjectID.0 = OID: enterprises.9.1.19 system.sysUpTime.0 = Timeticks: (27210723) 3 days, 3:35:07.23 system.sysContact.0 = "" system.sysName.0 = "cisco.ora.com" system.sysLocation.0 = "" system.sysServices.0 = 6 Hình 2.10 duyệt cây MIB với lệnh snmpwalk Ở đây ta muôn lấy thông tin của nhóm “system”, agent sẽ gửi trả toàn bộ thông tin của “system” theo yêu cầu. Quá trình tìm nhóm “system” trong MIB thực hiện theo cây từ gốc, đến một nút nếu có nhiều nhánh thì chọn nhánh tìm theo chỉ số của nhánh từ nhỏ đến lớn, system.1 (system.sysLocation), system.2,… 50 c) set request set để thay đổi giá trị của một đối tượng hoặc thêm một hàng mới vào bảng. Đối tượng này cần phải được định nghĩa trong MIB là “readwrite” hay “write-only”. NMS có thể dùng set để đặt giá trị cho nhiều đối tượng cùng một lúc. Hình 2.11 Trình tự thực hiện lệnh set $snmpget cisco.ora.com public system.sysLocation.0 system.sysLocation.0 = "" $snmpset cisco.ora.com private system.sysLocation.0 s "Atlanta, GA" system.sysLocation.0 = "Atlanta, GA" $snmpget cisco.ora.com public system.sysLocation.0 system.sysLocation.0 = "Atlanta, GA" Câu lệnh đầu là dung get để lấy giá trị hiện tại của “system.sysLocation”. Trong câu lệnh snmpset các trường cisco.ora.com và system.sysLocation.0 có ý nghĩa giống với ”get”, còn private để chỉ đối tượng “read-write’, và đặt giá trị mới bằng: s “Atlanta, GA”. Trong đó s tức là đặt giá trị của “system.sysLocation.0” thành kiểu string, và giá trị mới là "Atlanta, GA" . Varbind này được định nghĩa trong RFC 1213 là kiểu string tối đa 255 ký tự: sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The physical location of this node (e.g., 'telephone closet, 3rd floor')." ::= { system 6 } 51 SYNTAX của sysLocation là DisplayString (kích thước từ 0 đến 255). Lệnh snmpset thành công và báo cáo giá trị mới của sysLocation. Khi muốn biết đã thành công hay chưa chỉ cần chạy lại lệnh snmpget: $snmpget cisco.ora.com public system.sysLocation.0 system.sysLocation.0 = "Atlanta, GA" có thể cài đặt nhiều đối tượng cùng lúc, tuy nhiên nếu có một hành động bị lỗi, toàn bộ sẽ bị hủy bỏ. d) Thông báo lỗi của get, getnext, getbulk và set Một số lỗi báo thông dụng của agent xem bảng 2.2 sau: SNMPv1 error message Mô tả noError(0) Không có lỗi tooBig(1) Yêu cầu quá lớn để có thể trả lời được (nhiều yêu cầu trong một câu hỏi) noSuchName(2) OID yêu cầu không tìm thấy, tức OID không tồn tại ở agent badValue(3) Câu lệnh “set” dùng không đúng với các object “read-write” hay “write-only”. readOnly(4) Lỗi này ít dùng. Lỗi “noSuchName” tương đương với lỗi này genErr(5) Dùng cho tất cả các lỗi còn lại, không nằm trong các lỗi trên Bảng 2.2 Một số thông báo lỗi của SNMPv1 2.1.4 Truyền và nhận một Message SNMP a) Truyền Message SNMP Để truyền một trong năm dạng PDU cho một phần tử SNMP khác, phần tử SNMP phải thực hiện các hoạt động sau: • Sử dụng ASN.1 để tạo ra PDU. • PDU này được chuyển sang dịch vụ xác nhận cùng với các địa chỉ nguồn và đích của truyền thông và tên một truyền thông. Dịch vụ xác nhận thực hiện những biến đổi theo yêu cầu sau đó mã hoá hoặc thêm mã xác nhận và trả lại kết quả. 52 • Phần tử giao thức tạo ra một thông báo, thêm vào trường số hiệu phiên bản, tên truyền thông vào kết quả của bước trên. • Đối tượng ASN.1 mới này sau đó được mã hoá sử dụng BER và gửi đến dịch vụ giao vận. b) Nhận Message SNMP Khi nhận một thông báo từ một phần tử SNMP khác, một phần tử SNMP phải thực hiện các hoạt động sau: • Kiểm tra cú pháp cơ bản của thông báo và loại bỏ thông báo nếu cú pháp sai • Kiểm tra số hiệu phiên bản và loại bỏ thông báo nếu không tương hợp. Trong SNMP, chỉ có các đối tượng “lá” trong cây nhận dạng đối tượng, các đối tượng vô hướng là có thể truy cập. Tuy nhiên SNMP có khả năng nhóm các toán tử cùng dạng (get, set, trap) vào một thông báo, do vậy nếu một trạm quản trị muốn nhận các giá trị của tất cả các đối tượng trong một nhóm nhất định tại một Agent nhất định, nó có thể dùng một thông báo đơn, yêu cầu tất cả các giá trị và nhận lại một đáp ứng đơn các liệt kê tất cả các giá trị. Kỹ thuật này có thể làm giảm rất nhiều tải trọng truyền thông của quản trị mạng. Để thực hiện điều đó, các PDU của SNMP đều có trường variable-bindings (mục 2.1.1.4/b). Trường này bao gồm một thứ tự các tham chiếu đến các phiên bản đối tượng cùng với giá trị của các đối tượng đó. c) GetRequest PDU Một phần tử SNMP đưa ra GetRequestPDU thay mặt cho một ứng dụng trạm quản trị. Phần tử bao gồm các trường hợp sau trong PDU: • Dạng PDU: thể hiện một GetRequestPDU. • Request-id: phần tử gửi gán các số như vậy để người dùng mỗi yêu cầu gửi đi đến cùng một Agent là xác định duy nhất. Nó cho phép ứng dụng SNMP liên kết các đáp ứng truyền đến với yêu cầu còn lại, và cũng cho phép một phần SNMP loại bỏ các PDU kép được sinh ra do dịch vụ giao vận không tin cậy. • Variable bindings (các liên kết biến): liệt kê các phiên bản đối tượng có giá trị được yêu cầu. Phần tử SNMP nhận đáp ứng một GetRequestPDU bằng một GetResponsePDU có chứa cùng một request-id. Toán tử GetRequest có tính hạt nhân: hoặc lấy được tất 53 cả các giá trị hoặc không lấy bất cứ giá trị nào. Nếu phần tử đáp ứng có khả năng cung cấp tất cả các giá trị của các biến được liệt kê trong danh sách biến liên kết, thì GetResponsePDU bao gồm trường các liên kết biến với giá trị được cấp cho mỗi biến. Nếu ít nhất một biến không thể cấp giá trị thì sẽ không có giá trị nào được trả về. Các điều khiển sau có thể xảy ra: • Một đối tượng được đặt tên trong danh sách biến có thể không phù hợp với bất kỳ nhận dạng đối tượng nào trong MIB tương ứng, hoặc trên đối tượng là một dạng gộp mà không có giá trị phiên bản tương ứng. Trong trường hợp khác, phần tử đáp ứng trả về một GetResponsePDU có một error-status là noSuchName và một giá trị trong trường error-index là thứ tự của đối tượng bị lỗi trong trường liên kết biến. • Phần tử đáp ứng có khả năng cấp các giá trị cho tất cả các biến trong danh sách nhưng kích thước của GetResponsePDU có thể vượt quá một giới hạn cục bộ. Trong trường hợp này, phần tử đáp ứng trả về một GetResponsePDU có error- status là toobig. • Phần tử đáp ứng có thể không có khả năng cung cấp một giá trị cho ít nhất một trong các đối tượng vì một vài nguyên nhân. Khi đó phần tử đáp ứng trả về một GetRequestPDU với một lỗi error-status là getErr và một giá trị trong trường error-index là thứ tự của đối tượng vị lỗi trong trường liên kết biến. d) GetNextRequestPDU GetNextRequestPDU hầu như giống với GetRequestPDU cả về hình thức PDU lẫn dạng. Chỉ khác nhau như sau: trong GetRequestPDU,mỗi biến trong danh sách biến liên kết tham chiếu đến một phiên bản đối tượng cần trả giá trị còn trong GetNextRequestPDU,với một biến, việc đáp ứng sẽ trả về một giá trị của một phiên bản đối tượng mà là tiếp theo trong trật tự thứ tự (chú ý rằng đây là phiên bản đối tượng tiếp theo chứ không phải đối tượng tiếp theo). Điều này cho phép một trạm quản trị mạng khảo sát cấu trúc của một MIB theo cách động là một cơ chế có hiệu quả trong việc tìm kiếm trong một bảng mà có tất cả các mục là không biết. Gọi một giá trị đối tượng đơn: Khi một trạm quản trị mạng muốn nhận các giá trị của tất cả các đối tượng từ một Agent, nó có thể gửi một GetRequestPDU với một 54 danh sách biến liên kết. Tuy nhiên nếu có bất cứ một đối tượng nào trong danh sách đó không thể trả về một GetResponsePDU được trả về với một thống kê lỗi là noSuchname. Như vậy để chắc chắn nhận được tất cả cá giá trị có thể với GetRequestPDU,trạm quản trị mạng phải gửi lần lượt các GetRequestPDU cho mỗi giá trị biến cần thiết. Trong khi đó, GetResponsePDU sẽ trả về các giá trị phiên bản đối tượng sẵn có và với các giá trị phiên bản đối tượng không có sẵn, giá trị phiên bản đối tượng tiếp theo trong trật tự sẽ được trả về. Rõ ràng đây là cách có hiệu quả hơn để gọi mọi tập các giá trị đối tượng khi có thể có có thất lạc so với sử dụng GetRequestPDU. Gọi các đối tượng không biết: GetNextRequestPDU yêu cầu Agent gọi phiên bản đối tượng tiếp theo xuất hiện theo thứ tự sau nhận dạng đã đưa ra mà không yêu cầu cung cấp nhận dạng của một đối tượng hay phiên bản đối tượng thực. Do vậy một trạm quản trị mạng có thể sử dụng GetNextRequestPDU để thăm dò một MIB và khám phá cấu trúc của nó. Truy cập các giá trị bảng: GetNextRequestPDU là một cách để tìm kiếm một bảng khi nó không biết nội dung của bảng thậm chí không biết cả số hàng trong bảng. Nó sẽ gửi về các GetNextRequestPDU cho đến khi GetResponsePDU của Agent trả về chứa các tên đối tượng không phù hợp với yêu cầu. e) SetRequestPDU SetRequestPDU giống với GetRequestPDU cả về hình thức PDU lẫn dạng, tuy nhiên SetRequestPDU dùng để ghi (thay đổi) thông tin, thuộc tính một đối tượng hơn là đọc giá trị. Do vậy danh sách biến liên kết trong SetRequestPDU bao gồm các nhận dạng phiên bản đối tượng và một giá trị sẽ được gán cho mỗi phiên bản đối tượng trong danh sách. Phần tử SNMP nhận đáp ứng một SetRequestPDU bằng một GetRequestPDU có chứa cùng một request-id. Toán tử SetRequest có tính hạt nhân: hoặc tất cả các giá trị biến được cập nhập hoặc không có giá trị nào cả. Nếu phần tử đáp ứng có khả năng gán tất cả các giá trị của các biến được liệt kê trong danh sách biến liên kết được gửi đến, thì GetResponsePDU bao gồm trường các liên kết biến với giá trị đã gán cho mỗi biến. Nếu có ít nhất một biến không thể gán giá trị thì sẽ không có giá trị nào được gán, các điều kiện lỗi tương tự như trong trường hợp GetRequestPDU sẽ được trả về hoặc với điều kiện lỗi khác: badValue (xảy ra khi có ít 55 nhất một cặp tên biến và giá trị không tương thích nhau để có thể về dạng, độ dài hoặc giá trị thực của giá trị được cung cấp). f) Trap PDU Trap PDU sử dụng để cung cấp cho trạm quản trị một thông báo về một vài sự kiện quan trọng. Khi NMS nhận một trap, nó cần biết phải làm gì để hiểu nội dung thông tin kèm theo thông báo trap này, một trap đầu tiên được nhận xác định thông qua các số ở đây có 7 số cơ bản (xem bảng 2.3), sử dụng enterprises để xác định các nhánh cây của từng hãng cụ thể, ví dụ Cisco định nghĩa tất cả các trap trong cây MIB của riêng hãng theo cấu trúc sau iso.org.dod.internet.private.enterprises.cisco. các số trap này phải được đăng ký với IANA (Internet Assigned Numbers Authority). Ví dụ khi một modem trong trủ rack bị hỏng, rack agent có thể gửi thông tin trap thông báo hỏng cho NMS, với thông tin trap gửi đến ta xác định được rack đó là của hãng nào, và biết được chính xác modem nào bị hỏng trong số các modem khác trong tủ rack… Tên và số của trap Mô tả coldStart (0) Thông báo agent vừa khởi động lại. Tất cả các biến quản lý sẽ được reset, các biến kiểu “Counters” và “Gauges” được đặt về 0. “coldStart” dùng để xác định một thiết bị mới gia nhập vào mạng. Khi một thiết bị khởi động xong, nó gửi một “trap” tới NMS. Nếu địa chỉ NMS là đúng (địa chỉ IP của NMS), NMS có thể nhận được và xác định xem có quản lý thiết bị đó hay không. warmStart (1) Thông báo agent vừa khởi tạo lại, không có biến nào bị reset. linkDown (2) Gửi đi khi một interface trên thiết bị chuyển sang trạng thái “down”. Giá trị biến đầu tiên trong bảng interface sẽ được gửi đi. linkUp (3) Gửi đi khi một interface trở lại trạng thái “up”. Giá trị biến binding của interface sẽ được thiết lập lại. authenticationFailure (4) Cảnh báo khi một người nào đó cố truy cập vào agent đó mà không được xác thực egpNeighborLoss (5) Cảnh báo một EGP lân cận bị “down” enterpriseSpecific (6) Đây là một “trap” riêng, chỉ được biết bởi agent và NMS tự định nghĩa riêng chúng. NMS sử dụng phương pháp giải mã đặc biệt để hiểu được thông điệp này. Bảng 2.3 Mô tả tên và số của Trap RDBMS MIB định nghĩa trong RFC 1697. Một trap được định nghĩa bởi MIB rdbmsOutOfSpace: 56 rdbmsOutOfSpace TRAP-TYPE ENTERPRISE rdbmsTraps VARIABLES { rdbmsSrvInfoDiskOutOfSpaces } DESCRIPTION "An rdbmsOutOfSpace trap signifies that one of the database servers managed by this agent has been unable to allocate space for one of the databases managed by this agent. Care should be taken to avoid flooding the network with these traps." ::= 2 Tên enterprise là rdbmsTraps và số là 2. Trap này có một biến binding là rdbmsSrvInfoDiskOutOfSpaces, đây là một biến vô hướng của MIB. Nó được định nghĩa như sau : rdbmsSrvInfoDiskOutOfSpaces OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times the server has been unable to obtain disk space that it wanted, since server startup. This would be inspected by an agent on receipt of an rdbmsOutOfSpace trap." ::= { rdbmsSrvInfoEntry 9 } 2.2 Quản trị mạng với giao thức SNMPV2 SNMP trước đây phát triển như là một cách lấp chỗ trống để cung cấp khả năng quản trị mạng thấp nhất. SNMP có hai ưu điểm chính: 1. Cấu trúc thông tin quản trị (SMI) và cơ sở thông tin quản trị (MIB) của nó khá đơn giản vì vậy có thể dễ dàng và nhanh chóng thực hiện. 2. SNMP dựa trên cơ sở giao thức kiểm soát cổng đơn giản (SNMP), với một số khối lượng lớn các kinh nghiệm thu được. Từ năm 1988, việc quản trị mạng đã trở nên rất cần thiết cả đối với độ phức tạp của mạng và các môi trường phức tạp hơn. Tuy nhiên, SNMP chưa cung cấp các phương tiện an toàn và khả năng xác nhận nguồn của một thông báo quản trị hoặc chống lại việc nghe trộm. Mặt khác, việc tồn tại tên truyền thông trong phần đầu thông báo cũng là điểm yếu trên quan điểm an toàn. Do vậy nhiều nhà sản xuất đã không cho 57 thực hiện lệnh set trên thiết bị của mình. Để giải quyết vấn đề này, tháng 7-1992 phần “an toàn SNMP” bắt đầu được đưa ra và định nghĩa một SNMP tiêu chuẩn mới là SNMPv2 và từ tháng 10-1992, SNMPv2 được phát triển cho đến tháng 3-1993. Đến năm 1996, những sản phẩm an toàn trong SNMPv2 bị bỏ qua trong khi các phần khác chỉ là sự thay đổi mới hơn và SNMPv2 được gọi là “SNMPv2 trên cơ sở truyền thông” hay SNMPv2C. SNMPv2 có thể hỗ trợ các mạng trung tâm cấp cao hoặc các mạng phân tán. Những điểm nâng cấp chính của SNMP được đưa ra trong SNMPv2 nằm trong các vùng sau: 1. Cấu trúc thông tin quản trị (SMI): SNMPv2 mở rộng SNMPV1 SMI theo một vài cách. Bổ sung thêm các đối tượng mới bằng cách sử dụng Macro để định nghĩa các dạng đối tượng và nâng cấp thông tin liên quan đến một đối tượng. nó cung cấp một quy ước mới để thêm hoặc xoá các hàng trong bảng. 2. Khả năng trao đổi giữa các trạm quản trị: bổ sung InformRequestPDU cho phép một trạm quản trị gửi một thông báo dạng Trap cho một trạm quản trị khác. Các hoạt động giao thức SNMPv2 MIB chứa thông tin lưu chuyển cơ bản về hoạt động của giao thức SNMPv2, và chứa thông tin liên quan đến cấu hình của Agent hoặc trạm quản trị SNMPv2 và có thêm PDU mới: GetBulkRequestPDU cho phép trạm quản trị nhận các khối dữ liệu lớn một cách có hiệu quả. 2.2.1 SMI trong SNMPV2 SMIv2 mở rộng cây đối tượng SMI bằng cách thêm snmpV2 làm cây con của internet (xem hình 2.13) và OID của cây mới này là 1.3.6.1.6.3.1.1 hoặc iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects. Các kiểu dữ liệu mới của SMIv2 được mô tả chi tiết trong bảng 2.4 sau: Kiểu dữ liệu Mô tả Integer32 Giống như INTEGER. Counter32 Giống như Counter. 58 Kiểu dữ liệu Mô tả Gauge32 Giống như Gauge. Unsigned32 Số thập phân từ 0 tới 232 - 1 Counter64 Giống Counter32, nhưng giá trị lớn nhất là 18,446,744,073,709,551,615. Có thể trở về giá trị 0 trong khoảng thời gian ngắn BITS Tên bộ đếm số bít Bảng 2.4 Kiểu dữ liệu mới của SMIv2 Hình 2.13 Cây SMIv2 Định nghĩa một đối tượng trong SMIv2 không khác nhiều so với SMIv1, ở đây có thêm một số trường tùy chọn, cho phép ta điều khiển cách truy xuất (truy cập ) một đối tượng, cho phép thêm các cột vào bảng và giúp bạn mô tả đầy đủ hơn về đối tượng, 59 dưới đây cú pháp của đối tượng được định nghĩa trong SMIv2, sự thay đổi được in đậm (bảng 2.5): OBJECT-TYPE SYNTAX UnitsParts MAX-ACCESS STATUS DESCRIPTION "Textual description describing this particular managed object." AUGMENTS { } ::= { } Các đối tượng Mô tả UnitsParts Mô tả về các đơn vị (ví dụ như giây, phần nghìn giây,...) sử dụng cho đối tượng. MAX-ACCESS Giá trị của tùy chọn MAX-ACCESS là read-only, read-write, read- create, not-accessible, và accessible-for-notify. STATUS Sử dụng giống như trong SNMPv1 MIB. AUGMENTS Trong một số trường hợp nó hữu ích khi thêm cột vào bảng đã có, sử dụng AUGMENTS để mở rộng bảng bằng cách thêm một hay nhiều cột đại diện cho một số đối tượng khác và dẫn đến tên của bảng đối tượng sẽ tăng thêm. Bảng 2.5 Các đối tượng thay đổi trong SNMPv2 so với SNMPv1 a) get-bulk getbulk được định nghĩa trong SNMPv2. Nó cho phép lấy thông tin quản lý từ nhiều phần trong bảng. Dùng ”get” có thể làm được điều này. Tuy nhiên, kích thước của câu hỏi có thể bị giới hạn bởi agent. Khi đó nếu nó không thể trả lời toàn bộ yêu cầu, nó gửi trả một thông điệp lỗi mà không có dữ liệu. Với trường hợp dùng câu lệnh ”getbulk”, agent sẽ gửi càng nhiều trả lời nếu nó có thể. Do đó, việc trả lời một phần của yêu cầu là có thể xảy ra. Hai trường cần khai báo trong “getbulk” là: ”nonrepeaters” và ”max-repetitions”. Nonrepeaters báo cho agent biết N đối tượng đầu tiên có thể trả lời lại như một câu lệnh ”get” đơn mã, repeaters báo cho agent biết cần cố gắng tăng lên tối đa M yêu cầu ”getnext” cho các đối tượng còn lại: b) SNMP Notification 60 Để chuẩn hóa định dạng PDU trap của SNMPv1 do PDU của get và set khác nhau, SNMPv2 định nghĩa NOTIFICATION-TYPE, định dạng PDU của NOTIFICATION-TYPE là để nhận ra get và set. NOTIFICATION-TYPE được định nghĩa trong RFC 2863: linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 } Trong danh sách biến binding đáng lẽ gọi là biến (VARIABLES) sẽ chính xác hơn là OBJECTS tuy nhiên điều này không có gì là khác biệt lớn, đối tượng đầu tiên là một interface cụ thể (ifIndex) chuyển trạng thái từ linkDown sang một trạng thái khác. OID của trap này là 1.3.6.1.6.3.1.1.5.3, hay iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTra ps.linkDown. Dưới đây là cách tạo ra SNMP notification: $ snmptrap -v2c -c public 127.0.0.1 '' .1.3.6.1.6.3.1.1.5.3 ifIndex i 2 ifAdminStatus i 1 ifOperStatus i 1 c) SNMP inform SNMPv2 cung cấp cơ chế truyền thông giữa những NMS với nhau, gọi là SNMP inform. Khi một NMS gửi một SNMP inform cho một NMS khác, NMS nhận được sẽ gửi trả một ACK xác nhận sự kiện. Việc này giống với cơ chế của “get” và “set”. d) SNMP report SNMP report được định nghĩa trong bản nháp của SNMPv2 nhưng không được phát triển. Sau đó được đưa vào SNMPv3 và hy vọng dùng để truyền thông giữa các hệ thống SNMP với nhau. 61 SNMPv2 PDU Agent Generate Agent Receive Manager Generate Manager Receive GetRequest x x GetNextRequest x x Response x x x SetRequest x x GetBulkRequest x x InformRequest x x SNMPv2-Trap x x Bảng 2.6 Quy tắc truyền và nhận tin trong SNMPv2 62 CHƯƠNG 3: GIAO THỨC QUẢN TRỊ MẠNG SNMPV3 3.1 Quản trị mạng với giao thức SNMPV3 SNMPv3 mở rộng SNMP để đạt được hai lĩnh vực chính: việc quản trị và an toàn. Mục đích của SNMPv3 là hỗ trợ kiến trúc theo kiểu module để có thể dễ dàng mở rộng. Theo cách này, nếu các giao thức an toàn mới được mở rộng chúng có thể được hỗ trợ bởi SNMPv3 bằng các định nghĩa như các mô đun riêng. SMI và các dạng thông báo (message) sử dụng trong SNMPv3 cũng hoàn toàn tương tự như trong SNMPv2. Tất cả các Agent SNMP và trạm quản trị SNMP trước đây nay được gọi là các phần tử SNMP. Một phần tử SNMP được tạo ra từ hai phần: một SNMP engine và các phần mềm ứng dụng SNMP. Hình 3.1 Cấu trúc SNMPv3 3.1.1 SNMPv3 Engine Được tạo thành từ các thành phần sau: a) Bộ điều vận (Dispatcher) Bộ điều vận chịu trách nhiệm: 63 • Gửi và nhận các thông báo. Khi nhận được một thông báo, bộ điều vận xác định số hiệu phiên bản của thông báo và sau đó chuyển thông báo đến khối xử lý thông báo tương ứng. Nếu thông báo không thể phân tích để xác định phiên bản thì bộ đếm snmpInASNParseErrs tăng lên và thông báo bị loại bỏ. Nếu phiên bản không được hỗ trợ bởi hệ thống xử lý thông báo thì bộ đếm snmpInBadVersions tăng lên và thông báo bị loại bỏ. • Cung cấp một giao diện trừu tượng tới ứng dụng SNMP cho sự gửi và nhận của PDU tới ứng dụng. • Cung cấp một giao diện trừu tượng tới các ứng dụng SNMP mà nó cho phép chúng gửi một PDU tới một phần tử SNMP ở xa. b) Hệ thống con xử lý thông báo (Message Processing subsystem) Hệ thống con xử lý thông báo được tạo thành từ một hay nhiều khối thông báo. Sơ đồ hình 3.2 đưa ra một hệ thống con xử lý thông báo hỗ trợ các mô hình SNMPv3, SNMPv1, SNMPv2c và một vài mô hình khác Hình 3.2 Mô hình xử lý thông báo Hệ thống con xử lý thông báo có trách nhiệm: chuẩn bị các thông báo để gửi đi và trích dữ liệu từ các thông báo nhận được. Khi bộ điều vận nhận thông báo SNMPv3 từ đường truyền, bộ điều vận xác định phiên bản của thông báo và gửi nó cho khối xử lý thông báo. Khối xử lý thông báo xử lý các thông báo bằng cách trích thông tin từ đó. Sau đó gọi hệ thống con an toàn (Security Subsystem - 3.1.1/c) để giải mã phần dữ liệu của thông báo (nếu cần) và xác nhận thông báo hợp lệ. Lúc đó, bộ điều vận sẽ gửi PDU của thông báo đến ứng dụng SNMP thích hợp. Cấu trúc này cho phép thêm các khối của một hãng sản xuất hoặc thêm các tiêu chuẩn Message Processing Subsystem (Hệ thống con xử lý thông báo) SNMPv3 Message Processing Model Mô hình xử lý thông báo SNMPv3 SNMPv1 Message Processing Model Mô hình xử lý thông báo SNMPv1 SNMPv2c Message Processing Model Mô hình xử lý thông báo SNMPv2c Other Message Processing Model Mô hình xử lý thông báo khác 64 sau này. Trong mọi trường hợp, bộ điều vận cần có khả năng phân tích các thông báo để xác định phiên bản. c) Các hệ thống con an toàn (Security subsystem) Các hệ thống con an toàn cung cấp các dịch vụ an toàn như: xác nhận thông báo, mã hoá và giải mã các thông báo để đảm bảo bí mật. Sơ đồ hình 3.3 đưa ra hệ thống con an toàn hỗ trợ các mô hình cho SNMPv3, mô hình trên cơ sở truyền thông và vai mô hình khác. Mô hình trên cơ sở truyền thông hỗ trợ cả SNMPv1 và SNMPv2. Mô hình an toàn trên cơ sở người dùng sẽ bảo vệ các thông báo SNMPv3 từ các mối nguy hiểm: • Một người được phép gửi một thông báo mà có thể bị sửa trong khi truyền bởi một phần tử SNMP không được phép. • Một người dùng không được phép cố gắng giả trang như người dùng đã được phép. • Sửa chuỗi thông báo. SNMP dựa trên cơ sở UDP, là dịch vụ vận chuyển không liên kết. Các thông báo có khả năng bị bắt giữ và sắp xếp lại, làm chậm và có thể được chuyển lại sau đó. • Nghe trộm. Bởi các thông báo cho phép được mã hoá, một ai đó nghe trộm trên đường dây sẽ không thể phán đoán rằng họ nhận được gì. Hình 3.3 Hệ thống con an toàn Trong mô hình an toàn trên cơ sở người dùng, các giao thức xác nhận sử dụng HMAC-MD5-96 and HMAC-SHA-96 và giao thức bí mật sử dụng CBC-DES và có thể thêm vào các giao thức xác nhận và giao thức bí mật trong tương lai. d) Hệ thống con điều khiển truy cập (Access Control Subsystem) Security Subsystem (Hệ thống con an toàn) User-Based Security Model Mô hình an toàn người dùng Community-Based Security Model Mô hình an toàn truyền thông Other-Security Model Mô hình an toàn khác 65 Trách nhiệm của hệ thống con điều khiển truy cập là: xác định khi nào việc truy cập vào một đối tượng quản trị là được phép. Hiện nay mới định nghĩa một mô hình: mô hình điều khiển truy cập trên cơ sở thẩm tra (View-base Access Control Model – VACM, hình 3.5). Theo hình 3.4, cấu trúc SNMPv3 cho phép các mô hình điều khiển truy cập bổ sung được định nghĩa trong tương lai. • VACM có thể kiểm soát các user và các hoạt động truy cập tới các đối tượng quản trị. • Khi một lệnh Get, GetNext, GetBulk, hoặc Set PDU của SNMP được xử lý, hệ thống con điều khiển truy cập phải được gọi để chắc chắn các đối tượng MIB được mô tả trong các liên kết biến là được phép truy cập. • Khi một thông báo (SNMPv2-Trap hay Inform) được tạo ra, hệ thống con điều khiển truy cập phải được gọi để chắc chắn các đối tượng MIB đựơc mô tả trong liên kết biến là được phép truy cập. Hình 3.4 Hệ thống điều khiển truy cập Access Control Subsystem Hệ thống con điều khiển truy cập User-Based Access Control Model Mô hình điều khiển truy cập người dùng Community-Based Access Control Model Mô hình điều khiển truy cập truyền thông Other Access Control Model Mô hình điều khiển truy cập khác 66 Hình 3.5 VACM 3.1.2 Phần mềm ứng dụng SNMP Đối với SNMPv3 khi nói đến các ứng dụng, ta cần xem đây là các ứng dụng nội bộ bên trong phần tử SNMP. Các ứng dụng nội bộ này thực hiện công việc như tạo ra các bản tin SNMP, đáp ứng lại các bản tin nhận được, nhận các bản tin và chuyển tiếp các bản tin giữa các phần tử. Hiện có năm loại ứng dụng đã được định nghĩa: • Các bộ tạo lệnh (Command Generator): Tạo ra các lệnh SNMP để thu thập hoặc thiết lập các dữ liệu quản lý. • Các bộ đáp ứng lệnh (Command responders): Cung cấp việc truy cập tới dữ liệu quản lý. Ví dụ các lệnh Get, GetNext, GetBulk và Set PDUs được thực hiện bởi các bộ đáp ứng lệnh. • Các bộ tạo bản tin (Notification originators): Khởi tạo Trap hoặc Inform. • Các bộ nhận bản tin (Notification receivers): Nhận và xử lý các bản tin Trap hoặc Inform. • Các bộ chuyển tiếp uỷ nhiệm (Proxy Forwarder): Chuyển tiếp các thông báo giữa các phần tử SNMP. SNMP Manager: Một phần tử SNMP bao gồm một hoặc nhiều các bộ tạo lệnh và/hoặc các bộ nhận bản tin giữa các phần tử SNMP. Một SNMP Manager được giới thiệu ở dưới: 67 SNMP Agent: Một phần tử SNMP bao gồm một hoặc nhiều các bộ đáp ứng lệnh và/hoặc các bộ tạo bản tin (cùng với công cụ SNMP kết hợp chúng) được gọi là một SNMP Agent. Một SNMP Agent được giới thiệu ở hình 3.2 Định dạng thông báo SNMPv3 Một thông báo SNMPv3 bao gồm các thành phần chính sau: • Common data: Trường này có trong tất cả các thông báo SNMPv3 • Security model data: Gồm ba thành phần con là phần dùng chung, phần xác thực và phần riêng. • Context: Có hai trường đảm bảo PDU có nội dung không sai khác. • PDU: bao gồm một PDU SNMPv2c.. Hình 3.5 Định dạng gói tin snmpv3 3.3.1 Common Data a) MessageVersion Đây là trường đầu tiên của phiên bản thông báo này, nó ở vị trí giống như ở tất cả các phiên bản khác trong quá trình xử lý thông báo. Điều này giúp cho các thông báo tương thích với nhau giữa các phiên bản khi chuyển đổi giữa các dạng thông báo khác nhau. Trường này nếu có giá trị là 3 tương ứng với đây là gói tin SNMPv3, 2 là gói tin SNMPv2, và 1 là gói tin SNMPv1. b) MessageID Là giá trị nguyên dùng để phối hợp các thông báo yêu cầu và đáp ứng giữa hai phần tử SNMP. Việc sử dụng nó tương tự như việc sử dụng nhận diện yêu cầu trong PDU. MessageID được sử dụng bởi công cụ để nhận diện thông báo mang một PDU. Bởi vậy nếu một manager gửi một GetRequest với MessageID x, khi đó manager sẽ không được sử dụng lại x cho đến khi thông báo chưa được trả lời hoặc đã quá thời gian timed-out. PDU bao gồm một trường ID (được sử dụng tương tự như 68 trong SNMPv1 và SNMPv2) tuy nhiên với SNMPv2 thì có thêm mã hóa PDUs. MessageID nằm trong phần header (không được mã hóa). MessageID cũng cho biết các bản sao của một thông tin phản hồi có thể được xác định. Vậy nên khi truyền lại một message thì manager nên sử dụng một MessageID mới. b) MaxMessageSize Là số nguyên thể hiện kích thước thông báo lớn nhất mà bên gửi có thể hỗ trợ. Giá trị này dùng để xác định một kích thước lớn nhất mà một thông bóa phản hồi có thể đáp ứng. c) MessageFlags Có giá trị là một byte xác định xác thực và bảo mật của thông báo. Nếu tin nhắn yêu cầu một xác nhận báo cáo của người nhận thì quyền này được xác định thông qua 3 bit: • Không xác thực và không bảo mật (bit values 000) • Xác thực và không bảo mật (bit values 001) • Xác thực và bảo mật (bit values 011) Mức độ an toàn mà bên gửi phải áp dụng vào thông báo trước khi gửi đi bao gồm: reporttableFlag, authFlag, privFlag. d) MessageSecurity MessageSecurity là một số nguyên xác định thiết lập bảo mật giữa các thông báo: • 0 dành cho "any" • 1 dành cho SNMPv1. • 2 dành cho SNMPv2c. • 3 dành cho USM. • 4–255 dành cho các chuẩn mô hình bảo mật. Các giá trị trên 255 dành cho các nhà phát triển sử dụng cho các cơ chế bảo mật cụ thể, hệ thống con bảo mật (Security subsystem) xử lý trên phần này của SNMPV3. 3.3.2 Security Model Data (SMD) a) General Trong phần general của SMD gồm các trường sau: 69 • EngineID: Số nhận dạng một SNMPv3 engine • EngineBoots: số lần một SNMP engine được khởi tạo hoặc đặt lại giá trị của EngineID • EngineTime: số giây tính từ lúc EngineBoots được thay đổi lần cuối cùng. • UserName: Tên của user. b) Authentication Protocol Hai giao thức xác thực trong SNMPv3 là MD5 và SHA, cả hai giao thức này nhằm mục đích xác thực các thông báo SNMPv3. c) Privacy Protocol Hệ mã bảo mật trong trường Privacy sử dụng hệ mã hóa DES trong việc mã hóa và giải mã thông báo SNMPv3. 3.3.3 Context ContextName là một chuỗi octet, và ContextID xác định một thực thể duy nhất mà có thể nhận ra nội dung trong hoàn cảnh cụ thể. Các chi tiết nội dung được coi là một phần của trường PDU. 3.3.4 PDU Đối tượng này là một PDU được mã hóa hoặc không được mã hóa. Giá trị của MessageFlags sẽ quyết định việc mã hóa này. 3.4 Trao đổi SNMPv3 Message Hình 3.6 dưới đây bao gồm một SNMP manager A kết nối với một router, router này có ba giao tiếp 1 với A và hai giao tiếp còn lại với hai SNMP agent là B và C. trong hình này, trường PDU là SNMPv2c PDU có thêm phần xác thực và mã hóa. Có hai message được trao đổi là GetRequest và GetResponse. 70 Hình 3.6 Trao đổi SNMPv3 message 3.4.1 SNMPv3 GetRequest Manager A muốn lấy giá trị ipInReceives.0 là đối tượng của Agent B nên đã sử dụng một truy vấn getrequest để đảm bảo an toàn của thông tin thì trước khi truy vấn được gửi đi nó đã được mã hóa. Khi B nhận được thông báo ( truy vấn getrequest) nó sẽ xử lý ( kể cả các bước liên quan đến an toàn gói tin) và sau đó sẽ truy vấn đến một đối tượng trong MIB, bước tiếp theo Agent B sẽ tạo một thông báo phản hồi lại A cũng áp dụng các chính sách bảo mật để đảm bảo an toàn trong quá trình truyền. Sau khi thẩm tra độ an toàn và xác thực gói tin, Manager A sẽ lấy giá trị quan tâm lưu nó trong một ứng dụng cụ thể thường là một cơ sở dữ liệu. Hình 3.6 : • SNMPv3 được sử dụng (MessageVersions =3). • Trường đầu tiên trong PDU có giá trị là 0xA0 (get). • Giá trị của trường MessageFlags là 011 có nghĩa là các message này yêu cầu phải được xác thực và mã hóa để đảm bảo an toàn. 71 • Giá trị MessageSecurity là 3; SNMPv3 USM được dùng để đảm bảo an toàn. • es (error-status,) và ei (error-index, vị trí của đối tượng đầu tiên trong các biến binings khi một lỗi xảy ra) các trường này luôn có giá trị là zero tương ứng với một GetRequest. • Trong GetResponse message, trường đầu tiên của PDU có giá trị 0xA2 (getResponse) và giá trị es (error-status) và ei (error-index) tất cả đều bằng zeo (0) điều này có nghĩa là không có lỗi xảy ra khi truy vấn một đối tượng MIB. • Một message trả lời của Agent B có biến binding với giá trị là 90033, agent đẩy giá trị này vào đúng vị trí yêu cầu của PDU. 3.4.2 SNMPv3 GetNextRequest Nếu Manager A muốn thực hiện một lệnh getNextRequest trên đối tượng ipInReceives.0, trong hình 3.6 sẽ làm như sau: • Trường đầu tiên trong PDU sẽ có giá trị là oxA1 (getNext). • Trong phản hồi từ B sẽ bao gồm đối tượng tiếp theo của ipInReceives.0, ví dụ như ip.ipDefaultTTL.0 (bảng 3.1). Sau khi trao đổi message hoàn tất thì Manager A có dữ liệu quan tâm. MIB OBJECT NAME OBJECT TYPE OBJECT INSTANCE VALUE Ip.ipForwarding.0 INTEGER 2 Ip.ipDefaultTTL.0 INTEGER 128 Ip.ipInReceives.0 Counter 90033 Ip.ipFragCreates.0 Counter 0 Bảng 3.1 Duyệt nhóm IP trên MIB của một Host 3.5 Kiểm soát mạng từ xa RMON RMON là một thành phần quan trọng cho tập cơ sở dữ liệu chuẩn của SNMP (SMI, MIB, SNMP) để tiến tới việc quản trị liên mạng. Nó định nghĩa một khối MIB kiểm soát từ xa có hỗ trợ MIB-II và cung cấp thông tin cần thiết về liên mạng cho người quản trị mạng. 72 3.5.1 Khái niệm về kiểm soát mạng từ xa Chúng ta đã tìm hiểu khái niệm MIB-II ở phần trên, MIB-II giúp người quản trị nhận được thông tin cục bộ về từng thiết bị đơn lẻ (như thông lượng vào ra của thiết bị) nhưng với môi trường liên mạng (như muốn đánh giá thông lượng toàn bộ hệ thống gồm nhiều thiết bị đơn lẻ) thì cần phải có một bộ kiểm soát để thực hiện các hoạt động kiểm soát như đối với từng thiết bị đơn lẻ trong mạng cục bộ (thông tin tổng hợp thống kê lỗi, các thống kê hiệu năng, …). Bộ kiểm soát có thể là một thiết bị độc lập hoặc chức năng kiểm soát được thực hiện trên một thiết bị có nhiều chức năng, và được gọi là các bộ kiểm soát từ xa. Để quản trị mạng có hiệu quả, các bộ kiểm soát từ xa cần truyền thông tin tới một trạm quản trị mạng trung tâm. 3.5.2 Các đặc điểm cơ bản của RMON Hoạt động độc lập: cho phép người quản trị giới hạn hoặc ngắt việc thăm dò kiểm soát nhằm tiết kiệm chi phí truyền thông đặc biệt với các tuyến liên lạc, khi phát hiện lỗi truyền thông hoặc khi người quản trị ngắt, bộ kiểm soát sẽ tiếp tục thu thập thống kê nhận được sau đó. Kiểm soát liên tục: nếu bộ kiểm soát có đủ tài nguyên và nếu không quan tâm đến việc bị ngắt, bộ kiểm soát sẽ thực hiện liên tục các chuẩn hóa, và ghi lại hiệu năng mạng, khi có lỗi trong mạng, bộ kiểm soát sẽ thông bóa cho trạm quản lý và cung cấp thông tin hữu ích cho trạm quản trị để chuẩn đoán lỗi. Phát hiện lỗ và thông báo: bộ kiểm soát có bộ tìm kiếm chủ động để kiểm tra lỗi và các điều kiện ngoại lệ, ghi nhận thụ động (không thăm dò) các điều kiện lỗi nhất định và các điều kiện khác, nó được thiết lập để làm việc này liên tục nhằm thông báo cho trạm quản trị khi lỗi nào đó trong các điều kiện kia xuất hiện. Dữ liệu gia tăng: cấu hình liên mạng cần nhiều trạm quản trị để tăng độ tin cậy và thực hiện các nhiệm vụ khác nhau vì vậy bộ kiểm soát phải được thiết lập để phù hợp với nhiều trạm quản trị đồng thời. Trong hình 3.7, RMON được sử dụng để quản lý FDDI LAN, RMON đặt tại NMS. 73 Hình 3.7 Cấu hình mạng với RMON Đa quản lý: một cấu hình liên mạng có thể có nhiều trạm quản lý để tăng độ tin cậy, thực hiện các chức năng khác nhau và gia tăng khả năng quản lý. Bộ kiểm soát được thiết lập phù hợp với nhiều trạm quản lý hoạt động đồng thời như vậy. Tuy nhiên không phải mọi bộ kiểm soát đều phải có đầy đủ những đặc điểm cơ bản trên. 3.5.3 Quản lý bộ kiểm soát từ xa Một bộ kiểm soát từ xa có thể thực hiện như một thiết bị dành riêng hoặc là một chức năng có sẵn trong hệ thống. Để quản lý bộ kiểm soát từ xa có hiệu quả, RMON MIB có các thuộc tính hỗ trợ cho việc điều khiển rộng rãi từ các trạm quản trị. Các đặc tính này thể hiện ở hai mặt: cấu hình và thực hiện lệnh. a) Cấu hình bộ kiểm soát Một bộ kiểm soát từ xa cần được cấu hình cho dữ liệu thu thập. Cấu hình thể hiện loại và dạng dữ liệu cần thu thập. RMON MIB được tổ chức theo một số nhóm chức năng. Trong mỗi nhóm có một hay nhiều bảng điều khiển và bảng dữ liệu. Một bảng điều khiển, thường là đọc ghi, chứa các tham số mô tả dữ liệu trong một bảng dữ liệu, thường là chỉ đọc. Khi thiết lập cấu hình, trạm quản trị đặt các tham số điều khiển tương tứng để thiết lập bộ khiểm soát từ xa nhận dữ liệu mong muốn. Các tham số được đặt bằng cách thêm một hàng mới vào bảng điều khiển hoặc sửa đổi một hàng đã có. Khi thông tin được thu thập theo tham số đặt cho một hàng, dữ liệu sẽ được ghi vào một hay nhiều bảng dữ liệu tương ứng, một hàng đơn lẻ trong bảng điều khiển và các hàng dữ liệu tương ứng của nó rằng buộc với nhau bằng các con trỏ khóa. Do vậy khi 74 sửa chữa các tham số bất kỳ trong bảng điều khiển, đầu tiên phải chú ý đến rằng buộc này. b) Thực hiện lệnh Có thể sử dụng toán tử SET của SNMP để đưa ra một lệnh, một quá trình như vậy được gọi là thực hiện lệnh khi được gọi (thực hiện lệnh khi được yêu cầu). Một đối tượng có thể được sử dụng để đại diện cho một lệnh, do vậy một hoạt động nhất định sẽ được thực hiện khi đối tượng được đặt một giá trị nhất định. Một số đối tượng như vậy được bao gồm trong RMON MIB. 3.5.4 Đa quản lý Trong môi trường nhiều trạm quản trị, quyền sở hữu đối với các bảng dữ liệu (các đối tượng) được chia sẻ và cấp phát theo một số nguyên tắc sau: • Một trạm quản trị có thể nhận dạng các tài nguyên mà nó sở hữu và các tài nguyên không cần thiết khác. • Một trạm có thể tự giải phóng các tài nguyên thuộc sở hữu của mạng khác khỏi nó. • Nếu một trạm quản trị được khởi tạo lại, nó có thể nhận biết các tài nguyên nó đã sở hữu trước đó và cũng có thể giải phóng những tài nguyên mà nó thấy không cần thiết nữa. • Quyền sở hữu được xác định thông qua các thuộc tính sau của đối tượng: địa chỉ IP, tên trạm quản trị, tên người quản trị mạng, vị trí hoặc số điện thoại. • Quyền sở hữu không hoạt động theo mật khẩu hay cơ chế điều khiển truy cập, ví dụ một hàng trong bảng điều khiển chỉ có thể bị sửa đổi hay xóa khỏi trạm quản trị chủ của nó và là chỉ đọc đối với các trạm quản trị khác được chia sẻ (nhiều trạm quản trị có thể cùng truy cập một bảng điều khiển). • Khi một trạm quản trị muốn thực hiện một chức năng nhất định trong một bộ kiểm soát, trước tiên nó quét bảng điều khiển liên quan xem nếu có chức năng đó, hoặc chức năng gần giống đã được định nghĩa bởi một trạm quản trị khác nó sẽ chia sẻ chức năng đó bằng cách nhận các hàng dữ liệu chỉ đọc tương ứng liên quan đến hàng điều khiển đó. 75 • Để tránh một chức năng đã được chia sẻ bị sửa hay xóa bởi một trạm quản trị sở hữu nó, bộ kiểm soát khi được thiết lập với một tập ngầm định các chức năng khi nó được khởi tạo, các hàng điều khiển định nghĩa các chức năng này sẽ được sở hữu bởi bộ kiểm soát. Một trạm quản trị có thể chia sẻ các chức năng này nếu chúng phù hợp với các yêu cầu của trạm quản trị đó tuy nhiên nó không thể sửa chữa hay xóa một chức năng do bộ kiểm soát sở hữu nếu không có chỉ thị của người điều khiển bộ kiểm soát (ở đây thường là người quản trị mạng). 76 CHƯƠNG 4: GIỚI THIỆU PHẦN MỀM QUẢN TRỊ MẠNG (8 tiết giảng + 2 tiết thảo luận/ bài tập) 4.1 Giới thiệu các chức năng chính của phần mềm NET-SNMP 4.2 Hướng dẫn cài đặt và triển khai phần mềm trên nền Unix/Linux hoặc Window