Impedir que a instância do Google Compute configure a segunda interface de rede

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.