A instalação gráfica do convidado QEMU Deb9 falha ao obter a resposta DHCP durante a instalação

1

Meu objetivo é configurar alguns convidados baseados em QEMU / libvirt usando uma interface de ponte no host para que cada guest-VM tenha um endereço IP atribuído por DHCP em minha rede LAN. Eu configurei com sucesso e usei configurações de VM menos complexas e sei que meu hardware oferece suporte à virtualização, por isso vou tentar ir direto ao assunto, por assim dizer.

Topologia

Cada nó está conectado à ethernet de 1 Gbps (portanto, sem interfaces sem fio)

[roteador] --- [switch1] --- [switch2] --- [host]

Anfitrião

  • Executa o Ubuntu 16.04.5
  • 1 NIC de 1 Gbps configurada com dhcp para atividades de gerenciamento (em1)
  • 1 NIC de 1 Gbps configurada como uma ponte com um endereço IP estático (escravo br0 / eth1)
  • Conectividade de ponte testada com sucesso usando SSH & ping de host diferente na mesma rede LAN. Estou desabilitando explicitamente o protocolo spanning-tree no arquivo de interfaces, e o comando brctl show exibe corretamente minha bridge com eth1 como a única interface.

Tentativa de configuração do convidado com o virt-install

comando de instalação

virt-install --name={guest-name} --vcpus=2 --memory=4096 --network bridge=br0
--cdrom={.iso-img-path} --disk size=20,path={diskimg-path} --os-variant=debian8
--graphics vnc,password={pass},listen=0.0.0.0 --noautoconsole

Comportamento observado e solução de problemas até o momento

  • Conectado ao convidado VM VNC para instalação com êxito

  • O instalador gráfico do Debian 9 reporta uma falha na autoconfiguração da interface de rede do convidado para DHCP através da interface da ponte de host

  • comando ' sudo tcpdump -i br0 | grep -i dhcp '(saída abaixo) mostra apenas as solicitações sendo transmitidas e nenhuma resposta.

10:08:57.833669 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:8a:9e:69 (oui Unknown), length 300

Eu tenho um histórico técnico, mas não estou familiarizado com os detalhes de baixo nível e como solucionar problemas de DHCP corretamente.

UPDATE 1

Eu configurei o tshark no host do Ubuntu e conectei um laptop rodando o Wireshark via ethernet a uma das portas do switch no roteador.

Nota: Tanto quanto eu posso ver meu roteador não suporta qualquer espelhamento de porta ou monitoramento de porta.

Nova topologia

[roteador] --- [switch1] --- [switch2] --- [host-Tshark]

|

[Deb9.5-Wireshark]

Comando Tshark & Resultados

[]$ tshark -w out.pcap -f "udp port 68 or port 67" -i any

[]$ tshark -r out.pcap -V | grep -e Frame -e Bootstrap -e User\ Datagram\ Protocol -e Bootp\ flags -e "Internet Protocol Version 4"
Frame 295: 344 bytes on wire (2752 bits), 344 bytes captured (2752 bits) on interface 0
    Frame Number: 295
    Frame Length: 344 bytes (2752 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
    Bootp flags: 0x0000 (Unicast)
  • Eu iniciei o comando de captura acima, e rapidamente mudei para o meu VNC de instalação do debian 9 e tentei novamente a configuração automática de DHCP e, em seguida, parei rapidamente de capturar
  • Notei que a contagem de capturas começou a subir após a captura iniciada, mas ANTES de informar à instalação gráfica para tentar novamente a configuração do DHCP, todos os pacotes parecem iguais aos da saída acima. (alguns pacotes presos no ciclo de encaminhamento talvez?)
  • Eu tentei usar o Wireshark no laptop antes de usar o Tshark no host, então há alguns filtros que vou tentar quando chegar em casa, mas durante meus testes com o Wireshark eu não vi nenhum DHCP / BOOTP ( Discover) pacotes vêm através.
  • Os sinalizadores Bootp são marcados para unicast, mas o IP src / dst faz parecer que está tentando transmitir o pacote do Discover e aguardar uma resposta? Qualquer pessoa mais familiarizada com o DHCP poderia ajudar a esclarecer isso

Atualização 2 - resolução adicional

Então, a próxima coisa que tentei foi usar o endereço MAC nos pacotes DHCP Discover e configurar um IP estático na GUI do meu roteador. Isso foi bem-sucedido, pois permitiu que eu passasse pela parte de configuração de rede do instalador, mas falhou quando cheguei ao ponto em que precisava configurar o gerenciador de pacotes conectando-me a um servidor espelho.

Agora, a resolução ARP é algo que eu conheço e descobri que os pacotes ARP que estão sendo enviados não estavam recebendo uma resposta, semelhante aos pacotes DHCP descobertos. Quando inspecionei os pacotes de ping da interface de ponte de outro host na LAN, encontrei o endereço MAC incorreto no campo de origem da resposta. Acontece que o kernel Linux trata um endereço IP como um "objeto do sistema" em um sistema fracamente acoplado, então ter múltiplas interfaces conectadas à mesma rede (192.168.1.0/24) não garante qual interface física é usada para manipular pacotes pertencentes a um IP específico.

Para resolver isso, acabei de adicionar todas as interfaces físicas do sistema à definição da interface da bridge e tudo está funcionando agora após a reinicialização. Não é a minha configuração ideal, mas funciona e o DHCP funciona como esperado.

Mais informações: link

    
por user3282129 06.08.2018 / 20:51

0 respostas