nmap测试udp端口连通性

UDP端口扫起来比TCP麻烦得多。测试TCP有三次握手，口连你发个SYN包过去，通性对方回SYN-ACK还是测试RST，一目了然。口连UDP没有这套机制——你发个数据包过去，通性端口开着它也不一定回你，测试端口关着它才可能回一个ICMP端口不可达。口连这个差别直接决定了nmap扫UDP时的通性行为逻辑。

先说个实际例子。测试我前几天排查一台内网DNS服务器，口连怀疑53端口没正常监听。通性用nmap -sU -p 53 192.168.1.10跑了一下，测试结果出来是口连open|filtered。这个状态让人抓狂——它既可能是通性开着但没回包，也可能是被防火墙过滤了。nmap在UDP扫描里大量输出这个状态，原因就在上面说的：没有响应不等于端口关闭。

-sU 是基本盘，但别指望它快

UDP扫描必须加-sU，这是nmap的UDP扫描开关。不加这个参数，nmap默认只走TCP。但加上之后你会发现速度断崖式下降。原因很简单：nmap对UDP端口的探测需要等待超时。TCP可以靠RST快速判断，UDP很多时候只能干等。

我试过扫一台主机的前100个UDP端口，命令是nmap -sU --top-ports 100 10.0.0.5，花了将近四分钟。同样100个TCP端口，不到三秒就完事。这个差距在实际使用中非常明显，所以扫UDP一定要有耐心，或者把超时和重试参数调紧一点：

nmap -sU -p 53,123,161 --max-retries 1 --host-timeout 30s 10.0.0.5

--max-retries 1减少重发次数，--host-timeout 30s给单台主机设个硬上限。这两个参数能救命，尤其是扫大网段的时候。

结果状态怎么读

UDP扫描的结果状态比TCP多几种，容易混淆。open表示端口确实开着并且回了UDP包——这种情况其实不多，因为很多UDP服务收到不认识的包直接丢掉，根本不回。closed表示收到了ICMP端口不可达，说明端口确实关了。open|filtered是最常见的，意思是没收到任何回应，nmap无法区分是开着被过滤了还是开着但服务不理你。filtered则通常是收到了ICMP不可达但类型不对，比如管理员禁止了通信。

想让结果更明确，可以加-sV做版本探测。nmap会尝试发送特定服务的探测包，比如对SNMP端口发一个SNMP请求，如果服务响应了，状态就从open|filtered变成open。但这又会进一步拖慢速度，自己权衡。

几个踩过的坑

扫UDP必须用root权限或者sudo，普通用户跑-sU会直接报错。因为发原始套接字需要特权，这个没得商量。

另外，如果你在云服务器上扫，很多云厂商的虚拟网络会直接丢弃UDP探测包，导致所有端口都显示open|filtered。这不是nmap的问题，是网络环境的事。我一开始没意识到这点，对着结果研究了半天，后来换到本地物理机环境才正常。

还有一个细节：-p指定UDP端口时不用加U:前缀，因为-sU已经声明了协议。但如果你同时扫TCP和UDP，就得写成-p T:80,443,U:53,161，否则nmap会搞混。

扫UDP端口这件事，本质上是在一个不保证响应的协议上做推断。nmap已经尽力了，但结果永远带有不确定性。遇到open|filtered别急着下结论，结合-sV、换个时间再扫、或者直接用对应的客户端工具手动验证，才是靠谱的做法。