☰

为什么 dhclient 在虚拟接口上使用 ISP 的 DHCP 服务器失败？

tag-icon • tag-icon debian virtual-machine dhcp
为什么 dhclient 在虚拟接口上使用 ISP 的 DHCP 服务器失败？

最近我从 T1 切换到住宅有线电视服务 (Comcast)。我有一台运行 Debian 6.0.6 的虚拟机 (XenServer 5.6)，它充当我的家庭网络的默认网关，但由于某种原因，上游 DHCP 服务器似乎完全忽略了我的DHCPDISCOVER请求。

2 月 1 日 20:58:34 myhost dhclient：互联网系统联盟 DHCP 客户端 4.1.1-P1
2 月 1 日 20:58:34 myhost dhclient：版权所有 2004-2010 互联网系统联盟。
2 月 1 日 20:58:34 myhost dhclient：保留所有权利。
2 月 1 日 20:58:34 myhost dhclient：有关信息，请访问 https://www.isc.org/software/dhcp/
2 月 1 日 20:58:34 myhost dhclient：
2 月 1 日 20:58:34 myhost dhclient：监听 LPF/eth1/26:ac:40:50:5b:c7
2 月 1 日 20:58:34 myhost dhclient：在 LPF/eth1/26:ac:40:50:5b:c7 上发送
2 月 1 日 20:58:34 myhost dhclient：在套接字/后备上发送
2 月 1 日 20:58:38 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 4
2 月 1 日 20:58:42 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 5
2 月 1 日 20:58:47 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 9
2 月 1 日 20:58:56 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 14
2 月 1 日 20:59:10 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 8
2 月 1 日 20:59:18 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 8
2 月 1 日 20:59:26 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 9
2 月 1 日 20:59:35 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 4
2 月 1 日 20:59:39 myhost dhclient：未收到 DHCPOFFERS。
2 月 1 日 20:59:39 myhost dhclient：持久数据库中没有工作租约 - 休眠。
  • 一切都已正确连接，并且流量正在桥接到虚拟机上的正确接口。如果我使用 监听所有流量tcpdump，我可以看到大量 ARP 流量以及我的 ISP 的 DHCP 服务器响应其他请求 IP 地址的客户。我的 DHCP 数据包正在广播，但没有返回答案。
  • 如果我dhclient在调制解调器完全初始化之前启动，它将192.168.100.0/24以较低的刷新间隔提供网络范围内的专用 IP 地址，以便dhclient在准备好提供服务时获取公共 IP 地址。它继续发送DHCPACK专用网络的响应，直到准备好桥接网络，此时我将停止再次从 DHCP 服务器获取响应。
2 月 1 日 21:16:02 myhost dhclient：监听 LPF/eth1/26:ac:40:50:5b:c7
2 月 1 日 21:16:02 myhost dhclient：在 LPF/eth1/26:ac:40:50:5b:c7 上发送
2 月 1 日 21:16:02 myhost dhclient：在套接字/后备上发送
2 月 1 日 21:16:04 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 8
2 月 1 日 21:16:04 myhost dhclient：来自 192.168.100.1 的 DHCPOFFER
2 月 1 日 21:16:04 myhost dhclient：eth1 上的 DHCPREQUEST 到 255.255.255.255 端口 67
2 月 1 日 21:16:05 myhost dhclient：来自 192.168.100.1 的 DHCPACK
2 月 1 日 21:16:05 myhost dhclient：绑定到 192.168.100.10 —— 14 秒内更新。
2 月 1 日 21:16:19 myhost dhclient：eth1 上的 DHCPREQUEST 到 192.168.100.1 端口 67
2 月 1 日 21:16:20 myhost dhclient：来自 192.168.100.1 的 DHCPACK
2 月 1 日 21:16:20 myhost dhclient：绑定到 192.168.100.10 —— 13 秒内更新。
2 月 1 日 21:16:33 myhost dhclient：eth1 上的 DHCPREQUEST 到 192.168.100.1 端口 67
2 月 1 日 21:16:36 myhost dhclient：eth1 上的 DHCPREQUEST 到 192.168.100.1 端口 67
2 月 1 日 21:16:43 myhost dhclient：eth1 上的 DHCPREQUEST 到 192.168.100.1 端口 67
2 月 1 日 21:16:50 myhost dhclient：eth1 上的 DHCPREQUEST 到 255.255.255.255 端口 67
2 月 1 日 21:16:51 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 7
2 月 1 日 21:16:58 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 15
2 月 1 日 21:17:13 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 7
2 月 1 日 21:17:20 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 10
2 月 1 日 21:17:30 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 10
2 月 1 日 21:17:40 myhost dhclient：eth1 上的 DHCPDISCOVER 到 255.255.255.255 端口 67 间隔 12
2 月 1 日 21:17:52 myhost dhclient：未收到 DHCPOFFERS。
2 月 1 日 21:17:52 myhost dhclient：持久数据库中没有工作租约 - 休眠。
  • 就我的具体情况而言，这是一个 EMTA 调制解调器，它还为我家提供电话服务。我的电话服务正常，只是无法获取 IP 地址。
  • 我尝试拨打我的 ISP 并使用电话菜单向我的调制解调器发送重置信号，以及按住重置按钮以触发恢复出厂设置并重新下载固件。这些都没有解决问题。
  • 我有一个备用的 DOCSIS 3.0 电缆调制解调器。我与技术人员合作暂时将其 MAC 地址列入白名单，但我遇到了完全相同的问题，看不到 DHCP 响应。

我尝试致电康卡斯特询问他们我的 MAC 地址是否已被列入黑名单，但他们拒绝在不向我的帐户添加高级技术支持服务的情况下升级我的电话。 （包括一次性激活费，以防止我在问题解决后立即取消订阅）

为什么我的虚拟机无法获得 DHCP 响应？

答案1

不要使用 ISP 自动生成的虚拟 MAC 地址。

无论您使用完全随机的 MAC 地址还是非供应商前缀，您都面临着 MAC 地址混淆 ISP 基础设施的风险。

解决方法是欺骗现有网卡的 MAC 地址：最好是您永远不会再使用的旧 10 基卡，但任何符合以下条件的 MAC 地址都可以：

  • 分配给您实际拥有的物理网络端口
  • 未被基础架构中的其他虚拟机所持有（可能会混淆虚拟化平台）
  • 否则不会被您分配给的虚拟机看到
  • 该网段上的任何其他机器都看不到

重新配置您的虚拟 NIC 以欺骗该 MAC 地址，确认更改对您的操作系统可见，并且重新启动电缆调制解调器。我能够在我的特定场景中多次证明电缆调制解调器重新启动步骤是必要的。

答案2

另一个答案说是 VM MAC，非常接近正确。首先，让我们澄清一下您的一些困惑 - 调制解调器向上游服务器发出 DHCP 请求。它获得康卡斯特使用的不可路由的地址，例如10.x.x.x。您向调制解调器本身发出 DHCP 请求，它会为您提供 ISP 为调制解调器分配的公共 WAN IP。

无论如何，回到你的问题。调制解调器“绑定”到它看到的第一个 MAC。因此，如果您的主机操作系统尝试任何事物在虚拟机启动并尝试与其通信之前，在该端口上，调制解调器将忽略来自虚拟机的任何数据包。通过允许 RHEL 启动（专用）NIC，我能够在 RHEL 上使用 VMWare 完成您过去想做的事情，但没有与其关联的 IP（并且 BootP/DHCP 已关闭）。然后，当虚拟机启动并尝试连接时，它是调制解调器在线路上看到的第一个数据包。因此，要做到这一点，物理主机中至少需要有两个网卡；主机操作系统不能使用该端口执行任何其他操作；它只是与调制解调器的直接连接。

相关内容