Perguntas[iptables](unix)

Redirecionei com sucesso as solicitações de entrada da porta 53 para 3053 usando a tabela PREROUTING do iptables

Redirecionei com sucesso as solicitações locais da porta 53 para 3053 usando a tabela OUTPUT do iptables, desde que usem a interface de loopback

Mas as requisições locais que usam o endereço IPv4 eth0 ignoram ambos os redirecionamentos. Como resolver isso?

Eu tentei DNAT, especificando o IP de destino, a interface, nada funciona

sudo iptables-save
# Generated by iptables-save v1.8.9 (nf_tables) on Sun Feb 23 21:29:58 2025
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*nat
:PREROUTING ACCEPT [3765:300383]
:INPUT ACCEPT [3760:298404]
:OUTPUT ACCEPT [54136:75736197]
:POSTROUTING ACCEPT [54072:75544537]
-A PREROUTING -p udp -m udp --dport 53 -j REDIRECT --to-ports 3053
-A OUTPUT -o lo -p udp -m udp --dport 53 -j REDIRECT --to-ports 3053
COMMIT

Como reproduzir o erro com contêineres

FROM alpine:latest

RUN apk add --no-cache iptables netcat-openbsd socat

podman build -t udp-redirect .

podman run --rm -it --privileged --sysctl net.ipv4.conf.all.route_localnet=1  --name udp-redirect udp-redirect sh

socat -T 1 UDP-LISTEN:3053,fork EXEC:"echo -n 'Hello world'" &

iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 127.0.0.1:3053

echo -n "Test1" | nc -u -w1 10.0.2.100 53

Tenho usado o iptables-savecomando recentemente (combinado com iptables-restore) e notei um comportamento inconsistente que não entendo. Tenho certeza de que não é um bug, pois é um comando muito popular para ter passado despercebido, o que significa que é meu próprio entendimento que está falho. Dei uma olhada nas páginas de manual e em várias fontes de documentação, mas não consegui encontrar nada que explicasse o que observei.

O problema é que quando executo o comando iptables-save, espero ver a filtertabela despejada no stdout (conforme a documentação). O que vejo de fato é absolutamente nada, por exemplo:

[root@rhel9 ~]# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
[root@rhel9 ~]# 
...
[root@rhel9 ~]# iptables-save
[root@rhel9 ~]# 

Como você pode ver, não há saída para nada stdoutdo comando. Da mesma forma, se eu executar o comando e tentar redirecionar a saída ou passar a -f <output file>opção, a saída ainda estará em branco.

Se eu especificar a tabela que desejo visualizar, obtenho uma saída, por exemplo:

[root@rhel9 ~]# iptables-save -t filter
# Generated by iptables-save v1.8.8 (nf_tables) on Wed Jan  8 16:43:11 2025
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Wed Jan  8 16:43:11 2025

Se eu salvar essa saída em um arquivo, digamos ipv4backup, e então chamar iptables-restoreesse arquivo, o comportamento iptables-saveserá diferente:

[root@rhel9 ~]# iptables-restore ipv4backup
[root@rhel9 ~]# 
[root@rhel9 ~]# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
[root@rhel9 ~]# 
[root@rhel9 ~]# iptables-save
# Generated by iptables-save v1.8.8 (nf_tables) on Wed Jan  8 16:44:03 2025
*filter
:INPUT ACCEPT [5:305]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5:914]
COMMIT
# Completed on Wed Jan  8 16:44:03 2025

As tabelas contêm o mesmo conteúdo do exemplo acima, mas há um comportamento diferente dependendo iptables-savese iptables-restorefoi chamado anteriormente.

Testei isso no RHEL9 e no Ubuntu 22.04 e ambos apresentam o mesmo comportamento. No SuSE 15, o comando foi executado e produziu saída de todas as tabelas, independentemente de iptables-restoreterem sido executadas anteriormente. Os ip6tables...comandos equivalentes apresentam o mesmo comportamento.

Então, a questão é (com base no comportamento observado acima): por que iptables-savenão produz saída quando as tabelas estão vazias, mas se restaurarmos tabelas vazias e chamarmos o comando novamente, obtemos a saída esperada (que são tabelas vazias)?

Eu tenho um contêiner Docker em execução em uma configuração vanilla que escuta na porta 9999:

docker run --rm -it -p 9999:9999 busybox nc -vvl -p 9999 0.0.0.0

Adicionei uma regra LOG à tabela POSTROUTING no NAT para capturar os pacotes do servidor. No entanto, quando me conecto de uma máquina externa a este contêiner, não vejo nada no log do sistema.

No entanto, posso ver pacotes de conexão ao fazer login no final da cadeia POSTROUTING do mangle. De acordo com o The Diagram(TM) , NAT-POSTROUTING deve ser a próxima cadeia a viajar.

Esta é a tabela NAT:

# iptables -nL -tnat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER     0    --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER     0    --  0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
LOG        0    --  172.16.0.0/12        0.0.0.0/0            LOG flags 0 level 4 prefix "Packet:"
MASQUERADE  0    --  172.17.0.0/16        0.0.0.0/0           
MASQUERADE  6    --  172.17.0.2           172.17.0.2           tcp dpt:9999

Chain DOCKER (2 references)
target     prot opt source               destination         
RETURN     0    --  0.0.0.0/0            0.0.0.0/0           
DNAT       6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:9999 to:172.17.0.2:9999

Assistir journalctl -f | grep Packet:não mostra nada. TRACE indica que a tabela NAT foi totalmente ignorada, ou seja, todas as cadeias são ignoradas para pacotes de saída do servidor.

Isto está definido:

net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1

Por que isso acontece neste caso? Ou, de maneira mais geral, por que alguns pacotes simplesmente ignoram completamente a tabela NAT?

Eu tenho uma máquina Ubuntu no IP 192.168.3.1, outra máquina está conectada a ela no IP fixo de 192.168.3.2. Esta máquina também está conectada a um roteador via usb0 que compartilhou o IP 172.30.220.17 com a máquina

O que eu quero fazer é encaminhar qualquer pacote TCP ou UDP recebido por esta máquina através do IP 192.168.3.1 para 172.30.220.19 do roteador e vice-versa

Por exemplo, se a máquina em 192.168.3.2 enviar um pacote TCP "Hello" na porta 33000 para o computador principal, ela deverá enviar o pacote para 172.30.220.19:33000

Depois de ler a documentação do iptables e algumas perguntas anteriores, tentei os comandos abaixo para NAT, mas não funciona, não sei por quê. Eu ficaria feliz se alguém pudesse me orientar sobre o que fiz de errado. Obrigado pelo seu tempo

sudo iptables -t nat -A PREROUTING -p tcp -j DNAT --to-destination 172.30.220.19
sudo iptables -t nat -A POSTROUTING -p tcp -d 172.30.220.19  -j SNAT --to-source 192.168.3.2

Não está claro para mim se a verificação de INVÁLIDO vs ESTABLISHED, RELATED é igualmente rápida para ambos os casos (e se os estados são completamente ortogonais). Devo descartar INVÁLIDO antes de aceitar ESTABLISHED ou posso aceitar com segurança ESTABLISHED e depois descartar INVÁLIDO?

Eu configurei o iptables para registrar o tráfego de saída de todos, exceto um conjunto limitado de usuários, e estou tentando entender as mensagens de log que isso produz. Olhando para/var/log/syslog, vejo solicitações de 127.0.0.1 a 127.0.0.53 (pesquisas de DNS?) E algumas para 224.0.0.22 que se parecem com isto:

IN= OUT=wlp2s0 SRC=10.100.102.200 DST=224.0.0.22 LEN=40 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 MARK=0x94

que é um endereço multicast... alguma idéia do que estaria causando isso?

Finalmente, tenho vários parecidos com este, que parecem ser solicitações ICMP enviadas para vários lugares ao redor do mundo:

IN= OUT=wlp2s0 SRC=10.100.102.200 DST=151.80.9.69 LEN=138 TOS=0x08 PREC=0xC0 TTL=64 ID=26846 PROTO=ICMP TYPE=3 CODE=3 [SRC=151.80.9.69 DST=10.100.102.200 LEN=110 TOS=0x08 PREC=0x40 TTL=51 ID=48812 DF PROTO=UDP SPT=27209 DPT=8083 LEN=90 ]

Mas o que realmente me intriga é a parte entre colchetes ( SRC=151.80.9.69 PROTO=UDP SPT=27209 DPT=8083). Significa que o pacote ICMP é uma resposta a uma solicitação UDP para a porta 8083? Devo me preocupar com a possibilidade de uma possível intrusão (ou tentativa de intrusão)? E se sim, há algum motivo pelo qual eu não deva bloquear todo o tráfego UDP de entrada? (Eu só tenho servidores web escutando nas portas 80 e 443, e nenhuma outra porta está aberta - eu verifiquei e verifiquei novamente isso.)

Grato por qualquer ajuda para entender o que estou vendo aqui ...

Eu tenho uma configuração incomum no meu servidor. Temos três portas Ethernet de saída, todas conectadas a uma única interface de ponte que dividimos em duas VLANs:

ip link add veth type bridge
ip link set veth address 01:23:45:67:89:0A
ip link set dev eth1 master veth
ip link set dev eth2 master veth
ip link set dev eth3 master veth
[...]
ip link add veth name veth.10 type vlan id 10
ip link add veth name veth.20 type vlan id 20
ip link add veth.20-local link veth.20 type macvlan mode bridge
[...]
docker network create --driver=macvlan --subnet=192.168.XXX.0/24 --opt com.docker.network.driver.mpu=1500 --gateway 192.168.XXX.1 --opt parent=veth.20-local dockerbr20

Eu tenho uma imagem docker dentro do meu servidor conectada ao veth.20endereço, que só tem permissão para se comunicar por veth.20. Existem regras de roteamento e encaminhamento no restante da rede que permitem que a imagem do Docker se comunique com alguns destinos selecionados fora dessa VLAN.

Gostaria de adicionar uma iptablesregra cobrindo pacotes de saída que deixam meu servidor fora da veth.20interface, independentemente do seu destino. (Alguns pacotes devem permanecer dentro da veth.20interface; alguns podem ser roteados para outras VLANs.)

As seguintes regras foram tentadas e, por qualquer motivo, não parecem marcar os pacotes que saem veth.20do contêiner do docker:

iptables -A POSTROUTING -t mangle -o veth.20 -j MARK --set-mark 3
iptables -A PREROUTING -t mangle -i veth.20 -j MARK --set-mark 3
iptables -A POSTROUTING -t nat -o veth.20 -j MARK --set-mark 3
iptables -A PREROUTING -t nat -i veth.20 -j MARK --set-mark 3
iptables -A OUTPUT -t mangle -o veth.20 -j MARK --set-mark 3
iptables -A INPUT -t mangle -i veth.20 -j MARK --set-mark 3
iptables -A FORWARD -i veth.20 -j MARK --set-mark 3
iptables -A FORWARD -o veth.20 -j MARK --set-mark 3

Isto é, iptables -L -n -v -t manglee iptables -L -n -v -t natnão mostra nenhuma dessas regras sendo aplicadas a pacotes de saída veth.20para um host em outra VLAN.

Confirmei, por meio de ifconfig, que todos os pacotes da imagem do docker estão saindo do servidor veth.20; o

iptables -A OUTPUT -t mangle -o veth.20 -j MARK --set-mark 3

a regra se aplica quando envio pacotes para máquinas externas na VLAN 20, do servidor ou da imagem do docker; mas quando envio pacotes pela veth.20interface do docker que são roteados para um endereço VLAN 10 ou VLAN 30 externo (não ilustrado), nenhuma marca é aplicada.

Acho que esse deveria ser um problema simples, mas nada do que tentei foi capaz de marcar com base na interface que o pacote usa para sair da caixa. o que estou perdendo?

Filtrarei o tráfego de entrada com iptables.

Eu tenho 2 objetivos.

a) Allow HTTPS inbound at port 443.

b) Redirect port 443 to process listening port on 9443.

Não tenho certeza sobre o processamento dessas 2 regras.

Preciso definir minha regra INPUT para ACCEPT HTTPS de entrada para a porta 443 ou 9443?7

Depende se o redirecionamento for feito antes ou depois, eu acho.

Estou tentando executar o docker dentro do Ubuntu 22.04.3 LTS rodando em WSL-2 em minha máquina Windows 10.

Eu segui as instruções aqui . Mas ainda não está funcionando, estou recebendo o seguinte erro quando executo sudo dockerd:

failed to register "bridge" driver: failed to create NAT chain DOCKER:
       iptables failed: iptables -t nat -N DOCKER:
       iptables v1.8.7 (legacy): can't initialize iptables table `nat':
          Table does not exist (do you need to insmod?)
          Perhaps iptables or your kernel needs to be upgraded.
  (exit status 3)

Quando faço isso, modprobe ip_tablesrecebo:

modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.4.0-22621-Microsoft

Eu tenho um roteador Linux simples com vários NICs e encaminhamento IPv4 habilitado.

O roteador possui dois endereços IP WAN estáticos, atribuídos a uma interface ( eth0, eth0:0). (No texto a seguir, ofuscarei os endereços IP públicos reais (257 como um octeto).)

O roteador pode receber ping em ambos os endereços IP WAN externos da Internet externa.

Interfaces:

• eth0: Conexão com a Internet, 134.257.10. 24/10 , gateway 134.257.10.1
• eth0:0: Segundo endereço IP nessa interface: 134.257.10. 20/24 _
• eth1: LAN 1, 192.168.1.1/24
• eth2: LAN2, 192.168.2.1/24
• eth3: LAN 3, 192.168.3.1/24

Minha configuração funciona e todos os clientes LAN (LAN 1-3) podem acessar a Internet e são vistos externamente como 134.257.10. 10 . Além disso, tenho dois encaminhamentos de porta de entrada.

Minha tabela NAT do iptables é assim:

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# Port forwarding:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80
-A PREROUTING -i eth0:0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 192.168.3.33:25
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

Como posso fazer com que os clientes LAN3 ( eth3) apareçam como 134.257.10. 20 na Internet ( eth0:0) para conexões de saída em vez de 134.257.10. 10 ( eth0)?