Início / unix / Perguntas / 781319
Accepted
user632870
Asked: 2024-08-03 21:28:23 +0800 CST

Dispositivo de rede virtual assume a rota padrão e interrompe a conexão externa

  • 772

Estou encontrando um problema de rede em meu servidor Debian 12, onde a ativação de qualquer dispositivo de rede virtual - como ao iniciar o Docker ou iniciar uma VM com qemu-kvm - resulta no novo dispositivo virtual assumindo a rota de rede padrão. Essa alteração interrompe minha conexão de rede externa, causando perda de acesso à Internet. Normalmente, a conexão persiste após iniciar os serviços por cerca de 30 a 40 segundos, após os quais a saída ip route showmuda de:

default via 192.168.178.1 dev enp4s0
172.30.0.0/16 dev br-036d78a9f36a proto kernel scope link src 172.30.0.1 linkdown
172.31.0.0/24 dev docker0 proto kernel scope link src 172.31.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.178.0/24 dev enp4s0 proto kernel scope link src 192.168.178.10
192.168.178.1 dev enp4s0 scope link

para isso ao iniciar um contêiner docker com regras de rede padrão:

0.0.0.0 dev veth0136027 scope link
default dev veth0136027 scope link
default via 192.168.178.1 dev enp4s0
169.254.0.0/16 dev veth0136027 proto kernel scope link src 169.254.214.10
172.30.0.0/16 dev br-036d78a9f36a proto kernel scope link src 172.30.0.1 linkdown
172.31.0.0/24 dev docker0 proto kernel scope link src 172.31.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.178.0/24 dev enp4s0 proto kernel scope link src 192.168.178.10
192.168.178.0/24 dev veth0136027 proto kernel scope link src 192.168.178.20
192.168.178.1 dev enp4s0 scope link

ou isto ao iniciar uma VM via qemu-kvm:

0.0.0.0 dev vnet2 scope link
default dev vnet2 scope link
default via 192.168.178.1 dev enp4s0
169.254.0.0/16 dev vnet2 proto kernel scope link src 169.254.251.24
172.30.0.0/16 dev br-036d78a9f36a proto kernel scope link src 172.30.0.1 linkdown
172.31.0.0/24 dev docker0 proto kernel scope link src 172.31.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.178.0/24 dev enp4s0 proto kernel scope link src 192.168.178.10
192.168.178.0/24 dev vnet2 proto kernel scope link src 192.168.178.20
192.168.178.1 dev enp4s0 scope link

sobre o qual ambos ping google.come ping 8.8.8.8retornam

From 192.168.178.20 (192.168.178.20) icmp_seq=35 Destination Host Unreachablee

From 192.168.178.20 icmp_seq=36 Destination Host Unreachable

respectivamente.

Os logs de sudo journalctl -xeu systemd-networkdsão os seguintes:

Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Failed to start LLDP client: No such device
Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Could not process link message: No such device
Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Failed
Aug 03 14:27:41 callisto systemd-networkd[873]: veth5f934f0: Link DOWN
Aug 03 14:27:41 callisto systemd-networkd[873]: veth5f934f0: Lost carrier
Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Link DOWN
Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Lost carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: Link UP
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Link UP
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Gained carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: Gained carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: docker0: Gained carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Link UP
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Gained carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Link DOWN
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Lost carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: Lost carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: DHCPv6 lease lost
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: Link DOWN
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Link UP
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Gained carrier
Aug 03 14:38:38 callisto systemd-networkd[873]: docker0: Lost carrier
Aug 03 14:38:39 callisto systemd-networkd[873]: veth67c6d92: Gained IPv6LL
Aug 03 14:42:32 callisto systemd-networkd[873]: veth67c6d92: Lost carrier
Aug 03 14:42:32 callisto systemd-networkd[873]: veth67c6d92: DHCPv6 lease lost
Aug 03 14:42:32 callisto systemd-networkd[873]: veth67c6d92: Link DOWN

Coisas que já tentei incluem:

  • Definindo minha /etc/network/interfacesconfiguração para o seguinte:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp4s0
iface enp4s0 inet static
    address 192.168.178.10
    netmask 255.255.255.0
    gateway 192.168.178.1
    dns-nameservers 100.100.100.100

# This is an autoconfigured IPv6 interface
iface enp4s0 inet6 auto
  • Mudando do NetworkManager padrão para systemd-networkd com a seguinte configuração:
# /etc/systemd/network/10-enp4s0.network
[Match]
Name=enp4s0

[Network]
Address=192.168.178.10/24
Gateway=192.168.178.1
DNS=100.100.100.100
Priority=100
  • Excluir manualmente as novas rotas, que funcionou, mas não é uma solução prática
  • Desativando meu ufwfirewall, para ver se faz alguma diferença (não fez)

Por favor, desculpe quaisquer erros estúpidos ou lacunas de conhecimento de minha parte, estou mexendo com Linux e servidores em geral apenas como um hobby e na verdade não tenho formação nesta área.

debian

1 respostas

  1. Best Answer

    O procedimento descrito na postagem vinculada a este comentário funcionou. Primeiro você precisa editar o arquivo de configuração connman /etc/connman/main.confe descomentar a NetworkInterfaceBlacklistopção de configuração. Em seguida, basta adicionar as interfaces que você não deseja que assumam sua rota padrão, que no meu caso eram vethe vnet. Deverá então parecer algo assim: NetworkInterfaceBlacklist = veth, vnet. Agora basta salvá-lo e reiniciar o serviço connman systemctl restart connmanpara que ele tenha efeito.

    Eu tentei esse método antes, mas não consegui resolver o problema, pois acidentalmente adicionei um hífen à entrada da lista negra da interface ( veth-em vez de veth). Agora, depois de tentar novamente, funcionou perfeitamente.

    • 1

relate perguntas