Eu gostaria de espelhar apenas um tráfego de pacotes muito limitado destinado a uma única porta IP e UDP para o mesmo IP, mas uma segunda porta. Eu bloqueei em https://superuser.com/questions/1593995/iptables-nftables-forward-udp-data-to-multiple-targets , mas parece que a instrução dup do nftable só permite duplicar para outro IP, mas não o mesmo IP e porta diferente.

Por exemplo, o tráfego para 127.0.0.1 porta 123 deve ser duplicado para 127.0.0.1 porta 456. Como esta é a única duplicação, não tenho nenhum problema com a perda do número da porta original. Agora eu me pergunto se esse tipo de duplicação é possível porque 127.0.0.1 não é uma interface de "drenagem"/saída, mas o destino final da duplicata. Poderia haver alguma maneira de combinar isso com DNAT?

Existe algum outro mecanismo disponível além de anexar uma sonda eBPF ao netdev com o tráfego UDP de entrada?

Ao usar o RTLINK para consultar a rota IP disponível de um kernel Linux (com namespace de rede), notei que em um sistema de teste o RTLINK retorna uma rota sem um RTA_OIFatributo, ou seja, sem uma interface de rede de saída especificada.

Infelizmente, não tenho ideia de como reproduzir essa situação (para teste) usando o ip route addcomando e até agora nenhuma pessoa ao meu alcance conseguiu explicar "o que" originalmente criou essa rota sem qualquer indicação de uma interface de rede de saída. De uma olhada nas fontes do kernel do Linux, notei que o atributo de interface de rede de saída na verdade é opcional. No entanto, minhas tentativas ip route addsempre acabam com uma interface de rede de saída adicionada automaticamente pelo kernel ou uma interface inacessível:

ip route add 1.1.1.1/32 via 1.1.1.2dá RTNETLINK answers: Network is unreachable.

Próxima tentativa (falhou):

ip addr add 1.1.1.2/32 dev ens33
ip route add 1.1.1.1/32 via 1.1.1.2
ip route show

... então dá 1.1.1.1 via 1.1.1.2 dev ens33, onde o kernel inseriu automaticamente uma interface de rede de saída adequada (e, portanto, RTA_OIFestá presente, mesmo que eu não a especifique no início).

Pesquisar coisas como "rota ip linux sem interface de saída" ou similar não me dá resultados utilizáveis ​​- a menos que eu esteja ignorando algo importante aqui.

Então, como posso criar um caso (de teste) em que tenho uma rota IP sem uma interface de rede de saída? O que estou negligenciando aqui?

A página de manual do Linux para namespaces de rede(7) diz:

Os namespaces de rede fornecem isolamento dos recursos do sistema associados à rede: [...], o diretório /sys/class/net, [...].

No entanto, simplesmente mudar para um namespace de rede diferente não parece alterar o conteúdo de /sys/class/net(veja abaixo como reproduzir). Estou apenas enganado aqui ao pensar que o namespace setns()da rede já é suficiente? É sempre necessário remontar /syspara obter a /sys/class/netcorrespondência correta do namespace de rede atualmente associado? Ou estou perdendo alguma coisa aqui?

Exemplo para reproduzir

Pegue um sistema *ubuntu, encontre o PID do rtkit-daemon, insira o namespace de rede do daemon, mostre suas interfaces de rede e verifique /sys/class/net:

$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# ip link show
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
# ls /sys/class/net
docker0  enp3s0  lo  lxcbr0  ...

Observe que, embora ip link showcorretamente mostre apenas lo, /sys/class/netmostra todas as interfaces de rede visíveis no namespace de rede "raiz" (e no namespace de montagem "raiz").

No caso de rtkit-daemontambém entrar no namespace mount dele não faz diferença: sudo nsenter -t $PID -n -me depois ls /sys/class/netainda mostra as interfaces de rede não presentes no namespace da rede.

"Fixar"

Muitos elogios para @Danila Kiver por explicar o que realmente está acontecendo nos bastidores do kernel Linux. A remontagem sysfs enquanto o namespace de rede correto é associado mostrará as entradas corretas/sys/class/net em :

$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# MNT=`mktemp -d`
# mount -t sysfs none $MNT
# ls $MNT/class/net/
lo
# umount $MNT
# rmdir $MNT
# exit

Portanto, isso agora produz os resultados corretos em /sys/class/net.

Gostaria de detectar se uma interface de rede é "física" ou "virtual", onde "física" significa que a interface possui hardware conectado, mesmo que esse "hardware" seja virtualizado por um hipervisor. "Virtual" significa então que é um dos elementos do kernel do Linux, como bridges, veths, macvlans, etc.

Estou ciente de que usando /sys/class/net/[nif]/...posso seguir o link do dispositivo e, assim, diferenciar entre interfaces de rede virtual (virtuais) físicas e "reais" (sic!), com base no caminho do dispositivo que contém o subdiretório "virtual" ou não. No entanto, ao lidar com namespaces de rede, isso requer uma remontagem adequada sysfspara poder ver as /sys/class/net/...entradas corretas. Portanto, um método mais simples baseado apenas em dados RTNETLINK pode ser mais adequado.

Ao usar o RTNETLINK para descobrir as interfaces de rede disponíveis, existe alguma propriedade/atributo que me permite diferenciar sem a necessidade de verificar /sys/class/net/[nif]?

Qual é o intervalo permitido de caracteres em nomes de interfaces de rede Linux? Pesquisei mas não encontrei nenhuma definição ou esclarecimento. Caracteres maiúsculos são permitidos? As letras maiúsculas e minúsculas são diferentes?

Em um programa, estou enumerando namespaces de rede procurando /proc/pid/por ns/netlinks (sym). Este programa é executado dentro dos namespaces "raiz" (inicialização original) do próprio host. Normalmente, preciso executar a parte do scanner como root, caso contrário, terei apenas acesso limitado às /proc/pid/informações de outros processos. Gostaria de evitar executar o scanner como root, se possível, e gostaria de evitar o incômodo de perder privilégios.

Qual recurso do Linux preciso definir para meu programa de scanner para que ele possa ser executado por usuários não raiz e ainda ver a /proc/pid/árvore completa e ler os links de namespace da rede?

É possível identificar inequivocamente que uma determinada interface de rede, como eth1, é na verdade uma vethinterface de rede do tipo? Observe que em contêineres, seus nomes de interface de rede geralmente começam com eth*em vez de veth*e não se pode ter certeza de que não há um real ethno conjunto. Isso pode ser detectado através de /sys/class/net?

Tenho a impressão de que o iflinkelemento in /sys/class/net/...não identifica de forma inequívoca vethas interfaces de rede, mas também é usado em outras situações. Se não houver como resolver minha dúvida usando o /sys/class/net/...sistema de arquivos, existe uma chamada de soquete que possa me fornecer essa informação, preferencialmente utilizável em Python?

Tarefa

Eu preciso de forma inequívoca e sem suposições "holísticas" encontrar a interface de rede peer de um veth final em outro namespace de rede.

Teoria ./. Realidade

Embora muita documentação e também respostas aqui no SO assumam que os índices ifindex de interfaces de rede são globalmente exclusivos por host em namespaces de rede, isso não ocorre em muitos casos : ifindex/iflink são ambíguos . Até o loopback já mostra o contrário, tendo um ifindex de 1 em qualquer namespace de rede. Além disso, dependendo do ambiente do contêiner, os ifindexnúmeros são reutilizados em diferentes namespaces . O que torna o rastreamento da fiação veth um pesadelo, especialmente com muitos contêineres e uma ponte de host com veth peers, todos terminando em @if3 ou algo assim ...

Exemplo: link-netnsidé0

Gire uma instância de contêiner do Docker, apenas para obter um novo vethpar conectando-se do namespace da rede do host ao novo namespace da rede do contêiner...

$ sudo docker run -it debian /bin/bash

Agora, no namespace da rede do host, liste as interfaces de rede (deixei de fora as interfaces que não interessam a esta pergunta):

$ show de link ip
1: lo: mtu 65536 qdisc noqueue estado DESCONHECIDO modo DEFAULT padrão do grupo qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
...
4: docker0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/éter 02:42:34:23:81:f0 brd ff:ff:ff:ff:ff:ff
...
16: vethfc8d91e@if15: mtu 1500 qdisc noqueue master docker0 estado UP mode DEFAULT group default
    link/éter da:4c:f7:50:09:e2 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Como você pode ver, embora o iflinkseja inequívoco, mas o link-netnsidé 0, apesar da extremidade do par estar em um namespace de rede diferente.

Para referência, verifique o netnsid no namespace de rede sem nome do contêiner:

$ sudo lsns -t rede
        NS TIPO NPROCS PID COMANDO DO USUÁRIO
...
...
4026532469 net 1 29616 root /bin/bash

$ sudo nsenter -t 29616 -n show de link ip
1: lo: mtu 65536 qdisc noqueue estado DESCONHECIDO modo DEFAULT padrão do grupo qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
15: eth0@if16: 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

Portanto, para ambas as extremidades veth ip link show(e RTNETLINK fwif) nos diz que eles estão no mesmo namespace de rede com netnsid 0. O que está errado ou correto sob as suposições de que os netnsids de link são locais em oposição a globais. Não consegui encontrar nenhuma documentação que tornasse explícito qual escopo o link-netnsids deveria ter.

/sys/class/net/...NÃO para o resgate?

Procurei em /sys/class/net/ if /... mas só consigo encontrar os elementos ifindex e iflink; estes estão bem documentados. "ip link show" também parece mostrar apenas o par ifindex na forma da (in)famosa notação "@if#". Ou eu perdi algum elemento de namespace de rede adicional?

Conclusão/Pergunta

Existem syscalls que permitem recuperar as informações de namespace de rede ausentes para o ponto final de um par veth?