Почему dhclient терпит неудачу с DHCP-сервером моего ISP на виртуальном интерфейсе?

Недавно я переключился с T1 на жилую кабельную службу (Comcast). У меня есть виртуальная машина (XenServer 5.6), работающая под управлением Debian 6.0.6, которая действует как шлюз по умолчанию для моей домашней сети, но по какой-то причине похоже, что DHCP-сервер DHCPDISCOVER полностью игнорирует мои запросы DHCPDISCOVER .

 1 февраля 20:58:34 myhost dhclient: Консорциум Internet Systems Клиент DHCP 4.1.1-P1
 1 февраля 20:58:34 myhost dhclient: Copyright 2004-2010 Internet Systems Consortium.
 Feb 1 20:58:34 myhost dhclient: Все права защищены.
 Feb 1 20:58:34 myhost dhclient: Для получения информации посетите https://www.isc.org/software/dhcp/
 Feb 1 20:58:34 myhost dhclient:
 1 февраля 20:58:34 myhost dhclient: Прослушивание на LPF / eth1 / 26: ac: 40: 50: 5b: c7
 Feb 1 20:58:34 myhost dhclient: Отправка по LPF / eth1 / 26: ac: 40: 50: 5b: c7
 Feb 1 20:58:34 myhost dhclient: Отправка на Socket / backback
 Feb 1 20:58:38 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 4
 Feb 1 20:58:42 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 5
 Feb 1 20:58:47 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 9
 1 февраля 20:58:56 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 14
 1 февраля 20:59:10 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 8
 Feb 1 20:59:18 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 8
 Feb 1 20:59:26 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 9
 Feb 1 20:59:35 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 4
 1 февраля 20:59:39 myhost dhclient: не получено DHCPOFFERS.
 Feb 1 20:59:39 myhost dhclient: Без работы в постоянной базе данных - спать.
  • Все правильно подключено, и трафик соединяется с правильным интерфейсом на виртуальной машине. Если я слушаю весь трафик с помощью tcpdump , я могу видеть много трафика ARP, а также DHCP-сервер моего провайдера, отвечающий на других клиентов, которые запрашивают IP-адреса. Мои пакеты DHCP транслируются, но ответы не возвращаются.
  • Если я начну dhclient до того, как модем завершит полную инициализацию, он будет обслуживать частный IP-адрес в сетевом диапазоне 192.168.100.0/24 с низким интервалом обновления, чтобы dhclient подхватил публичный IP-адрес, когда он будет готов к обслуживанию. Он продолжает отправлять ответы DHCPACK для частной сети, пока не будет готов к мосту сетей, после чего я перестаю получать ответы с сервера DHCP.
 Feb 1 21:16:02 myhost dhclient: Прослушивание на LPF / eth1 / 26: ac: 40: 50: 5b: c7
 Feb 1 21:16:02 myhost dhclient: Отправка на LPF / eth1 / 26: ac: 40: 50: 5b: c7
 Feb 1 21:16:02 myhost dhclient: Отправка на Socket / fallback
 Feb 1 21:16:04 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 8
 Feb 1 21:16:04 myhost dhclient: DHCPOFFER от 192.168.100.1
 Feb 1 21:16:04 myhost dhclient: DHCPREQUEST на eth1 до 255.255.255.255 порт 67
 Feb 1 21:16:05 myhost dhclient: DHCPACK от 192.168.100.1
 Feb 1 21:16:05 myhost dhclient: привязан к 192.168.100.10 - обновление за 14 секунд.
 Feb 1 21:16:19 myhost dhclient: DHCPREQUEST на eth1 до 192.168.100.1 порт 67
 Feb 1 21:16:20 myhost dhclient: DHCPACK от 192.168.100.1
 Feb 1 21:16:20 myhost dhclient: привязано к 192.168.100.10 - обновление за 13 секунд.
 Feb 1 21:16:33 myhost dhclient: DHCPREQUEST на eth1 до 192.168.100.1 порт 67
 Feb 1 21:16:36 myhost dhclient: DHCPREQUEST на eth1 до 192.168.100.1 порт 67
 Feb 1 21:16:43 myhost dhclient: DHCPREQUEST на eth1 до 192.168.100.1 порт 67
 Feb 1 21:16:50 myhost dhclient: DHCPREQUEST на eth1 до 255.255.255.255 порт 67
 Feb 1 21:16:51 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 7
 Feb 1 21:16:58 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 15
 Feb 1 21:17:13 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 7
 Feb 1 21:17:20 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 10
 Feb 1 21:17:30 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 10
 Feb 1 21:17:40 myhost dhclient: DHCPDISCOVER на eth1 до 255.255.255.255 порт 67 интервал 12
 Feb 1 21:17:52 myhost dhclient: не получено DHCPOFFERS.
 Feb 1 21:17:52 myhost dhclient: Нет действующей аренды в постоянной базе данных - спать.
  • В моем конкретном случае это модем EMTA, который также предоставляет телефонное обслуживание моему дому. Моя телефонная служба работает, я просто не могу получить IP-адрес.
  • Я попробовал обратиться к своему интернет-провайдеру и использовать меню телефона, чтобы отправить сигнал сброса на модем, а также удерживая кнопку сброса, чтобы вызвать перезагрузку и повторную загрузку прошивки. Ни одна из них не решила проблему.
  • У меня есть запасной кабель DOCSIS 3.0. Я работал с техническим специалистом, чтобы временно переустановить его MAC-адрес, но у меня возникла такая же проблема, что и при отсутствии ответов DHCP.

Я попробовал позвонить Comcast, чтобы спросить их, был ли мой MAC-адрес каким-то образом занесен в черный список, но они отказываются эскалировать мой звонок, не добавляя премиум-службу технической поддержки моей учетной записи. (включая единовременную плату за активацию, чтобы отговорить меня от немедленной отмены подписки, когда моя проблема решена)

Почему моя VM не может получить ответ DHCP?

Не используйте автоматически созданные виртуальные MAC-адреса с вашим интернет-провайдером.

Независимо от того, используете ли вы полностью рандомизированный MAC-адрес или префикс не-поставщика, вы рискуете, что ваш MAC-адрес будет путать инфраструктуру вашего провайдера.

Обходной путь – обмануть MAC-адрес существующей сетевой карты: желательно старую 10-базовую карту, которую вы никогда не планируете использовать повторно, но любой MAC-адрес, который соответствует следующим критериям, будет:

  • Назначается физическому сетевому порту, который вы фактически являетесь владельцем
  • Не удерживается другой виртуальной машиной в вашей инфраструктуре (может запутать платформу виртуализации)
  • В противном случае виртуальная машина, которую вы назначаете, не будет
  • Не будет видно ни одна другая машина на этом сегменте сети

Переконфигурируйте свой виртуальный сетевой адаптер, чтобы подделать этот MAC-адрес, подтвердите, что изменения видны вашей ОС, и перезагрузите ваш кабельный модем . В моем конкретном сценарии мне удалось несколько раз продемонстрировать, что необходим шаг перезагрузки кабельного модема.

Другой ответ, говорящий, что это VM MAC, очень близок к правилу. Во-первых, давайте немного распутаем ваше мнение – модем выполняет DHCP-запрос на восходящий сервер. Он получает неиспользуемый адрес, который используется Comcast, например, 10.xxx . Вы выполняете запрос DHCP самому модему, и он дает вам общедоступный IP-адрес WAN, который модем назначил провайдером.

Во всяком случае, вернемся к вашей проблеме. Модем «связывает» с первым MAC, который он видит. Поэтому, если ваша хост-система пыталась что-либо на этом порту до того, как VM загрузилась и попыталась с ней поговорить, модем будет игнорировать любые пакеты, поступающие с виртуальной машины. Я смог сделать то, что вы хотели в прошлом, с VMWare на RHEL, разрешив RHEL поднять (выделенный) сетевой адаптер, но с ним не связался IP (и BootP / DHCP был отключен). Затем, когда VM загружается и пытается подключиться, это первый пакет, который модем видит на линии. Чтобы сделать это, вам нужно как минимум два сетевых адаптера на физическом хосте; ОС хоста не может ничего сделать с этим портом; это прямое подключение к модему.