解決Cacti無法直連設備 教你隔山打牛抓遠端資訊

接著，以下列指令安裝socat：

在安裝完成後，執行socat，將本機收到的TCP 10000 Port的封包轉發給192.168.1.2的UDP 161 Port，其語法如下：

-T指的是timeout時間為10秒。預設為0.5秒，將之放大，增加其彈性。而在指令的最後加一個&號，是為了讓其在背景執行。

同樣驗證其成效，在下方的輸出中，可看出TCP Port 10000目前由socat進行聆聽，在收到封包後進行後續處理：

接著，回到Cacti Server來驗證SNMP是否能取得資料：

在snmpget的Host端，將之設定為tcp:127.0.0.1: 10000，並輸入相同的oid，成功取得設備的sysName是CISCO_Router。

此結果代表本文所規劃的架構已能成功運作。最後，回到Cacti Web GUI進行對應的操作。

Cacti Web GUI相關設定

登入Cacti Web GUI之後，先選擇左邊選單的Management下方的Devices，並點選右上方的Add，新增一台設備。如圖2所示。在Hostname的部分，輸入「tcp:127.0.0.1」，與在CLI介面進行測試時相同。

▲圖2 在Device選項新增一台設備。

由於此設備並非直接可連線，因此在Availability/Reachability Options欄位中點選【None】，不做監控。在SNMP Options設定部分，除了一定要設定正確的SNMP Community之外，將SNMP Port改為「10000」。

最重要的是SNMP Timeout的部分，由於在192.168.0.1和192.168.0.2中間有穿過異質網路或防火牆，將其值放大至「5000」（單位是ms），避免因防火牆效能或網路傳輸問題造成回應時間太長而被Cacti判斷為失聯，相關設定如圖3所示。

▲圖3 監控及SNMP相關設定。

完成設定後，按下〔Create〕按鈕以完成此次的操作。接著，確認是否成功抓取資料。在最下方的Associated Data Queries，選擇Add Data Query裡面的「SNMP - Interface Statistics」，並按下〔Add〕按鈕。

其輸出結果如圖4所示，在Status欄位內，可以看到Success並且其後方的Items和Rows均不為0，此結果代表Cacti已成功抓取該設備的資料。

▲圖4 新增SNMP - Interface Statistics進行驗證。

也可以點選Debugging下方的(Verbose Query)連結，以確認所抓取的資料是否正確，其輸出結果節錄如圖5所示，可以看出已成功取得Index值。

▲圖5 Data Query Debug Information。

觀察封包

操作至此，其實已大功告成。但為了確認Cacti是在SSH Tunnel上運作而非直接在TCP 10000 Port上執行，所以在Cacti Server上進行封包的擷取，並利用Wireshark來查看，以驗證Cacti的連線是運作於SSH Tunnel上。

在Cacti Server執行側錄指令如下（筆者有多張網卡，故須指定網卡），接著執行tcpdump指令：

將封包錄製存檔為test.cap檔，接著用Wireshark將之開啟，其結果如圖6所示。

▲圖6 查詢封包傳遞情形。

從Wireshark的輸出結果可以看出，在Cacti Server與Gateway之間交換的封包都是透過SSH進行加密傳輸的，因此也無法看出其內容為何。但可以發現，Cacti Server使用SSH協定建立與Gateway的連線（透過TCP 22 Port），而Gateway則是透過這個已建立的Tunnel使用22 Port往Cacti Server的60200 Port進行回傳的，因此符合此網路架構的規範。

進行架構改善

測試完成了，但有一些潛在的問題是在導入之前必須先進行考量的：

1. SSH Tunnel斷線後能否自動重新連線。

2. 自動重新連線時，能否自動登入不需輸入密碼以提 高其可靠性。

基本上，這兩個問題應該是日常維運時經常遇到的問題。可以利用幾個小工具來解決。首先，解決自動登入的問題。在Linux的openssh-clients套件中，有一個名為ssh-keygen的工具，可以使用公開金鑰認證的方式來取代原先的帳號密碼認證。