SNMP 連接埠號：161 與 162 的區別、放行與排查

SNMP 連接埠號是 UDP 161 和 UDP 162。161 是被監控裝置（交換器、路由器、伺服器上的 snmpd、UPS 網路卡等）上的 SNMP 代理監聽的連接埠，監控伺服器向它傳送 Get、GetNext、GetBulk、Set 請求；162 是監控伺服器上的 Trap 接收程式監聽的連接埠，裝置出現連接埠斷開、重啟、溫度過高等事件時，主動把 Trap 或 Inform 發到這裡。一句話記住方向：查詢發往裝置的 161，告警發往監控伺服器的 162。所以被監控裝置上不需要開放 162，監控伺服器上也不需要開放 161（除非它自己也被別人監控）。

161 和 162 分別是誰在監聽

連接埠	傳輸	誰在監聽	誰發起	承載的報文
161	UDP	被監控裝置上的 SNMP 代理	監控伺服器	Get、GetNext、GetBulk、Set 請求及對應的回應
162	UDP	監控伺服器上的 Trap 接收程式（如 snmptrapd、監控平台）	被監控裝置	Trap、Inform，以及 Inform 的確認
10161、10162	TCP 上的 TLS，或 UDP 上的 DTLS	同上兩行	同上兩行	加密傳輸的 SNMP（RFC 6353），網路裝置很少支援

一次查詢和一次告警的報文走向如下，範例中監控伺服器為 10.10.0.10，交換器為 10.0.0.2：

輪詢（Get / Walk）
  10.10.0.10:隨機高位連接埠  ── 請求 ──▶  10.0.0.2:161
  10.10.0.10:隨機高位連接埠  ◀── 回應 ──  10.0.0.2:161

Trap
  10.0.0.2:隨機連接埠        ── Trap ──▶  10.10.0.10:162

Inform
  10.0.0.2:隨機連接埠        ── Inform ─▶  10.10.0.10:162
  10.0.0.2:隨機連接埠        ◀── 確認 ───  10.10.0.10:162

注意兩點：監控伺服器發查詢時用的是作業系統分配的隨機源連接埠，不是 161；裝置發 Trap 的源連接埠一般也是隨機的，少數裝置固定使用某個連接埠，所以防火牆規則只按目的連接埠寫，不要依賴源連接埠。

SNMP 為什麼用 UDP，這意味著什麼

SNMP 選擇 UDP，是因為它的互動是一問一答、報文很小，一台監控伺服器要輪詢成百上千台裝置，不必為每台維持連線狀態；網路擁塞時，管理流量也不會像 TCP 那樣被擁塞控制壓得發不出去。但 UDP 也帶來了幾個排查時必須知道的特點：

1. 沒有“連線被拒絕”。 TCP 連接埠不通時你會立刻收到拒絕或超時，能區分；SNMP 不通時幾乎只有一種表現：超時。團體名錯誤、來源不在 ACL 裡、版本沒啟用、連接埠被防火牆攔截，客戶端看到的都是 Timeout: No Response。
2. 丟包靠重試。 net-snmp 的命令列工具預設超時 1 秒、重試 5 次，一個不通的位址要等約 6 秒才報錯。批次輪詢幾百台裝置時，用 -t、-r 調整這兩個值，避免一台故障裝置拖慢整輪採集。
3. Trap 可能丟。 Trap 沒有確認機制，鏈路擁塞或監控伺服器正在重啟時，告警就丟了。重要裝置用 Inform，或者讓輪詢兜底。
4. 大回應會被分片。 GetBulk 一次返回很多行，回應包超過鏈路 MTU 時會在 IP 層分片，途中有裝置丟棄分片的話，讀單個值正常、批次讀大表卻超時。
5. 連接埠掃描給不出確定答案。 nmap 掃 UDP 連接埠，沒有回應時只能報 open|filtered，說不清是被過濾了還是服務沒回。

防火牆怎麼放行 SNMP 連接埠

按“誰存取誰”逐段寫規則：

位置	方向	放行內容
被監控裝置本機（交換器的 SNMP ACL、伺服器防火牆）	入	僅監控伺服器 → 本機 UDP 161
中間防火牆，監控網 → 裝置網	去程	監控伺服器 → 裝置網段 UDP 161；有狀態防火牆會自動放行回應
中間防火牆，裝置網 → 監控網	去程	裝置網段 → 監控伺服器 UDP 162
監控伺服器本機	入	裝置網段 → 本機 UDP 162
無狀態 ACL（不跟蹤會話）	回程	裝置的源連接埠 161 → 監控伺服器的高位連接埠；用 Inform 時還要放行 162 的確認回程

Linux 上用 iptables：

# 被監控的 Linux 伺服器：只允許監控伺服器讀 161
iptables -A INPUT -p udp -s 10.10.0.10 --dport 161 -j ACCEPT
iptables -A INPUT -p udp --dport 161 -j DROP

# 監控伺服器：接收裝置網段發來的 Trap
iptables -A INPUT -p udp -s 10.0.0.0/16 --dport 162 -j ACCEPT

使用 firewalld 的系統：

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.0.10/32" port port="161" protocol="udp" accept'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/16" port port="162" protocol="udp" accept'
firewall-cmd --reload

Windows 上的監控平台接收 Trap：

New-NetFirewallRule -DisplayName "SNMP Trap 162" -Direction Inbound -Protocol UDP -LocalPort 162 -RemoteAddress 10.0.0.0/16 -Action Allow

路由器上用的是不跟蹤會話的擴充套件 ACL 時，回程要單獨寫。以思科 IOS 為例，snmp 和 snmptrap 分別是 161 和 162 的關鍵字：

ip access-list extended NMS-TO-DEVICES
 permit udp host 10.10.0.10 10.0.0.0 0.0.255.255 eq snmp
ip access-list extended DEVICES-TO-NMS
 permit udp 10.0.0.0 0.0.255.255 eq snmp host 10.10.0.10 gt 1023
 permit udp 10.0.0.0 0.0.255.255 host 10.10.0.10 eq snmptrap

第一條 ACL 放在朝向裝置網的方向，第二條放在反方向：前一行放行查詢的回應，後一行放行 Trap。

改用非標準連接埠怎麼寫

查詢時指定連接埠，在位址後面加冒號和連接埠號即可：

snmpget -v2c -c 'Rd-DC1-2026' 10.0.0.2:1161 1.3.6.1.2.1.1.3.0

Linux 上的 snmpd 在 /etc/snmp/snmpd.conf 裡用 agentaddress udp:1161 改監聽連接埠；snmptrapd 在 /etc/snmp/snmptrapd.conf 裡用 snmpTrapdAddr udp:1162 改接收連接埠。1024 以下的連接埠需要 root 許可權或 CAP_NET_BIND_SERVICE 能力才能監聽，所以容器裡執行的 Trap 接收程式常常監聽 1162，再由宿主機把 UDP 162 對映過去。

裝置側把 Trap 發往非標準連接埠，在 Trap 目標里加 udp-port：

# 華為、H3C
snmp-agent target-host trap address udp-domain 10.10.0.10 udp-port 1162 params securityname cipher Rd-DC1-2026 v2c
# 思科
snmp-server host 10.10.0.10 version 2c Rd-DC1-2026 udp-port 1162

H3C 的命令把 cipher 去掉即可。網路裝置上 161 的監聽連接埠一般不建議修改，很多型號也不提供修改入口。改連接埠並不能帶來多少安全性，真正起作用的是來源 ACL 和 SNMPv3。

SNMP 連接埠不通怎麼排查

按從近到遠的順序，一段一段確認：

1. 先確認走的是哪條路、用的是哪個源位址。 監控伺服器有多塊網路卡時，ip route get 10.0.0.2 會顯示去往裝置的出介面和源位址，這個源位址必須在裝置的 SNMP ACL 裡。

2. 在監控伺服器上抓包，同時發一次查詢。 用 -t 2 -r 0 把超時設為 2 秒、不重試，抓包結果更乾淨：

tcpdump -ni any udp port 161 and host 10.0.0.2
# 另開一個終端
snmpget -v2c -c 'Rd-DC1-2026' -t 2 -r 0 10.0.0.2 1.3.6.1.2.1.1.3.0

抓包看到	說明	下一步
只有請求，沒有回應	請求沒到裝置，或者裝置收到了但不回（團體名、ACL、版本）	到裝置上看 SNMP 收包計數是否隨請求增加
請求之後收到 ICMP port unreachable	包到了，但 161 上沒有程式在監聽	SNMP 代理沒開，或者只監聽在別的位址、別的 VRF
請求和回應都有，客戶端仍報超時	回應被本機防火牆丟棄，或裝置用另一個位址回包，有狀態防火牆不認為它是這次請求的回應	檢查本機 INPUT 規則；看回應包的源位址
讀單個值正常，snmpbulkwalk 大表超時	回應超過 MTU 被分片，分片在途中被丟棄	用 snmpbulkwalk -Cr5 減少每次返回的行數

3. 在裝置側確認請求到了沒有。 華為、H3C 執行 display snmp-agent statistics，思科執行 show snmp，重複發幾次查詢，看收到的 SNMP 報文總數是否隨之增加：不增加說明包沒到裝置，問題在網路或中間防火牆；增加了但沒有回應，再看錯誤團體名、版本不符這些分項計數。

4. 被監控的是 Linux 伺服器時，確認 snmpd 監聽在哪。 執行 ss -ulnp | grep -w 161，如果顯示的是 127.0.0.1:161，外面永遠連不上。Debian、Ubuntu 的 snmpd 預設配置就只監聽本機迴環位址，要在 snmpd.conf 裡把 agentaddress 改成 udp:161 或指定的管理網位址，再重啟服務。

5. 不知道團體名時，也能測連接埠通不通。 nmap 的 snmp-info 指令碼傳送的是一個不需要憑據的 SNMPv3 探測，裝置支援 v3 時會返回引擎資訊：

nmap -sU -p 161 --script snmp-info 10.0.0.2

結果為 open 並帶有引擎 ID 等資訊，說明 UDP 161 是通的，剩下的問題出在團體名或使用者配置上。反過來，沒有回應並不能說明 161 不通：裝置可能沒有啟用 v3，或者執行 nmap 的機器不在 SNMP ACL 裡。UDP 掃描需要 root 許可權。

Trap 收不到時

先把監控平台的 Trap 服務停掉，避免佔用 162 連接埠，再用 snmptrapd 在前台臨時接收，收到什麼直接列印出來：

printf 'disableAuthorization yes\n' > /tmp/snmptrapd-test.conf
snmptrapd -f -Lo -C -c /tmp/snmptrapd-test.conf udp:162

# 在另一台機器上發一條測試 Trap（coldStart），驗證到監控伺服器的路徑
snmptrap -v2c -c test 10.10.0.10 '' 1.3.6.1.6.3.1.1.5.1

-f 前台執行，-Lo 輸出到螢幕，-C -c 表示唯讀取指定的配置檔案，disableAuthorization yes 讓它接受任何團體名，僅用於測試。測試 Trap 能收到、裝置的 Trap 收不到，問題在裝置側：用 display snmp-agent target-host 或 show snmp host 確認目標位址和連接埠，再確認 Trap 源介面到監控伺服器的路由是通的。snmptrapd 能收到、平台上卻看不到，多半是平台按來源位址匹配不到裝置，或者團體名與平台配置不一致。用 SNMPv3 發 Trap 時還要注意，接收端必須按傳送裝置的引擎 ID 建立對應的使用者，否則訊息會被丟棄；Inform 以接收端自己的引擎 ID 為準，接收端不需要預先知道裝置的引擎 ID。

在管理系統裡怎麼落地

機房管理系統接入交換器時，連接埠規劃要一併考慮配置下發和資料採集兩條路徑。Toplink DCIM 的交換器管理透過 SSH 或 Telnet 下發連接埠開關、VLAN 和限速配置，SNMP 只用於唯讀採集，因此交換器管理位址需要對 DCIM 採集與下發所用的位址放行 UDP 161，以及 TCP 22（使用 Telnet 時是 TCP 23），其餘來源一律拒絕。交換器的管理位址建議放在獨立的管理網段，並在 IP 位址管理裡單獨登記為內網型別的位址段，哪台交換器用哪個管理位址、ACL 裡該放行哪些來源，查起來都有據可依。