Início / unix / Perguntas / 687546
Accepted
AFP_555
Asked: 2022-01-24 01:48:03 +0800 CST

Como pode "/sys/class/net/eth0/iflink" ter informações de todo o sistema em um contêiner

  • 772

Eu estava procurando maneiras de fazer o tcpdump de um pod do Kubernetes. Cada pod cria uma interface virtual e é difícil saber qual interface pertence ao pod real. Encontrei um método que ajuda a identificar o índice de interface de todo o sistema. Basicamente, é possível cat /sys/class/net/eth0/iflinkdentro de um container rodando no pod de destino, e ele mostrará o índice da interface de rede do host. Desta forma, você pode conhecer o veth que pertence ao pod.

Então, funcionou, mas me deixou pensando... por que posso obter informações de todo o sistema na rede se devo estar em um namespace de rede no contêiner. Portanto, não devo ter acesso ao índice de todo o sistema, devo ver apenas o índice virtual de "namespace" para a interface virtual.

Existe alguma explicação de como /sys/class/net/eth0/iflinkestá relacionado aos namespaces de rede dentro do K8s?

networking docker

1 respostas

  1. Best Answer

    O iflinkvalor não é um valor de todo o sistema. É um valor válido no nsid da rede peer, conforme exibido por exemplo com all ip link show dev eth0(já que é uma vethinterface com seu peer em outro namespace de rede). Para os pequenos detalhes, o nsid da rede peer não é um valor de todo o sistema, mas um valor válido apenas no namespace de rede atual que vincula a rede peer (em todo o sistema) a esse namespace de rede (em todo o sistema) porque em alguns vez que uma interface relacionada foi movida.

    Aqui está um exemplo, usando ip netns addand ip netns exec(que também (re)monta corretamente /sysem seu próprio namespace de montagem para poder usar entradas de rede em /sys).

    # ip netns add n1
# ip netns add n2
# ip netns add n3
# ip netns add n4

# ip -n n1 link add name ton2 index 42 type veth peer netns n2 name eth0
# ip -n n3 link add name ton4 index 42 type veth peer netns n4 name eth0


# ip netns exec n2 cat /sys/class/net/eth0/iflink
42
# ip -n n2 link show dev eth0
2: eth0@if42: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 0e:27:6f:19:05:02 brd ff:ff:ff:ff:ff:ff link-netns n1
# ip netns exec n4 cat /sys/class/net/eth0/iflink
42
# ip -n n4 link show dev eth0
2: eth0@if42: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether fe:09:53:11:84:d6 brd ff:ff:ff:ff:ff:ff link-netns n3

    Ambas as interfaces têm um link de peer com valor de índice 42, mas isso não representa a mesma interface: um valor 42 é ton2o valor de índice de ' em netns n1, o outro é ton4o valor de índice de ' em netns n3. Se as versões modernas de ip linknão resolverem o link-nsid para os nomes reais designados ip netns addpelos namespaces de mesmo nível, ambos serão mostrados como link-netnsid 0abaixo (porque esse é o único namespace de rede de mesmo nível e o link-nsid começa por padrão em 0, a menos que definido caso contrário, em cada namespace de rede), novamente com 0 não sendo em todo o sistema.

    # stat -f -c %T /run/netns/n1 /run/netns/n3
nsfs
nsfs
# stat -c %i /run/netns/n1 /run/netns/n3
4026533318
4026533590

    O valor real de todo o sistema para o peer é o namespace da rede + o índice. Aqui seria 4026533318:42 e 4026533590:42 . Mas pode ser bastante desafiador descobrir simplesmente esse namespace de rede quando ele não for o namespace de rede inicial (como neste exemplo) se não souber como ele foi criado (aqui com ip netnso qual deixa uma referência montada em /run/netns).

    Informações adicionais sobre isso disponíveis nesta resposta que fiz.

    • 3

relate perguntas