O host não pode falar com a VM guest quando o IP é alterado de dinâmico dinâmico para estático

Question

TL; DR: O host pode fazer ping da VM Convidada conectada por NAT quando o IP do DHCP é usado no guest, não quando o ip estático é usado. Socorro.

Estou tentando configurar uma LAN baseada em NAT que o host possa se comunicar com o local em que cada VM possui um IP estático. De acordo com os documentos VMware, o comutador virtual vmnet tem um adaptador host conectado a ele, que aparece como 'vmnet #' (onde # é o número do adaptador) na saída ifconfig do host. Usando essa interface virtual, o host pode executar ping e se comunicar com as VMs convidadas conectadas ao mesmo switch virtual vmnet #.

Agora, primeiro criei um novo switch virtual chamado vmnet10. Configurei-o para ter um IP de sub-rede de 10.0.99.0/24 (NetMask: 255.255.255.0 ), um dispositivo NAT com o IP de 10.0.99.2 e um servidor DHCP (que, de acordo com os documentos VMware, reside em 10.0.99.254). Eu não alterei as configurações de DHCP automatizadas e, portanto, o intervalo 10.0.99.128 - 10.0.99.253 são IPs DHCP dinâmicos, enquanto 10.0.99.3 - 10.0.99.127 são IPs que eu posso atribuir estaticamente. É aí que o problema começa.

Quando o convidado da VM obtém o IP do servidor DHCP, (10.0.99.128) o adaptador do host é conectado a ele e o 10.0.99.1 pode efetuar ping de 10.0.99.128 e vice-versa. No entanto, se eu alterar o IP manualmente via nmtui, (gerando o seguinte arquivo /etc/sysconfig/network-scripts/ifcfg-ens33 ), mesmo que o vm ainda possa acessar a Internet e pingar outras VMs, o host não poderá acessá-lo e vice-versa. O que está acontecendo? É por causa do fato de que eu não pedi ao servidor DHCP por um IP estático ?! Como faço para corrigir isso?

O despejo de configuração para os sistemas descritos acima pode ser encontrado em este local .

    

Answer 1

EDIT : O método abaixo pode ou não ser necessário - no entanto, este passo em particular é um must . Uma rota estática precisa ser criada nas interfaces de convidado, uma vez que a tabela de roteamento existente pode estar errada. Mina originalmente parecia:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.99.2       0.0.0.0         UG    100    0        0 ens33
10.0.99.2       0.0.0.0         255.255.255.255 UH    100    0        0 ens33
10.0.99.11      0.0.0.0         255.255.255.255 UH    100    0        0 ens33
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Para isso, um arquivo /etc/sysconfig/network-scripts/route-ens33 (route- interface ) deve ser criado com a sintaxe:

default 10.0.99.2 dev ens33
10.0.99.0/24 dev ens33

Em que 10.0.99.2 é o endereço IP do Gateway (dispositivo NAT do VMware) e 10.0.99.0/24 é a sub-rede na qual os IPs estáticos existem, ou seja, a sub-rede da LAN. Após essa etapa, a interface deve ser reiniciada usando nmcli c d ens33; nmcli c u ens33 . A tabela de roteamento do kernel deve agora se parecer com:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.99.2       0.0.0.0         UG    100    0        0 ens33
10.0.99.0       0.0.0.0         255.255.255.0   U     100    0        0 ens33
...

Portanto, precisamos atribuir um IP estático às VMs convidadas mesmo quando os convidados não estão trabalhando com o DHCP. Como tal, o dhcpd.conf para o comutador virtual precisa ter entradas para cada IP estático. Como eu estava usando vmnet10 , editei o arquivo /etc/vmware/vmnet10/dhcpd/dhcpd.conf e adicionei:

...
####### VMNET DHCP Configuration. End of "DO NOT MODIFY SECTION" #######

####### VMNET Static IP Allocation Table by Somu                 #######
host vmInfra.somuVMnet.local {
    hardware ethernet 00:0C:29:79:8C:1F;
    fixed-address 10.0.99.99;
}

host vmPrime.somuVMnet.local {
    hardware ethernet 00:0C:29:3B:B9:1C;
    fixed-address 10.0.99.11;
}

host vmDeux.somuVMnet.local {
    hardware ethernet 00:0C:29:2A:E2:D3; 
    fixed-address 10.0.99.12;
}

Observe que cada endereço MAC corresponde às NICs virtuais atribuídas para cada VM. Essas configurações devem ser adicionadas após as VMs terem sido encerradas e a própria estação de trabalho do vmware ter sido desativada.

Finalmente, depois que a configuração é salva, como o serviço dhcp é executado na máquina host, eles precisam ser reiniciados. Como não consegui encontrar o serviço individual para cada VM, simplesmente reiniciei o vmware.service no próprio host. Note que estou usando systemd desde que eu estou no Fedora 27. Esse método deve funcionar igualmente bem para os sistemas operacionais System V também, mesmo que o comando seja diferente.

systemctl restart vmware; systemctl status -l vmware

Certifique-se de que o serviço esteja ativo e, em seguida, ligue seu convidado. Agora, se você configurou sua VM para ter um IP estático, ela deve corresponder ao IP que você definiu em dhcpd.conf apenas para evitar conflitos. Se estiver usando a configuração automática baseada em DHCP, isso não é um problema, já que o servidor DHCP agora irá atribuir o IP específico que você solicitou com base no endereço do MAC da NIC virtual!

Espero que esta resposta ajude alguém que está preso em uma situação semelhante e economize as incontáveis horas de pesquisa. Note que não precisei desligar o firewall nem no host nem no convidado!