能否跨网络/互联网向其他Ubuntu VM发送SNMP Traps？

Great question! It’s super common to get SNMP traps working locally but hit walls when going cross-network—let’s break down the key issues and walk through how to fix them step by step.

1. Verify Basic Network Connectivity First #

Before diving into SNMP specifics, make sure your two VMs (or your VM and the internet endpoint) can actually talk to each other:

• Ping the target machine’s IP from the sender: ping <target-ip> — if this fails, you’ve got a network routing issue (check VM network settings, subnet masks, gateways) to fix first.
• Test UDP port 162 (the default SNMP Trap port) connectivity with nc (netcat):
  • On the receiver, run nc -ul 162 to listen for UDP traffic.
  • On the sender, run echo "test" | nc -u <target-ip> 162 — if the receiver sees the "test" message, your port is open at the network level. If not, firewall/port blocking is the likely culprit.

2. Fix SNMP Configuration Issues #

Local traps work because your config is probably set to allow loopback traffic—you need to update it for external sources:

On the Trap Receiver (snmptrapd) #

• Edit the config file at /etc/snmp/snmptrapd.conf:
  • Add or uncomment lines to allow traps from external IPs and set the correct community string (replace public with your actual community string):

    authCommunity log,execute,net public
    traphandle default /usr/sbin/snmptthandler
    

  • Make sure there’s no localhost restriction (like authCommunity ... localhost—that blocks external traps).
• Restart the snmptrapd service: sudo systemctl restart snmptrapd

On the Trap Sender #

• When sending traps, explicitly specify the target IP and community string (don’t rely on defaults that might point to localhost):
  Example command for v2c traps:

  snmptrap -v 2c -c public <target-ip> '' SNMPv2-MIB::sysUpTime.0 SNMPv2-MIB::snmpTrapOID.0 SNMPv2-MIB::coldStart.0
  

  • If using a custom SNMP config file, ensure it doesn’t hardcode localhost as the trap destination.

3. Unblock Firewalls on Both Ends #

Ubuntu’s default firewall (ufw) blocks incoming UDP 162 by default—you need to open it:

• On the receiver machine:

  sudo ufw allow 162/udp
  sudo ufw reload
  

• If you’re using iptables instead of ufw, run:

  sudo iptables -A INPUT -p udp --dport 162 -j ACCEPT
  sudo iptables-save | sudo tee /etc/iptables/rules.v4
  

• Also check any network-level firewalls (like your router’s firewall if sending over the internet) — they might block UDP 162 traffic.

4. Sending Traps Over the Internet? Special Considerations #

If you’re trying to send traps to a machine over the public internet, there are extra hoops:

• Public IP Requirement: The receiver must have a public static IP (or use a dynamic DNS service if the IP changes).
• Port Forwarding: If the receiver is behind a home/business router, you need to set up port forwarding on the router to send UDP 162 traffic to the receiver’s internal IP.
• ISP Port Blocking: Some ISPs block UDP 162 (it’s a common target for abuse). If port forwarding doesn’t work, try using an alternative port (update both sender and receiver configs to use, say, 1620 instead of 162).
• SNMPv3 for Security: If sending over the internet, avoid v2c (it’s unencrypted). Use SNMPv3 with authentication and encryption to keep your trap traffic secure.

5. Debugging Tips #

• On the receiver, run snmptrapd in verbose mode to see real-time traffic:

  sudo snmptrapd -f -Lo
  

  This will print all incoming trap data directly to your terminal, making it easy to spot if traps are arriving or being rejected.
• Check system logs for snmptrapd errors: grep snmptrapd /var/log/syslog — this might show authentication failures or configuration issues.
• Use tcpdump to capture trap traffic on the receiver:

  sudo tcpdump -i any udp port 162
  

  This will confirm whether the trap packets are even reaching the receiver’s network interface.

内容的提问来源于stack exchange，提问作者mionnaise