为什么我的 ISP 的 DHCP 服务器在虚拟接口上时 dhclient 会失败?

And*_*w B 3 virtual-machine dhcp debian

最近我从 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 Internet Systems Consortium。
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:在套接字/回退上发送
Feb 1 20:58:38 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
Feb 1 20:58:42 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5
Feb 1 20:58:47 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 9
Feb 1 20:58:56 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
Feb 1 20:59:10 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
Feb 1 20:59:18 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
Feb 1 20:59:26 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 9
Feb 1 20:59:35 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 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:在套接字/回退上发送
Feb 1 21:16:04 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 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
Feb 1 21:16:51 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Feb 1 21:16:58 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 15
Feb 1 21:17:13 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Feb 1 21:17:20 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10
Feb 1 21:17:30 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10
Feb 1 21:17:40 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 12
2 月 1 日 21:17:52 myhost dhclient:未收到 DHCPOFFERS。
Feb 1 21:17:52 myhost dhclient:持久数据库中没有工作租约 - 睡眠。
  • 在我的特殊情况下,这是一个 EMTA 调制解调器,它也为我的房子提供电话服务。我的电话服务正在工作,我就是无法获得 IP 地址。
  • 我曾尝试致电我的 ISP 并使用电话菜单向我的调制解调器发送重置信号,同时按住重置按钮以触发出厂重置并重新下载固件。这些都没有解决问题。
  • 我有一个备用的 DOCSIS 3.0 电缆调制解调器。我与技术人员合作将其 MAC 地址暂时列入白名单,但我遇到了完全相同的问题,没有看到 DHCP 响应。

我试着打电话给康卡斯特,询问他们我的 MAC 地址是否以某种方式被列入黑名单,但他们拒绝升级我的电话,而不为我的帐户添加高级技术支持服务。(包括一次性激活费,以阻止我在问题解决后立即退订)

为什么我的 VM 无法获得 DHCP 响应?

And*_*w B 5

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

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

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

  • 分配给您实际拥有的物理网络端口
  • 不由基础架构中的另一个 VM 持有(可能会混淆虚拟化平台)
  • 将不会被您分配给它的 VM 看到
  • 不会被该网段上的任何其他机器看到

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