我在 AWS 上的一台 ubuntu 机器上有一个监听 UDP 端口的服务。我无法控制的另一台机器正在向该服务发送数据包，但这些数据包的源端口设置为 68。当我的服务想要响应这些数据包时，它会尝试将目标端口为 68 的 UDP 数据包发送回原始机器。由于某种原因，这些返回的数据包永远无法到达目的地。在系统日志中还有一个非常可疑的日志条目，内容如下：
Jan 9 15:17:08 ip-172-31-118-74 dhclient[1019]: Discarding packet with bogus hlen.
这与这些数据包的生成相吻合。这是否意味着本地 dhclient 守护进程以某种方式拦截了这些数据包？
日志条目可能只是个幌子，但这些数据包仍然没有到达目的地。过去，当选择了不同的源端口时，这种方法是有效的，因此，我相信使用 68 端口是我遇到问题的原因。
一些 tcpdump 输出显示源端口设置为 68 的传入数据包。
10:38:04.892816 IP 1.1.1.1.68 > 172.31.118.74.500: BOOTP/DHCP, unknown (0x20), length 448
10:38:04.901687 IP 172.31.118.74.500 > 1.1.1.1.68: BOOTP/DHCP, unknown (0x20), length 481
10:38:08.893218 IP 1.1.1.1.68 > 172.31.118.74.500: BOOTP/DHCP, unknown (0x20), length 448
10:38:08.893835 IP 172.31.118.74.500 > 1.1.1.1.68: BOOTP/DHCP, unknown (0x20), length 481
10:38:16.093319 IP 1.1.1.1.68 > 172.31.118.74.500: BOOTP/DHCP, unknown (0x20), length 448
10:38:16.093908 IP 172.31.118.74.500 > 1.1.1.1.68: BOOTP/DHCP, unknown (0x20), length 481
10:38:24.901839 IP 172.31.118.74.500 > 1.1.1.1.68: BOOTP/DHCP, unknown (0xff) [|bootp]
（原有公网IP替换为1.1.1.1） 以及同一时间段的syslog输出
Jan 10 10:38:16 ip-172-31-118-74 dhclient[755]: Discarding packet with bogus hlen.
Jan 10 10:38:16 ip-172-31-118-74 dhclient[1019]: Discarding packet with bogus hlen.
答案1
如果设备是 Cisco 路由器，则可能是 8.4 之前的版本存在 PAT 问题。端口转换基于分配的池
来自以下支持论坛链接： ASA 和 PIX 将 PAT 端口分配范围划分为三个池：
- 1-511
- 512-1023
- 1024-65535
我希望这能有所帮助。