我在AWS上的ubuntu机器上有一个监听UDP端口的服务。另一台我无法控制的机器是向该服务发送数据包,但是这些数据包的源端口设置为68。当我的服务想要响应这些数据包时,它尝试将带有目的地端口68的UDP数据包发送回原始机器。由于某种原因,这些返回数据包永远不会到达它们的目的地。在syslog中还有一个非常可疑的日志条目,内容如下:
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.发布于 2018-01-13 18:33:57
如果设备是Cisco路由器,这可能是PAT问题,是8.4之前的版本。端口是根据分配的池进行转换的。
支持论坛链接如下: ASA和PIX将PAT端口分配范围划分为三个池:
我希望这能帮上忙。
https://serverfault.com/questions/891393
复制相似问题