Estou tentando entender como o systemd-nspawn gerencia o acesso à internet e o encaminhamento de portas para contêineres.

Configurei um contêiner nspawn com --network-vethe um encaminhamento de porta com --port=80. Tanto o host quanto o contêiner executam systemd-networkd. Tudo funciona perfeitamente: o contêiner consegue acessar a internet e o tráfego de entrada na porta 80 é encaminhado para o contêiner.

Gostaria de entender e inspecionar como o systemd gerencia isso. Eu esperava (ingenuamente?) encontrar regras relacionadas no iptables, mas se eu executar, iptables -t ... -Stodas as tabelas parecem vazias, tanto no host quanto no contêiner. Também executei o mesmo comando nsenterpara entrar no namespace de rede do veth, mas ainda não vejo regras.

Então, o systemd não usa o Netfilter para NAT/Masquerading? Se não, o que ele usa?

Estou vendo várias das duas linhas a seguir nos meus logs do dmesg¹:

[602956.308844] [iptables] (10): IN=eno1 OUT=eno2 MAC=xx:yy:..:zz SRC=10.174.26.245 DST=192.168.22.59 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53 DPT=47150 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
[602956.652575] [iptables] (10): IN=eno1 OUT=eno2 MAC=xx:yy:..:zz SRC=10.172.0.22 DST=192.168.22.59 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53 DPT=44204 WINDOW=28960 RES=0x00 ACK SYN URGP=0 

Meu firewall os bloqueia porque não reconhece os endereços IP 10.172.0.22 e 10.174.26.245.

Na verdade, olhando as listas de endereços IP eno1 e eno2, esses dois não estão incluídos. Eu tenho dois 10.xxx que uso, mas não os dois listados acima (daí o firewall bloqueando esses dois).

Minha rede se parece com isso:

+----------+     +--------+     +--------+     +--------+
| Internet |<--->| Router |<--->| Server |<--->| Laptop |
+----------+     +--------+     +--------+     +--------+

Tanto o servidor quanto o laptop possuem firewalls. O laptop está conectado em 192.168.22.59. Nenhum desses pacotes UDP TCP é enviado a ele.

O eno1 e o eno2 estão no servidor. O eno1 se conecta ao roteador, que se conecta à internet. A conexão do roteador usa endereços de rede local (IPv4 e IPv6). O eno2 é minha rede local (LAN). O servidor está configurado para ENCAMINHAR tráfego entre o laptop e a internet.

O laptop usa uma VPN e suspeito que possa vir dela, mas o laptop também tem um firewall e, portanto, ignoraria esse tráfego. O que me pergunto é de onde esses pacotes estão vindo? Seria de um sistema local ou de algum hacker? Ou a VPN poderia ser a culpada? De qualquer forma, não entendo como um pacote UDP TCP pode estar usando um endereço IP que não está presente em uma interface de rede e, se for local, não vejo como poderia vir de fora. Existe uma maneira de descobrir quem envia esses pacotes, supondo que seja um processo local?

Observação: Tenho o libvirt instalado, mas tentei interromper a VPN que estou usando e não adiantou. Além disso, as duas pontes que ele cria não usam os endereços IP 10.17[24].xx. Além disso, não consigo imaginar nenhum motivo para a VPN enviar pacotes UDP TCP para a máquina errada.

Atualizar

Então, fui até meu laptop e reconectei a VPN. Depois disso, as duas linhas acima pararam de aparecer.

Isso me permitiu ver outra linha:

[608974.298853] [iptables] (192): IN=eno1np0 OUT=eno2np1 MAC=xx:yy:...:zz SRC=192.168.19.2 DST=192.168.22.189 LEN=151 TOS=0x00 PREC=0x00 TTL=63 ID=8281 DF PROTO=UDP SPT=53 DPT=47512 LEN=131 

Este é UDP, mas a questão é que, assim como no laptop, ele precisa de dados do que parece ser um IP local que vem do roteador (portanto, da internet). O dispositivo 189 é minha impressora HP, então talvez ela também tenha um sistema semelhante a uma VPN e falhe em solicitações de DNS de vez em quando dessa maneira.

Resolução

Na verdade, eu consegui ver esses dois IPs na tabela de rotas, o que você pode fazer assim:

$ ip route

Isso significa que meu gráfico seria mais ou menos assim:

+----------+     +-----+     +--------+     +--------+     +--------+
| Internet |<--->| VPN |<--->| Router |<--->| Server |<--->| Laptop |
+----------+     +-----+     +--------+     +--------+     +--------+

Claro, como mencionado pela telcoM, também há o ISP entre o roteador e a VPN, mas ele não é o culpado. Agora, eu DESCARTO esses pacotes sem registrá-los primeiro:

-A bad_tcp_packets -i eno1 -s 10.172.0.0/16 -j DROP
-A bad_tcp_packets -i eno1 -s 10.174.0.0/16 -j DROP

Um ponto a ser observado: isso significa que usar uma VPN pode abrir um conjunto de IPs locais do outro lado. Portanto, você precisa ficar atento a isso, pois isso pode afetar a configuração da sua LAN.

¹ Configurei meu firewall para registrar esses acessos para garantir que eu possa ver esses problemas. No momento, não estou tentando evitar o registro, mas sim entendê-lo.

Um servidor NCP (nextcloudpi) está estacionado em myfqdn.duckdns.org

O Safari retorna:

O Chrome retorna:

Um navegador Safari privado retorna a página da Web NCP esperada.

Procuro um procedimento de solução de problemas para diagnosticar o problema: Gostaria de saber se há um problema de certificado.

Vi outras respostas neste site, li um artigo e assisti a um vídeo sobre o assunto, mas ainda não consigo conectar meu namespace de rede ao mundo externo.

Configurar

Criei um namespace chamado "foo" e um par de vethinterfaces e movi uma para o namespace.

ip netns add foo
ip link add veth-foo type veth peer name veth-out
ip link set dev veth-foo netns foo

Atribuí um endereço IP a cada interface e verifiquei se ambas estavam ativas.

ip -n foo addr add 192.168.15.1 dev veth-foo
ip addr add 192.168.15.2 dev veth-out
ip -n foo link set dev veth-foo up
ip link set dev veth-out up

# Just in case, I made sure the loopback interfaces, too, are up, though they still show "UNKNOWN".
ip link set dev lo up
ip -n foo link set dev lo up 

Adicionei entradas às tabelas de roteamento dos namespaces global e "foo", para que eles possam se comunicar entre si.

ip route add 192.168.15.1 via 192.168.15.2
ip -n foo route add default via 192.168.15.1

Agora, posso alcançar "foo" do namespace global e o namespace global de "foo".

$ traceroute -n 192.168.15.1
traceroute to 192.168.15.1 (192.168.15.1), 30 hops max, 60 byte packets
 1  192.168.15.1  0.257 ms  0.209 ms  0.194 ms

$ ip netns exec foo traceroute -n 192.168.15.2
traceroute to 192.168.15.2 (192.168.15.2), 30 hops max, 60 byte packets
 1  192.168.15.2  0.046 ms  0.009 ms  0.008 ms

Também posso acessar a interface Ethernet que conecta a VM ao mundo externo de dentro de "foo".

# I ran this after I finished setting up IP forwarding, packet forwarding,
# and IP masquerading, so I'm not sure if it would work at this stage.
$ ip netns exec foo traceroute -n 10.0.2.15
traceroute to 10.0.2.15 (10.0.2.15), 30 hops max, 60 byte packets
 1  10.0.2.15  0.065 ms  0.010 ms  0.008 ms

Por fim, configurei o encaminhamento de IP, o encaminhamento de pacotes e o mascaramento de IP.

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -o enp1s0 -i veth-out -j ACCEPT
iptables -A FORWARD -i enp1s0 -o veth-out -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.15.1/24 -o enp1s0 -j MASQUERADE

Como resultado, meu sistema fica assim:

$ sysctl -a | grep ip_forward
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0

$ iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 102 packets, 6816 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  any    enp1s0  192.168.15.0/24      anywhere

$ 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 noprefixroute 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:c3:cd:ac brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute enp1s0
       valid_lft 83383sec preferred_lft 83383sec
    inet6 fec0::11b8:4b3b:59ba:bae4/64 scope site dynamic noprefixroute 
       valid_lft 86026sec preferred_lft 14026sec
    inet6 fe80::f3fd:90f2:d15f:d570/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: veth-out@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether da:a2:13:05:c4:f5 brd ff:ff:ff:ff:ff:ff link-netns foo
    inet 192.168.15.2/32 scope global veth-out
       valid_lft forever preferred_lft forever
    inet6 fe80::d8a2:13ff:fe05:c4f5/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

$ ip -n foo 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 proto kernel_lo 
       valid_lft forever preferred_lft forever
4: veth-foo@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 7e:84:e6:16:92:8e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.15.1/32 scope global veth-foo
       valid_lft forever preferred_lft forever
    inet6 fe80::7c84:e6ff:fe16:928e/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

$ ip route
default via 10.0.2.2 dev enp1s0 proto dhcp src 10.0.2.15 metric 100 
10.0.2.0/24 dev enp1s0 proto kernel scope link src 10.0.2.15 metric 100 
192.168.15.1 via 192.168.15.2 dev veth-out

$ ip -n foo route
default via 192.168.15.1 dev veth-foo

Testando

Neste ponto, espero conseguir alcançar o mundo exterior, mas não.

$ ip netns exec foo traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.15.1  3067.680 ms !H  3067.655 ms !H  3067.650 ms !H

$ sudo ip netns exec foo ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.15.1 icmp_seq=1 Destination Host Unreachable
From 192.168.15.1 icmp_seq=2 Destination Host Unreachable
From 192.168.15.1 icmp_seq=3 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2077ms

É claro que a própria VM está conectada à Internet.

$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.0.2.2  0.719 ms  0.691 ms  0.676 ms
 2  192.168.100.1  1.913 ms  2.593 ms  5.264 ms
 3  31.146.255.37  18.493 ms  18.740 ms  19.041 ms
 4  188.123.128.85  19.384 ms  19.658 ms  19.925 ms
 5  188.123.128.96  20.275 ms  21.787 ms 188.123.128.84  21.773 ms
 6  192.178.69.213  47.953 ms  53.145 ms  53.127 ms
 7  192.178.69.212  53.116 ms  51.893 ms 188.123.128.33  51.293 ms
 8  192.178.107.87  48.513 ms 192.178.107.135  43.582 ms 192.178.107.203  43.391 ms
 9  72.14.237.137  43.195 ms 8.8.8.8  43.207 ms  43.200 ms

$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=40.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=37.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=255 time=38.0 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 37.859/38.698/40.205/1.067 ms

Tcpdump

Aqui está a saída de tcpdump -n -i veth-out icmp. Ele capturou pacotes quando eu mirei 192.168.15.2& 10.0.2.15, mas não obteve nada quando eu mirei 8.8.8.8.

listening on veth-out, link-type EN10MB (Ethernet), snapshot length 262144 bytes

# This is the output when I ran `traceroute -n 192.168.15.2` (the address
# of "veth-out") in another terminal window (from inside "foo", of course).
12:44:19.172007 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port traceroute unreachable, length 68
12:44:19.172029 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port mtrace unreachable, length 68
12:44:19.172046 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33436 unreachable, length 68
12:44:19.172063 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33437 unreachable, length 68
12:44:19.172102 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33438 unreachable, length 68
12:44:19.172119 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33439 unreachable, length 68

# And this is when I ran the same command but addressed 10.0.2.15 (the
# ethernet interface to the outside world).
12:44:35.305689 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port traceroute unreachable, length 68
12:44:35.305715 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port mtrace unreachable, length 68
12:44:35.305733 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33436 unreachable, length 68
12:44:35.305750 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33437 unreachable, length 68
12:44:35.305766 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33438 unreachable, length 68
12:44:35.305783 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33439 unreachable, length 68
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

Nem capturou tcpdump -n -i lo icmpnenhum tcpdump -n -i enp1s0 icmppacote, independentemente do alvo de traceroute—sim, mesmo quando "foo" alcançou com sucesso a interface "enp1s0" (endereçada 10.0.2.15).

Informações do sistema

Isso foi feito dentro de uma VM (GNOME Boxes), no Fedora 41, versão do kernel 6.11.4-301.fc41.x86_64.

Minha máquina host também está executando o Fedora 41, embora o kernel esteja na versão 6.13.5-200.fc41.x86_64.

Edição: Só para garantir que isso fosse um problema do Fedora, testei em uma VM Mint e aconteceu exatamente a mesma coisa.

Estou tentando aprender a trabalhar com iptables. Tentei parar todo o tráfego por http e https.

Minhas cadeias de ENTRADA e SAÍDA estavam vazias.

Inicialmente fiz o seguinte:

sudo iptables -A OUTPUT -p tcp --dport 80 -j DROP
sudo iptables -A OUTPUT -p tcp --dport 443 -j DROP

No entanto, ainda consegui acessar novas páginas da web como https://systemd.io/ ou https://fr.euronews.com/ , mas não https://unix.stackexchange.com/

Como isso não era suficiente, decidi adicionar também regras semelhantes para a cadeia OUTPUT...

sudo iptables -A INPUT -p tcp --sport 80 -j DROP
sudo iptables -A INPUT -p tcp --sport 443 -j DROP

Eu ainda conseguia acessar esses sites... Não sei como isso era possível.

Na cadeia FORWARD, tenho 3 regras (repetidas muitas vezes),

ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere  

Não tenho certeza se eles influenciam as cadeias de ENTRADA ou SAÍDA...

Então, eu tenho um sistema embarcado que eu construí com yocto. Estou tentando habilitar DHCPv6. Mas quando eu tento colocar a interface online, ifup diz que não consegue encontrar o software DHCPv6, mesmo que dhcpcd esteja instalado. E dhcpcd funciona se eu executá-lo manualmente.

root@1234:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.5.80
        netmask 255.255.255.0
        gateway 192.168.5.1

iface eth1 inet6 dhcp

root@1234:~# ip a show dev eth1
8: eth1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
    link/ether ce:e6:83:59:f1:93 brd ff:ff:ff:ff:ff:ff
    inet 169.254.23.45/16 brd 169.254.255.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::468b:6249:e50b:a437/64 scope link
       valid_lft forever preferred_lft forever

root@1234:~# which dhcpcd
/sbin/dhcpcd

root@1234:~# ifup eth1
No DHCPv6 client software found!
ifup: failed to bring up eth1

root@1234:~#

Observe que eth1 é apenas uma interface fictícia por enquanto, para que eu não interrompa minha conexão SSH mexendo com eth0, que é onde realmente quero adicionar DHCPv6.

Meu laptop executando NixOs 24.11 com um adaptador Intel(R) Wi-Fi 6E AX211 160MHz não consegue se conectar à minha rede doméstica usando wifi (ethernet está funcionando). Em vez dos SSIDs corretos aparecerem (2.4G ou 5G), ele mostra apenas fhmesh_seguido pelo endereço mac hexadecimal do meu roteador. Quando tento me conectar a ele no meu gerenciador de janelas em mosaico, o networkManager mostra o erro 802-11-wireless-security.key-mgmt: 'wpa-psk' is not a valid value for 'mesh' mode connections. Quando tento me conectar a ele usando o KDE Plasma, ele mostra 802-11-wireless.mode: connection does not match access point. Estou me conectando a uma rede oculta com o nome e a senha do meu SSID correto, mas o networkManager não conseguiu encontrá-lo. Tentei instalar o iwlwifimódulo do kernel ( logs ), o iwpacote e pkgs.wireless-regdbem hardware.firmwaremas eles não corrigiram meu problema. Eu executei iw reg geto que mostrou que meu país regulatório era TH: DFS-UNSET. Tentei executar sudo iw reg setpara ambos CA(estou no Canadá) e US(a página de configurações de WLAN do meu roteador mostra seu país como UNITED STATESe não consigo alterá-lo). Nenhuma das opções pareceu funcionar. Tentei alternar para wpa-supplicantmas isso também não funcionou.

Informações extras:

• Esse problema parece afetar apenas meu dispositivo quando ele está sob internet fornecida pela CIK Telecom, pois não consegui me conectar ao wifi em outra casa sob o mesmo ISP. Posso me conectar ao wifi em locais não fornecidos por este ISP e o networkManager atualmente consegue detectar o wifi do meu vizinho.
• Esse problema não se manifesta quando eu faço dual-boot no Windows na mesma máquina (a reinicialização rápida já está desabilitada). Estou executando o Debian em outra máquina e ele está se conectando ao wifi perfeitamente. Ele está se conectando à rede com o SSID adequado, ao mesmo tempo em que me mostra a opção de conectar a fhmesh_. Quando tento conectar a fhmesh_, o mesmo wpa-pskerro aparece. iw reg getnesta máquina também retornaTH: DFS-UNSET
• Meu /etc/nixos está aqui
• Acabei de atualizar nixos-unstablee esse problema ainda persiste

Estou tentando definir um IP estático em um novo sistema operacional Raspbian Lite.

Eu costumava conseguir definir um endereço IP estático em sistemas Debian mais antigos modificando o /etc/network/interfacesarquivo, mas este sistema operacional não tem esse arquivo. quando adiciono o arquivo com o seguinte:

auto eth0
iface eth0 static
    address 192.168.1.15/24
    gateway 192.168.1.1

o iface é desconfigurado. Ele nem aceita o valor dhcp. O que estou perdendo/fazendo errado?

Tenho dois arquivos, eth0-statice eth0-dhcp, para meu NetworkManager definido e quero que o NetworkManager use um desses arquivos como padrão. A seleção de arquivo depende se o DHCP está habilitado ou não. Como posso dizer ao NetworkManager para usar um desses arquivos em vez de criar Wired connection 1? Ou faz mais sentido renomear os arquivos existentes?

Então, eu tenho uma rede docker chamada homeonde todos os meus contêineres baseados em raiz (ou contêineres docker que eram simplesmente muito difíceis de portar para o podman) ficam armazenados.

sudo docker network ls
NETWORK ID     NAME                 DRIVER    SCOPE
9d5788b45048   bridge               bridge    local
b1f4756feab4   home                 bridge    local
5d7ee6579f19   host                 host      local
8678a773e2f2   none                 null      local

E, para o podman, tenho uma configuração muito semelhante.

podman network ls
NETWORK ID    NAME        DRIVER
8b17ae3d5d67  home        bridge  
2f259bab93aa  podman      bridge

O problema? Bem, acontece que minha resolução de nomes para contêineres não funciona de uma rede para outra. Então, por exemplo, eu tenho o nginx-proxy-managerpodman em execução e quero redirecionar http://domain/freshrsspara o serviço freshrss especificando freshrsse o número da porta associado. Isso não funciona, e isso faz sentido para mim, pois a rede docker e a rede podman são fundamentalmente separadas uma da outra.

Então, minha pergunta é simples: Existe alguma maneira de tratar essas duas redes como uma rede unindo-as sem prejudicar a santidade das configurações de rede individualizadas ? Alternativamente, existe alguma maneira de contornar esse problema de comunicação sem ter que especificar novamente o nome de domínio no nome e na porta de encaminhamento? Por exemplo, pensei que encaminhar para 127.0.0.1:<freshrss port>funcionaria, pois iria para o host e, em seguida, conectaria à porta apropriada, mas isso não funcionou.

docker/podman composeRespostas personalizadas são bem-vindas, pois é assim que estou configurando meus serviços.