系列教程

內容介紹

作為系統管理員，我們的主要工作就是收集來自伺服器與基礎設施的準確資訊。目前多種工具都能夠幫助我們實現此類資訊收集任務，而其中大部分都以同一技術為基礎，即SNMP。

SNMP全稱為簡單網路管理協議。其不僅能夠收集伺服器的當前狀態資訊，同時允許管理員藉此對預設值進行變更。另外，這套協議本身雖然非常簡單，但在實際程式中的使用結構卻往往相當複雜。

在本教程中，我們將探討SNMP協議的各基礎知識。具體而言，我們將瞭解其使用方式、網路中的協議使用慣例以及不同協議版本等等。

基本概念

SNMP是一種用於實現網路堆疊應用層的協議（具體請參閱網路層相關說明)。該協議能夠以統一方式對來自不同系統的資訊進行收集。儘管其能夠以多種途徑接入系統，但採用的資訊查詢方法與路徑相關資訊則是完全標準化的。

SNMP協議擁有多種版本，而且多數聯網硬體裝置都會採用某種形式的SNMP接入機制。目前應用最為廣泛的為SNMPv1，但其安全性存在一定問題。它的超高人氣主要歸功於普遍性與較早的推出時間。因此，除非大家擁有明確理由，否則推薦各位優先選擇SNMPv3，其包含更多更為先進的安全功能。

總體來講，由SNMP配置的網路將由多臺包含SNMP代理的裝置構成。所謂代理，就是一款能夠對特定硬體資訊進行收集、整理並利用SNMP協議實現查詢響應的程式。

這種模式中，負責向代理查詢資訊的元件被稱為SNMP manager。這些元件查詢的資訊主要為啟用SNMP裝置的全部狀態，且可執行請求以收集資訊並設定特定屬性。

SNMP Mangers

SNMP manager就是一臺計算機，其配置方式為輪詢SNMP代理以獲取資訊。在核心功能層面，這種管理元件在複雜性上遠低於客戶端配置，因為它的作用只有一種——進行資料查詢請求。

該manager可以是任何能夠向SNMP代理查詢資料且包含正確證書的裝置。有時候，我們也可以將其作為監控套件的組成部分。

SNMP協議中的幾乎全部定義命令都需要由manager元件負責傳送，其中包括GetRequest,GetNextRequest,GetBulkRequest,SetRequest,InformRequest以及Response。另外，manager還需要響應Trap並Response資訊。

SNMP代理

SNMP代理的工作很多。它們負責收集本地系統資訊並將其儲存為可供查詢的資料庫格式。這種資料庫被稱為“管理資訊庫”，或者簡稱MIB。

MIB是一套層次化預定義結構，負責儲存可供查詢或者設定的資訊。我們可以立足於一套擁有正確憑證的認證主機（即SNMP manager）生成擁有適當格式的SNMP請求。

代理計算機則配置哪些manager有權對其資訊進行訪問。它還能夠作為中間人報告那些其能夠接入，但並未面向SNMP流量進行配置的裝置的相關資訊。如此一來，我們就能夠非常靈活地線上訪問元件與SNMP。

SNMP代理包含大量由該協議定義的命令，其中包括GetRequest,GetNextRequest,GetBulkRequest,SetRequest以及InformRequest。另外，代理還能夠傳送Trap訊息。

瞭解管理資訊庫

SNMP系統中最難以理解的部分當數MIB，或者說管理資訊庫。MIB是一套遵循manger與代理所提出標準的資料庫。這是一套層級化結構，採用全域性標準但亦可靈活針對特定供應商方案做出調整。

MIB結構可以被理解為一套向上而下的樹狀結構。每個分支都由一個標識數字（從1開始）與一個標識字串進行指定，且二者在整套結構中獨一無二。大家可以交替使用字串與數字。

要引用樹狀結構中的特定節點，大家必須從該樹的未命名root處追蹤路徑至所需節點。其父ID（數字或字串）譜系通常為起點，其貫通至目標節點並以此形成地址。層次結構中的每個結點以一個點（.）代表，即各ID字串或數字以點隔開。這樣一條完整的地址即被稱為一個物件識別符號，或者OID。

硬體供應商有時會將SNMP代理嵌入至裝置當中，從而以定製化方式拆分自己的欄位與資料點。然而，其同樣屬於標準化MIB分支，經過合理定義且可用於任何裝置。

我們討論的標準分支皆人性於同一套父分支結構。該分支負責根據MIB-2規範進行資訊定義，並作為裝置的執行標準存在。

該分支的基礎路徑為：

1.3.6.1.2.1

我們可以將其解釋為字串形式：

iso.org.dod.internet.mgmt.mib-2

其中1.3.6.1或者iso.org.dod.internet部分代表OID，負責定義網際網路資源。而2或者mgmtthat則屬於一個管理子類。接下來的1或mib-2則定義MIB-2規範。

這裡推薦大家參閱MIB樹狀結構。此頁面顯示了我們之前談到的交界處的連線節點。大家可以藉此向上或向下檢視“superior”與“subsidiary”引用的含義。

另一款類似的工具為SNMP物件導航器，由思科公司提供。我們可以藉此找到自己需要的資訊。另外，SolarWinds也提供類似的樹狀結構。

基本上，如果大家希望查詢裝置上的資訊，那麼大部分路徑皆以1.3.6.1.2.1開頭。大家可以瀏覽樹介面以瞭解可供查詢及設定的資訊。

SNMP協議命令

SNMP之所以廣受歡迎，一大原因在於其命令相當簡單。具體操作要求不高，但又擁有充足的靈活性，這一切都使其成為一套理想的解決方案。

以下PDU，全稱為協議資料單元，用於描述協議之後附加的具體訊息型別：

• Get: Get訊息由manager傳送至代理處，用於請求特定OID值。此請求由Response訊息進行應答，並最終攜帶相關資料重新迴歸manager。
• GetNext: GetNext訊息允許manager請求MIB中的下一序列物件。通過這種方式，我們能夠遍歷MIB結構，而無需擔心具體的OID查詢方式。
• Set: Set訊息由manager傳送至代理處，旨在變更該代理所持有的某變數值。我們可以藉此控制配置資訊，或者修改遠端主機狀態。這也是惟一一條由該協議定義的寫入操作。
• GetBulk: 這條請求負責一次性實現多條GetNext請求。返回結果所包含的資料量僅受資料包攜帶能力的限制。
• Response: 由代理髮送的response訊息用於將任意所請求資訊傳送回manager。其既負責所請求資料的傳輸，同時也對收到的請求做出確認。如果無法返回請求的資料，response會新增錯誤欄位以進行進一步資訊查詢。以上各請求都會匹配對應的response以及Inform訊息。
• Trap: 由代理生成的trap訊息指向manager。Traps屬於被動型非同步通訊，主要由代理用於向事件的對應manager釋出當前所託管裝置的狀態。
• Inform:為了確認trap收取完成，manager會向代理髮回一條Inform訊息。如果該代理未收到此訊息，則會再次傳送trap訊息。

憑藉這七種資料單元型別，SNMP得以查詢併發送與網路裝置相關的各類資訊。

協議版本

SNMP協議自初次出現以來已經經歷了多次變革。其最初規範分別作為RFC 1065、1066與1067出現於1988年。儘管時隔多年，該版本仍然廣受支援。然而，由於此版本存在多種安全問題，包括以明文方式儲存憑證等，因此我們不推薦大家使用。

該協議的版本2出現於1993年，針對原有版本做出一系列改進。此版本提供新的“party-based”安全模式，旨在解決上代版本的安全難題。然而，這套新模式始終人氣不高，這主要是由於其難以理解及實現。

因此，版本2的多種“副產品”應運而生，其不僅保留了原有改進，同時亦去掉了飽受詬病的安全模式。在SNMPv2c中，基於社群的驗證機制（與v1一致）被重新引入。這是v2協議中最具人氣的版本。而另一套實現方案SNMPv2u則採用基於使用者的安全機制，但其也未能開啟市場。

1998年，SNMP協議的第三代版本（也是當前版本）成為新的規範提案。從使用者角度看，其最重要的變化就是採用基於使用者的安全系統。我們可以利用以下方式設定出使用者需要的驗證要求：

• NoAuthNoPriv: 以此級別接入的使用者不具備驗證身份，且無法對傳送及接收的訊息進行隱私保護。
• AuthNoPriv: 使用此模式接入必須經過驗證，但發出的訊息未經過加密。
• AuthPriv: 必須驗證且訊息經過加密。

除了驗證之外，版本3還提供訪問控制機制為使用者可訪問的分支提供細化控制。新版本亦能夠利用其它傳輸協議提供的安全保護，例如SSH或者TLS。

總結

在下一篇系列教程中，我們將探討如何安裝並配置必要的元件，從而在系統中上手使用SNMP。

翻譯：diradw