Estou criando uma VM no Google Compute Engine executando o Debian Buster e configurando-a com duas interfaces de rede.
O primeiro usa uma configuração de IP efêmera e é atribuído a uma rede roteável publicamente, configurada via DHCP. Eu gostaria de manter isso como está.
A segunda interface usa uma configuração de IP estático e é atribuída a uma rede privada. Gostaria de impedir o GCE de usar o DHCP para configurar essa interface e, em vez disso, usar o systemd-networkd para configurá-lo sozinho, com o objetivo de adicionar facilmente algumas rotas personalizadas.
Embora a configuração do systemd-networkd funcione com sucesso, o problema é que, quando a máquina é reinicializada, a configuração do DHCP do GCE está sendo executada após a configuração do systemd-networkd e substituindo minha configuração personalizada.
Eu tentei várias coisas para resolver esse problema até agora, incluindo:
- Desabilite a entrada para /var/run/interfaces.d em /etc/network/interfaces
- Adicione um serviço systemd personalizado para ser executado após os serviços de rede do GCE
A única coisa que funcionou até agora é um hack de script hediondo para esperar 30 segundos após a inicialização e, em seguida, iniciar o systemd-networkd novamente para substituir a configuração do GCE.
Existe alguma alteração de configuração mais limpa que eu possa fazer no nível do sistema operacional ou uma configuração durante a configuração da rede/servidor que impedirá o GCE de configurar automaticamente essa segunda interface de rede?
EDIÇÃO #1:
Este é um exemplo da configuração systemd-networkd que eu prefiro usar:
[Match]
Name=ens5
[Network]
Address=10.1.3.30/32
LinkLocalAddressing=no
[Route]
Destination=10.1.3.1/32
Scope=link
[Route]
Gateway=10.1.3.1
Destination=10.1.3.0/24
GatewayOnlink=yes
[Route]
Gateway=10.1.3.1
Destination=10.1.1.0/24
GatewayOnlink=yes
[Route]
Gateway=10.1.3.1
Destination=10.1.2.0/24
GatewayOnlink=yes
[Route]
Gateway=10.1.3.1
Destination=10.10.0.0/24
GatewayOnlink=yes
Usar essa configuração me permite definir rotas adicionais na interface para outras sub-redes. Observe que essas outras sub-redes podem ou não estar no GCP.
A configuração acima funciona, mesmo que eu tenha que declarar o endereço IP estático 10.1.3.30 como parte da configuração do meu servidor GCE. O problema é que não consigo fazer com que o GCE pare de fazer sua própria configuração da interface, que substitui a acima. No Azure, posso simplesmente comentar a sourcereferência /var/run/network/interfaces.dem /etc/network/interfaces.
Quanto ao motivo pelo qual eu prefiro essa configuração, é um método elegante para configurar minha rede interna por meio do software de gerenciamento de configuração do servidor - eu apenas coloco a configuração acima /etc/systemd/network/e emito systemctl enable systemd-networkd && systemctl restart systemd-networkd, e ele lida com a configuração da interface e a configuração para também acontecer na inicialização.
ATUALIZAÇÃO #1:
Eu arquivei https://issuetracker.google.com/issues/153513472 no rastreador de problemas do GCP, espero que eles resolvam. Vou atualizar o problema de acordo quando eles o fizerem.
ATUALIZAÇÃO #2:
Após uma rodada com suporte pago do GCP, eles me apontaram para outro problema em andamento: https://issuetracker.google.com/issues/167371074
O agente de suporte também sugeriu que outros usuários simplesmente colocassem scripts cron para reiniciar a rede periodicamente.
Adaptei esta sugestão para minhas necessidades específicas de rede, com a seguinte entrada crontab:
* * * * * /usr/bin/test -z "$(/sbin/ip route | /bin/grep "10.1.1.0/24")" && /bin/systemctl restart systemd-networkd
Onde '10.1.1.0/24' é uma sub-rede que eu sei que na minha configuração de roteamento não deve faltar.
ATUALIZAÇÃO #3:
Finalmente, uma resposta limpa e satisfatória! Os engenheiros do Google me informaram que o google-guest-agent.serviceque é executado como parte de seu ambiente convidado em sistemas Debian tem um daemon de rede, que, quando reconfigura qualquer interface, chama dhclientdiretamente. Parece que o dhclientchamado desta forma elimina as rotas existentes. Dado isso, uma solução fácil é criar um gancho de saída dhclient adicionando um script de shell no arquivo /etc/dhcp/dhclient-exit-hooks.d/.
No meu caso, adicionei o seguinte script em /etc/dhcp/dhclient-exit-hooks.d/systemd-networkd:
case $reason in
BOUND|RENEW|REBIND|REBOOT)
systemctl restart systemd-networkd.service
;;
esac
Isso parece resolver o problema, inclusive nas reinicializações.
