Perguntas[iptables](unix)

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)?

Eu executo um servidor com um servidor web rodando como um contêiner podman sem root. Isso expõe as portas 10080 e 10443 porque, como um contêiner sem raiz, não é permitido expor as portas 80 e 443.

Para que meu site possa ser acessado de fora, eu uso o ufw como firewall e configurei o encaminhamento de porta lá. Para fazer isso, adicionei as seguintes linhas ao início do /etc/ufw/before.rulesarquivo:

*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 10080
-A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 10443
COMMIT

Até agora tudo funciona.

Agora quero executar outro contêiner que execute um servidor Wireguard. Isso gera o seguinte em seu log e parece definir isso como regras no firewall:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.13.13.1 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 10.13.13.2/32 dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth+ -j MASQUERADE

Se eu executar o contêiner Wireguard sem o firewall ufw ativado - especialmente sem o encaminhamento de porta definido - tudo funcionará. Posso me conectar a um cliente e seu tráfego é roteado pelo túnel e chega à Internet.

Se, por outro lado, eu ativar o firewall ufw incluindo o encaminhamento de porta definido e depois conectar-me à VPN Wireguard com um cliente, todas as visualizações de página parecerão chegar ao meu próprio servidor - pelo menos recebo mensagens de erro como esta:

This server could not prove that it is www.google.de. Its security certificate comes from <myServer>.de

Como posso configurar o firewall ufw para que

1. Solicitações externas para a porta 80 ou 443 são encaminhadas para as portas 10080 ou 10443 e assim chegam ao meu servidor web
2. As solicitações do meu cliente VPN chegam à Internet através do túnel WireGuard e não do meu próprio servidor?

(Em outro servidor eu executo o WebServer e o WireGuard no docker - tudo funciona porque o Docker WebServer expõe diretamente as portas 80 e 443 e, portanto, não preciso de nenhum encaminhamento de porta.)

Muito obrigado pela sua ajuda.

Estou tentando entender claramente o que exatamente o br_netfiltermódulo do kernel Linux faz (sei que tem algo a ver com rede).

Minha pergunta simples que estou fazendo aqui é a seguinte:

Qual é um exemplo de algo que POSSO fazer com este módulo habilitado e que NÃO POSSO fazer quando ele está desabilitado? Achei que tinha algo a ver iptables, mas ao desabilitar/habilitar o módulo sempre consegui executar os mesmos iptablescomandos.

Nota: como eu não tinha certeza de que não mataria meu computador desabilitando um módulo do kernel, criei uma instância de teste do AWS EC2 para testar isso.

EDIT: Para esclarecer, o que eu gostaria de ver é um conjunto simples de etapas, também conhecido como executar comandos X, Y, Z, que quando habilitado, o sistema age conforme o esperado, quando desabilitado, não.