Por que o dhclient falha com o servidor DHCP do meu ISP em uma interface virtual?

Question

Recentemente eu mudei de um T1 para um serviço de cabo residencial (Comcast). Eu tenho uma máquina virtual (XenServer 5.6) rodando Debian 6.0.6 que está agindo como o gateway padrão para minha rede doméstica, mas por alguma razão parece que o servidor DHCP a montante está ignorando minhas solicitações DHCPDISCOVER completamente.

Feb  1 20:58:34 myhost dhclient: Internet Systems Consortium DHCP Client 4.1.1-P1
Feb  1 20:58:34 myhost dhclient: Copyright 2004-2010 Internet Systems Consortium.
Feb  1 20:58:34 myhost dhclient: All rights reserved.
Feb  1 20:58:34 myhost dhclient: For info, please visit https://www.isc.org/software/dhcp/
Feb  1 20:58:34 myhost dhclient:
Feb  1 20:58:34 myhost dhclient: Listening on LPF/eth1/26:ac:40:50:5b:c7
Feb  1 20:58:34 myhost dhclient: Sending on   LPF/eth1/26:ac:40:50:5b:c7
Feb  1 20:58:34 myhost dhclient: Sending on   Socket/fallback
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
Feb  1 20:59:39 myhost dhclient: No DHCPOFFERS received.
Feb  1 20:59:39 myhost dhclient: No working leases in persistent database - sleeping.

• Tudo está conectado corretamente e o tráfego está sendo conectado à interface correta na máquina virtual. Se eu ouvir todo o tráfego usando tcpdump , posso ver muito tráfego ARP, bem como o servidor DHCP do meu ISP respondendo a outros clientes que estão solicitando endereços IP. Meus pacotes DHCP estão sendo transmitidos, mas as respostas não retornam.
• Se eu iniciar dhclient antes que o modem tenha sido completamente inicializado, ele exibirá um endereço IP privado no intervalo de rede 192.168.100.0/24 com um intervalo de atualização baixo, para que dhclient atenda ao endereço IP público quando ele for pronto para ser servido. Ele continua a enviar DHCPACK de respostas para a rede privada até que esteja pronto para fazer a ponte entre as redes, quando eu paro de receber as respostas de um servidor DHCP novamente.

Feb  1 21:16:02 myhost dhclient: Listening on LPF/eth1/26:ac:40:50:5b:c7
Feb  1 21:16:02 myhost dhclient: Sending on   LPF/eth1/26:ac:40:50:5b:c7
Feb  1 21:16:02 myhost dhclient: Sending on   Socket/fallback
Feb  1 21:16:04 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
Feb  1 21:16:04 myhost dhclient: DHCPOFFER from 192.168.100.1
Feb  1 21:16:04 myhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Feb  1 21:16:05 myhost dhclient: DHCPACK from 192.168.100.1
Feb  1 21:16:05 myhost dhclient: bound to 192.168.100.10 -- renewal in 14 seconds.
Feb  1 21:16:19 myhost dhclient: DHCPREQUEST on eth1 to 192.168.100.1 port 67
Feb  1 21:16:20 myhost dhclient: DHCPACK from 192.168.100.1
Feb  1 21:16:20 myhost dhclient: bound to 192.168.100.10 -- renewal in 13 seconds.
Feb  1 21:16:33 myhost dhclient: DHCPREQUEST on eth1 to 192.168.100.1 port 67
Feb  1 21:16:36 myhost dhclient: DHCPREQUEST on eth1 to 192.168.100.1 port 67
Feb  1 21:16:43 myhost dhclient: DHCPREQUEST on eth1 to 192.168.100.1 port 67
Feb  1 21:16:50 myhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 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
Feb  1 21:17:52 myhost dhclient: No DHCPOFFERS received.
Feb  1 21:17:52 myhost dhclient: No working leases in persistent database - sleeping.

• No meu caso particular, este é um modem EMTA que também fornece serviço telefônico para minha casa. Meu serviço de telefone está funcionando, só não consigo um endereço IP.
• Tentei ligar para o meu provedor e usar o menu do telefone para enviar um sinal de redefinição ao meu modem, além de manter pressionado o botão de redefinição para acionar uma redefinição de fábrica e fazer o download novamente do firmware. Nenhum destes resolveu o problema.
• Eu tenho um modem a cabo DOCSIS 3.0 de reposição. Eu trabalhei com um técnico para colocar na lista de permissões temporariamente seu endereço MAC, mas estou tendo exatamente o mesmo problema de não ver as respostas do DHCP.

Eu tentei ligar para a Comcast para perguntar se meu endereço MAC estava na lista negra de alguma forma, mas eles estão se recusando a escalar minha chamada sem adicionar um serviço de suporte técnico premium à minha conta. (incluindo uma taxa de ativação única para me desencorajar de cancelar a inscrição imediatamente quando meu problema for resolvido)

Por que minha VM não pode receber uma resposta DHCP?

    

Answer 1

Não use endereços MAC virtuais gerados automaticamente com seu ISP.

Se você estiver usando um endereço MAC completamente aleatório ou um prefixo que não seja de fornecedor, estará correndo o risco de que seu endereço MAC confunda a infraestrutura do seu provedor de serviços de Internet.

A solução é falsificar o endereço MAC de uma placa de rede existente: de preferência, uma placa antiga de 10 bases que você nunca pretende usar novamente, mas qualquer endereço MAC que se ajuste aos seguintes critérios será:

• É atribuído a uma porta de rede física que você realmente possui
• Não é mantido por outra VM em sua infraestrutura (pode confundir a plataforma de virtualização)
• Não será visto pela VM que você está atribuindo a
• Não será visto por nenhuma outra máquina nesse segmento de rede

Reconfigure sua NIC virtual para falsificar esse endereço MAC, confirme se as alterações estão visíveis para o seu SO e reinicie seu modem a cabo . Eu fui capaz de demonstrar várias vezes no meu cenário particular que a etapa de reinicialização do modem a cabo era necessária.

    

Answer 2

A outra resposta dizendo que é a VM MAC está muito próxima da direita. Primeiro, vamos esclarecer uma pequena confusão sua - o modem faz uma requisição DHCP para o servidor upstream. Obtém um endereço não rotativo que é utilizado pela Comcast, por ex. %código%. Você faz uma requisição DHCP para o modem em si, e lhe dá o IP da WAN pública que o modem foi atribuído pelo ISP.

De qualquer forma, voltemos ao seu problema. O modem "liga" ao primeiro MAC que vê. Portanto, se o sistema operacional host tiver tentado qualquer coisa nessa porta antes de a VM inicializar e tentar falar com ela, o modem ignorará todos os pacotes provenientes da VM. Eu era capaz de fazer o que você queria no passado com o VMWare no RHEL, permitindo que o RHEL exibisse a NIC (dedicada), mas não havia nenhum IP associado a ela (e o BootP / DHCP estava desativado). Então, quando a VM inicializa e tenta se conectar, é o primeiro pacote que o modem vê na linha. Portanto, para fazer isso, você precisa de pelo menos duas NICs no host físico; o sistema operacional host não pode fazer mais nada com essa porta; é uma conexão direta apenas com o modem.