Início / server / Perguntas / 1160372
Accepted
codenamezero
Asked: 2024-06-04 07:09:12 +0800 CST

É possível ativar a interface de rede após "ip link set eth0 down"?

  • 772

Eu tenho um contêiner docker em execução Ubuntu 18.04.

Executei-o com o seguinte comando, mas se eu desligar uma interface, não importa o que eu faça, mesmo que diga que a interface está ativa, não consigo mais ter nenhuma conexão com ela.

docker run --hostname=hello.world --cap-add=NET_ADMIN -it test-ubuntu18

Dentro do meu contêiner, eu costumava ip link set eth0 downdesabilitar temporariamente a rede, mas depois de ligá-la novamente, nada funciona.

Este é o meu Dockerfile

FROM ubuntu:18.04 as base

# Install base dependencies
RUN apt-get update && apt-get install -y -q --no-install-recommends \
    apt-transport-https build-essential ca-certificates curl dbus git \
    iputils-ping libssl-dev net-tools network-manager vim wget systemd \
    sudo rsyslog

ENV NVM_DIR /root/.nvm
ENV NODE_VERSION 17

RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash \
    && . $NVM_DIR/nvm.sh \
    && nvm install $NODE_VERSION \
    && nvm alias default $NODE_VERSION \
    && nvm use default

# Fix rsyslog start up by disable imklog
RUN sed -i 's/module(load="imklog"/#module(load="imklog"/' /etc/rsyslog.conf

ENTRYPOINT service rsyslog start && \
           service dbus start && \
           service network-manager start && \
           bash

Alguém sabe se é possível reativar a rede com um contêiner docker?

root@hello:~# ping google.com
PING google.com (172.217.13.110) 56(84) bytes of data.
64 bytes from 172.217.13.110 (172.217.13.110): icmp_seq=1 ttl=63 time=11.9 ms
64 bytes from 172.217.13.110 (172.217.13.110): icmp_seq=2 ttl=63 time=14.0 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 11.982/13.011/14.041/1.035 ms
root@hello:~# ip link set eth0 down
root@hello:~# ping google.com
ping: google.com: Temporary failure in name resolution
root@hello:~# ip link set eth0 up  
root@hello:~# ping google.com
ping: google.com: Temporary failure in name resolution
root@hello:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
269: eth0@if270: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
ubuntu

1 respostas

  1. Best Answer

    Quando você executa ip link set eth0 down, duas coisas acontecem:

    1. O estado do link muda para downe a interface não passa mais nenhum tráfego.
    2. Quaisquer rotas associadas à interface serão excluídas.

    Quando você corre ip link set eth0 up:

    1. O estado do link muda para upe as interfaces retomam a passagem do tráfego.
    2. Uma rota de dispositivo é criada para a rede à qual o link está associado.

    Leia atentamente o segundo passo acima: quaisquer rotas adicionais que estavam na sua tabela de roteamento antes de você desabilitar o link não serão recriadas.

    Por exemplo, se eu construir e executar seu Dockerfile localmente, o contêiner inicialmente terá um endereço:

    root@3194a6d67d5d:/# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
40: eth0@if41: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

    E uma tabela de roteamento:

    root@3194a6d67d5d:/# ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2

    Depois de executar ip link set eth0 down, vemos que o estado do link eth0mudou (mas ainda tem um endereço configurado):

    40: eth0@if41: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

    E a tabela de roteamento agora está vazia:

    root@3194a6d67d5d:/# ip route
<no output>

    Quando reativamos a interface executando ip link set eth0 up, a interface retorna à sua configuração inicial:

    root@3194a6d67d5d:/# ip addr show eth0
40: eth0@if41: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

    Mas agora a tabela de roteamento está assim:

    root@3194a6d67d5d:/# ip route
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2

    Observe que não existe uma rota padrão . Sem uma rota padrão, seu contêiner não sabe como alcançar outros endereços além daqueles aos quais está diretamente conectado. As tentativas de chegar a qualquer outro lugar falharão:

    root@3194a6d67d5d:/# ping -c1 google.com
ping: google.com: Temporary failure in name resolution

    (Estamos vendo uma "Falha temporária na resolução de nomes" aqui porque o contêiner não consegue acessar o servidor DNS configurado.)

    Podemos resolver esta situação recriando manualmente a rota padrão:

    root@3194a6d67d5d:/# ip route add default via 172.17.0.1
root@3194a6d67d5d:/# ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2

    E agora as coisas funcionaram como esperado:

    root@3194a6d67d5d:/# ping -c1 google.com
PING google.com (142.251.41.14) 56(84) bytes of data.
64 bytes from lga34s40-in-f14.1e100.net (142.251.41.14): icmp_seq=1 ttl=117 time=13.4 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 13.460/13.460/13.460/0.000 ms
    • 1

relate perguntas