很高兴你已经解决了Azure上的具体问题，针对你提到的通用UDP转发链路排查需求，我整理了几个Ubuntu默认自带的工具和实操方法，帮你在未来快速定位这类问题：

1. tcpdump：最精准的抓包分析 #

这是排查流量问题的核心工具，Ubuntu默认预装，能直接看到数据包的完整流转路径：

• 在负载均衡器节点（可访问时）抓包：
  运行tcpdump -i any udp port 5050 -vvv，可以看到：
  • 有没有外部测试的UDP数据包到达LB的5050端口
  • LB是否向目标服务器172.16.2.2:5075发出了转发后的数据包
• 在目标服务器抓包：
  运行tcpdump -i any udp port 5075 -vvv，确认是否收到来自LB的UDP数据包。如果LB抓包显示已转发，但目标没收到，大概率是路由、安全组或防火墙拦截了流量。

2. ss/netstat：验证端口监听状态 #

虽然UDP是无连接协议，但可以先确认端口是否正常监听：

• 查看目标服务器的监听状态：ss -ulnp | grep 5075，重点确认监听的IP是0.0.0.0（允许所有IP访问）还是仅限本地127.0.0.1
• 查看负载均衡器的端口状态：ss -ulnp | grep 5050，确认端口是否在正常接收UDP流量

3. traceroute：UDP路径追踪 #

你之前用的tracepath效果不好，可以试试指定UDP协议的traceroute：
运行traceroute -U -p 5050 172.16.1.1，其中-U强制使用UDP协议（默认traceroute用ICMP，很多设备会过滤ICMP）。虽然部分负载均衡器可能不会回应探测包，但至少能看到数据包能到达哪一跳就中断了，缩小排查范围。

4. nc（netcat）：模拟真实UDP流量 #

把nc从端口探测工具升级为流量测试工具：

• 在目标服务器上启动UDP监听：nc -ul 5075，这个命令会实时打印所有收到的UDP内容
• 在测试VM上发送UDP数据：nc -u 172.16.1.1 5050，输入任意文本后回车发送。如果LB转发正常，目标服务器的nc窗口会立刻显示你发送的内容；如果没收到，再结合tcpdump抓包定位丢包点。

额外排查思路 #

• 检查路由表：在测试VM和LB节点运行ip route，确认到目标服务器172.16.2.2的路由条目存在且正确
• 排查防火墙/安全组：
  • 本地防火墙：Ubuntu用ufw status查看是否允许UDP 5050/5075的出入流量
  • 云平台安全组：确认双向的UDP流量都被允许（UDP无连接，但很多设备需要放行回程流量）

这些工具都是Ubuntu默认预装的，完全云无关，不管是在公有云、私有云还是本地网络环境都能直接使用。

备注：内容来源于stack exchange，提问作者MJV