Início / server / 问题

Perguntas[iptables](server)

Martin Hope
Mohammadmahdi
Asked: 2025-04-19 15:32:22 +0800 CST
  • 5

Tenho um IPtables correspondente como -m policy --dir out --pol ipsec --mode tunnel --tunnel-src 1.1.1.2 --tunnel-dst 1.1.1.1. Sei que essa correspondência funciona com nftables em modo compatível como xt "policy", mas preciso usar a sintaxe nftables para isso, a fim de usar nfte fazer backup apenas a partir dele.

Ele também nftables v0.9.3 (Topsy)não suporta o modo de compatibilidade xt "policy". Eu também tentei, ipsec out ip saddr 1.1.1.2 ip daddr 1.1.1.1mas não pareceu funcionar nem com esta versão nem nftables v1.0.9 (Old Doc Yak #3)como esperado.

iptables
Martin Hope
Mohammadmahdi
Asked: 2025-04-16 22:43:21 +0800 CST
  • 6

Estou com um problema com dir out marka política do XFRM. Configurei mark_ino mark_outStrongSwan e estabeleci uma conexão IPsec. Também adicionei algumas regras simples do IPTables para marcar pacotes e verificar apenas se a correspondência funciona (é apenas para fins de teste, então permite tudo, exceto os pacotes relacionados ao IPsec que não correspondem) .

eth3 está conectado aos clientes deste lado do túnel

eth8 é usado para o túnel

Configuração do StrongSwan:

connections {
  tun_p1 {
    local_addrs=1.1.1.2
    remote_addrs=1.1.1.1
    send_cert=never
    unique=replace
    version=2
    mobike=no
    keyingtries=5
    dpd_delay=30
    dpd_timeout=90
    rekey_time=3600s
    over_time=120s
    rand_time=60
    children {
      tun_1 {
        local_ts=3.3.3.0/24
        remote_ts=2.2.2.0/24
        mode=tunnel
        ipcomp=no
        dpd_action=trap
        start_action=start
        close_action=none
        rekey_time=28800s

        # Marks are here
        mark_out=0x1000/0xff000
        mark_in=0x100000/0x100000
      }
    }
    local {
      auth=psk
      id=1.1.1.2
    }
    remote {
      auth=psk
      id=1.1.1.1
    }
  }
}

Política XFRM:

root@ubuntu-24:~# ip xfrm policy
src 3.3.3.0/24 dst 2.2.2.0/24
        dir out priority 375423
        mark 0x1000/0xff000
        tmpl src 1.1.1.2 dst 1.1.1.1
                proto esp spi 0xc862dc7c reqid 1 mode tunnel
src 2.2.2.0/24 dst 3.3.3.0/24
        dir fwd priority 375423
        mark 0x100000/0x100000
        tmpl src 1.1.1.1 dst 1.1.1.2
                proto esp reqid 1 mode tunnel
src 2.2.2.0/24 dst 3.3.3.0/24
        dir in priority 375423
        mark 0x100000/0x100000
        tmpl src 1.1.1.1 dst 1.1.1.2
                proto esp reqid 1 mode tunnel

Configuração do IPtables:

*raw
:PREROUTING ACCEPT
:OUTPUT ACCEPT

 -A PREROUTING -i eth3 -j TRACE

COMMIT

*mangle
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
:FORWARD ACCEPT
:IPsec -

 -A PREROUTING  -i eth8 -p esp -d 1.1.1.2 -s 1.1.1.1 -j MARK --set-mark 0x100000/0x100000

 -A FORWARD  -i eth3 -o eth8 -j MARK --set-mark 0x1000/0xff000

 -A POSTROUTING -j IPsec

 -A IPsec -m mark --mark 0x1000/0xff000 -m policy --dir out --pol ipsec --mode tunnel --tunnel-src 1.1.1.2 --tunnel-dst 1.1.1.1 -j RETURN
 -A IPsec -m mark --mark 0x1000/0xff000 -j DROP

COMMIT

*nat
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
:OUTPUT ACCEPT

COMMIT

*filter
:INPUT ACCEPT
:OUTPUT ACCEPT
:FORWARD ACCEPT
:PolicyFilterChain -

 -A FORWARD -j PolicyFilterChain

 -A PolicyFilterChain -m state --state NEW,ESTABLISHED,RELATED -m mark --mark 0x100000/0x100000  -m policy --dir in --pol ipsec --mode tunnel --tunnel-src 1.1.1.1 --tunnel-dst 1.1.1.2  -j ACCEPT

 -A INPUT -i eth8 -p udp --sport 500 --dport 500 -d 1.1.1.1 -s 1.1.1.2 -j ACCEPT
 -A INPUT -i eth8 -p esp -d 1.1.1.2 -s 1.1.1.1 -j ACCEPT

COMMIT

Quando envio pacotes do outro lado do túnel, tudo funciona bem e recebo a resposta. O problema está nos dir outpacotes deste lado do túnel. Sei que eles recebem a marca, pois são descartados pela regra após a verificação da política, mas não correspondem à política do XFRM e, mesmo que eu não os descarte, eles não são criptografados pelo XFRM.

Se eu comentar -A IPsec -m mark --mark 0x1000/0xff000 -j DROPa regra, o pacote é enviado para o outro lado sem criptografia, embora a marca esteja definida no pacote.

Rastreamento após queda de comentário :

TRACE: raw:PREROUTING:policy:2 IN=eth3 OUT= MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1
TRACE: mangle:PREROUTING:policy:2 IN=eth3 OUT= MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1
TRACE: nat:PREROUTING:policy:1 IN=eth3 OUT= MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1
TRACE: mangle:FORWARD:rule:1 IN=eth3 OUT=eth8 MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1
TRACE: mangle:FORWARD:policy:2 IN=eth3 OUT=eth8 MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1 MARK=0x1000
TRACE: filter:FORWARD:rule:1 IN=eth3 OUT=eth8 MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1 MARK=0x1000
TRACE: filter:PolicyFilterChain:return:3 IN=eth3 OUT=eth8 MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1 MARK=0x1000
TRACE: filter:FORWARD:policy:2 IN=eth3 OUT=eth8 MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1 MARK=0x1000
TRACE: mangle:POSTROUTING:rule:1 IN=eth3 OUT=eth8 MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1 MARK=0x1000
TRACE: mangle:IPsec:return:2 IN=eth3 OUT=eth8 MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1 MARK=0x1000
TRACE: mangle:POSTROUTING:policy:2 IN=eth3 OUT=eth8 MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1 MARK=0x1000
TRACE: nat:POSTROUTING:policy:1 IN=eth3 OUT=eth8 MAC=00:50:56:9f:3d:99:00:50:56:9f:c8:bc:08:00 SRC=3.3.3.3 DST=2.2.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=42626 DF PROTO=ICMP TYPE=8 CODE=0 ID=2584 SEQ=1 MARK=0x1000

Despejo TCP:

root@ubuntu-24:~# tcpdump -i eth8 proto 50 or host 3.3.3.3 -nn
17:58:41.992237 IP 3.3.3.3 > 2.2.2.2: ICMP echo request, id 2603, seq 1, length 64
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

O inverso está ok:

root@ubuntu-24:~# tcpdump -i eth8 proto 50 or host 3.3.3.3 -nn
18:00:04.880886 IP 1.1.1.1 > 1.1.1.2: ESP(spi=0xc98cba8d,seq=0x2), length 136
18:00:04.881265 IP 2.2.2.2 > 3.3.3.3: ICMP echo request, id 59100, seq 1, length 64
18:00:04.882554 IP 3.3.3.3 > 2.2.2.2: ICMP echo reply, id 59100, seq 1, length 64
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

Eu sei que o problema é com mark_out, porque se eu comentar, tudo funciona como esperado, mas preciso marcar.

iptables
Martin Hope
Bernd Storath
Asked: 2025-03-27 15:53:34 +0800 CST
  • 6

Estou executando o WireGuard em um contêiner Podman. Tenho uma configuração Hub and Spoke como esta

Client A <--> Hub <--> Client B
               |
               |
            Internet

Esta é minha configuração WireGuard no Hub atualmente

[Interface]
PrivateKey = ...
Address = 10.8.0.1/24, fdcc:ad94:bacf:61a4::cafe:1/112
ListenPort = 51820
MTU = 1420
PostUp = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE; iptables -A INPUT -p udp -m udp --dport 51820 -j ACCEPT; iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -s fdcc:ad94:bacf:61a4::cafe:0/112 -o eth0 -j MASQUERADE; ip6tables -A INPUT -p udp -m udp --dport 51820 -j ACCEPT; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -A FORWARD -o wg0 -j ACCEPT;
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE; iptables -D INPUT -p udp -m udp --dport 51820 -j ACCEPT; iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -s fdcc:ad94:bacf:61a4::cafe:0/112 -o eth0 -j MASQUERADE; ip6tables -D INPUT -p udp -m udp --dport 51820 -j ACCEPT; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -D FORWARD -o wg0 -j ACCEPT;

# Client A
[Peer]
PublicKey = hcU3LDJmlsInRSDFErt+Kp2CZBRzSggvmfOkSKcGx1A=
PresharedKey = ...
AllowedIPs = 10.8.0.2/32, fdcc:ad94:bacf:61a4::cafe:2/128

Mas como o Hub está executando o AlmaLinux 9.5 no OCI, tive que configurar o iptables para usar iptables-legacy.

Agora estou tentando migrar para nftables

Esta é a nova configuração

[Interface]
...
PostUp = nft add table inet wg_table; nft add chain inet wg_table postrouting { type nat hook postrouting priority 100 \; }; nft add rule inet wg_table postrouting ip saddr 10.8.0.0/24 oifname eth0 masquerade; nft add rule inet wg_table postrouting ip6 saddr fdcc:ad94:bacf:61a4::cafe:0/112 oifname eth0 masquerade; nft add chain inet wg_table input { type filter hook input priority 0 \; policy accept \; }; nft add rule inet wg_table input udp dport 51820 accept; nft add chain inet wg_table forward { type filter hook forward priority 0 \; policy accept \; }; nft add rule inet wg_table forward iifname "wg0" accept; nft add rule inet wg_table forward oifname "wg0" accept;
PostDown = nft delete table inet wg_table
...

Tentei ficar o mais próximo possível da regra original do iptables por enquanto.

Mas não funciona usando meu telefone, não consigo me conectar à internet com as novas regras. Mesmo usando iptables-nft, não funciona

iptables
Martin Hope
Magnus
Asked: 2025-03-13 05:41:49 +0800 CST
  • 5

Tenho lido sobre redes esta semana, mas ainda tenho uma lacuna aparentemente significativa no meu entendimento, relacionada a quais endereços IP são acessíveis a partir da minha máquina host e como.

Especificamente, ip -br addrmostra:

lo               UNKNOWN        127.0.0.1/8 ::1/128
tunl0@NONE       DOWN
sit0@NONE        DOWN
ip6tnl0@NONE     DOWN
eth0@if15        UP             198.19.249.109/24 metric 1024 fd07:b51a:cc66:0:439:fcff:fe3f:27d6/64 fe80::439:fcff:fe3f:27d6/64
docker0          DOWN           172.17.0.1/16 fe80::acc7:7cff:fe73:5421/64
br-140e1fbca70a  UP             172.18.0.1/16 fe80::34c3:10ff:fe55:2464/64
vethbf1bfcc@if5  UP             fe80::38fd:c6ff:fe37:f54/64
veth7e8fb76@if5  UP             fe80::689e:8bff:fe81:d8c3/64

E ip routemostra:

default via 198.19.249.1 dev eth0 proto dhcp src 198.19.249.109 metric 1024
0.250.250.200 via 198.19.249.1 dev eth0 proto dhcp src 198.19.249.109 metric 1024
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-140e1fbca70a proto kernel scope link src 172.18.0.1
198.19.249.0/24 dev eth0 proto kernel scope link src 198.19.249.109 metric 1024
198.19.249.1 dev eth0 proto dhcp scope link src 198.19.249.109 metric 1024

E ip neighmostra:

198.19.249.1 dev eth0 lladdr da:9b:d0:54:e0:02 STALE
172.18.0.3 dev br-140e1fbca70a lladdr fe:50:d0:de:5a:ce STALE
fe80::d84c:3aff:fef1:e382 dev eth0 lladdr da:9b:d0:54:e0:02 router STALE

Além disso, docker network inspect ..._..._defaultdiz que a rede possui Gateway 172.18.0.1, com dois contêineres conectados a ela, incluindo 172.18.0.3.

iptablescontém apenas as regras padrão do Docker .

Pergunta :

Corri ip route del 172.18.0.0/16e excluí essa entrada da tabela de roteamento.

Por que não consigo mais acessar o contêiner do Docker agora?

O 172.18.0.3contêiner roda localmente na minha máquina, então eu esperava poder acessá-lo, se eu ajustasse as iptableregras de alguma forma. Não é isso?

iptables
Martin Hope
Lorie
Asked: 2025-03-13 00:27:45 +0800 CST
  • 5

Tenho uma política de rede global que se parece com isso (registrar qualquer pacote que não esteja na porta 30000 e permitir apenas o tráfego para a porta 30000 na interface ens4):

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: internal-rules
spec:
  selector: interface == 'ens4'
  applyOnForward: true
  types:
  - Ingress
  - Egress
  ingress:
  - action: Log
    protocol: TCP
    destination:
      notPorts:
      - 30000:32767
  - action: Allow
    protocol: TCP
    destination:
      ports:
      - 30000:32767
  egress:
  - action: Allow

então aplico isso a uma interface com um hostendpoint como este.

apiVersion: projectcalico.org/v3
kind: HostEndpoint
metadata:
  name: node1-internal-if
  labels:
    interface: ens4
spec:
  interfaceName: ens4
  node: testmdm2503nic-node1

Tenho regras diferentes para as 3 interfaces diferentes que tenho na minha configuração. Em geral, funciona para filtrar meu tráfego, mas vejo pacotes sendo descartados de forma inesperada. Por exemplo, o seguinte pacote é descartado. Observe que a interface IN está em branco; eu teria pensado que ela não deveria ser filtrada por uma das minhas regras de hostendpoint. A porta 30000 é uma das portas que listei como aberta no ens4, mas não tenho certeza de qual interface esse tráfego está chegando.

Ter 11 Mar 18:02:39 2025 : INFO | kickRegressionSuite: 11 Mar 16:43:04 testmdm2503nic-k8sc-node1-2 kernel: calico-packet: IN= OUT=cali6f00f63eeec SRC=1.2.3.4 DST=1.2.8.4 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=9941 DF PROTO=TCP SPT=58082 DPT=30000 WINDOW=64240 RES=0x00 SYN URGP=0 MARK=0x69a04000

Quando um pacote é descartado conforme o esperado, normalmente o log teria o nome da interface listado no campo IN:

20 de fevereiro 10:30:50 loriek8s-k8sc-node2-3 kernel: calico-packet: IN=ens3 OUT= MAC=fa:: SRC=1.1.7.9 DST=1.1.7.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=53798 DF PROTO=TCP SPT=33728 DPT=10250 WINDOW=29200 RES=0x00 SYN URGP=0

alguma ideia do que posso estar fazendo errado ou talvez o registro de pacotes descartados não esteja como eu esperava.

iptables
Martin Hope
barmanthewise
Asked: 2025-01-30 12:10:13 +0800 CST
  • 6

Preciso expor um serviço Wireguard no Kubernetes por meio de um AWS Network Load Balancer.

O Load Balancer não roteia tráfego para meu pod wireguard a menos que as verificações de integridade sejam aprovadas. Como os AWS Load Balancers não oferecem suporte a verificações de integridade UDP, e o wireguard é executado em UDP, anexei um serviço TCP simples ao pod wireguard, mas ele não pode ser alcançado e, portanto, falha nas verificações de integridade.

Aqui está o snippet de especificação de implantação do yaml relevante.

    spec:
      containers:
        - name: "wireguard"
          image: "linuxserver/wireguard:latest"
          ports:
            - containerPort: 51820
              protocol: UDP
          securityContext:
            privileged: true
            capabilities:
              add:
                - NET_ADMIN
        - name: healthcheck
          image: istio/tcp-echo-server:latest
          imagePullPolicy: IfNotPresent
          args: [ "9000", "hello" ]
          ports:
          - containerPort: 9000

Se eu deixar de fora o contêiner wireguard ou comentar a parte NET_ADMIN, garantindo assim que nenhuma configuração de rede seja alterada, posso acessar com sucesso o pod heathcheck, executando, por exemplo:

kubectl run -i --rm --restart=Never dummy --image=busybox -- sh -c "echo world | nc wireguard-service.wg-test 9000"
hello world

Nos logs do contêiner do wireguard, posso ver esses comandos sendo executados. Suspeito que algo na configuração de roteamento do nó seja alterado para que a porta 9000 se torne inacessível.

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.11.0.1/16 dev wg0
[#] ip link set mtu 1450 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[#] sysctl -w -q net.ipv4.ip_forward=1

Tentei adicionar iptables -A INPUT -p tcp --dport 9000 -j ACCEPTe iptables -A FORWARD -p tcp --dport 9000 -j ACCEPTnão adiantou. O que estou esquecendo aqui?

iptables
Martin Hope
jurijus01
Asked: 2025-01-06 06:16:36 +0800 CST
  • 6

Solução de problemas de conectividade IPv4 limitada na porta 25.

Tenha regras ipTables:

  Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  185.121.228.0/24     anywhere            
ACCEPT     all  --  127.0.0.0/24         anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:smtp

Uma vez que a política de ENTRADA padrão é ACEITAR,

root@mail:/home/ubuntu# echo “HELO” | nc -4 smtp.google.com 25
220 mx.google.com ESMTP ffacd0b85a97d-38a1c8bb5f7si23003263f8f.375 - gsmtp
502-5.5.1 Unrecognized command. For more information, go to
502 5.5.1  https://support.google.com/a/answer/3221692 ffacd0b85a97d-38a1c8bb5f7si23003263f8f.375 - gsmtp

Quando a política de ENTRADA padrão é DROP, o mesmo comando trava indefinidamente.

Agora, a parte mais interessante é que a mudança na política de INPUT não tem efeito sobre

root@mail:/home/ubuntu# echo “HELO” | nc -6 smtp.google.com 25

que está recebendo resposta do Google de qualquer maneira.

É preciso que o servidor de e-mail envie e-mails para todos os outros servidores de e-mail, não apenas para aqueles compatíveis com IPv6.

Se alguém pudesse explicar o que está acontecendo, seria fantástico!

Atualizado: a impressão do ip-save é:

:INPUT DROP [41791:1739301]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6390374:3802889072]
-A INPUT -i ens3 -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -s 127.0.0.0/24 -i lo -j ACCEPT
-A INPUT -s 185.121.228.0/24 -i ens3 -j ACCEPT
COMMIT
iptables
Martin Hope
jurijus01
Asked: 2024-12-30 20:30:36 +0800 CST
  • 5

Olá e feliz NYE que se aproxima!

Tentando fazer um firewall na instalação do iRedMail. É preciso manter abertas apenas as portas necessárias para conexões de entrada. Atualmente as regras são:

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:submission
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:submissions
ACCEPT     all  --  localhost            anywhere  
ACCEPT     all  --  185.121.228.0/24     anywhere

A última regra é manter sua conexão SSH ativa.

Atualmente, não há e-mails entrando e saindo, nenhum erro e nenhum e-mail devolvido. Suspeito que isso pode ter algo a ver com certificados SSL usados ​​para SMTP não resolverem nomes de host, mas habilitei a porta 53 "domain" para ele e não está ajudando.

Preso aqui. Assim que a política padrão mudou de DROP para ACCEPT, funcionou como uma brisa.

Qualquer ideia sobre como aplicar firewall no servidor iRedMail corretamente será muito bem-vinda!

Editar: SMTP (porta 25) habilitado por si só, que não está sendo usado de qualquer maneira. Não fez efeito

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:smtp
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:submission
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:submissions
ACCEPT     all  --  localhost            anywhere            
ACCEPT     all  --  185.121.228.0/24     anywhere
iptables
Martin Hope
jurijus01
Asked: 2024-12-23 19:18:13 +0800 CST
  • 5

Onde a configuração do iptables é persistida? A pesquisa não produziu resultados:

/etc/iptables - no such file or directory
/etc/sysconfig - no such file or directory
/etc/init.d/iptables - no such file or directory
/etc/network/if-up.d/ contains ethtool only
/etc/network/if-pre-up.d/ contains ethtool only

Algum outro lugar? Executando Ubuntu 24.04.1 LTS

Suas ideias são muito apreciadas.

iptables
Martin Hope
iopq
Asked: 2024-12-21 02:26:18 +0800 CST
  • 3

Estou executando meu cliente proxy na mesma máquina Linux em que estou usando a conexão. Na configuração, posso dizer para ele fazer tproxy para a porta 2500. O proxy é executado na porta 443, usando TLS (embora o proxy assuma o gerenciamento dessa parte)

Então preciso usar iptables ou nftables para rotear todos os pacotes para o proxy. Mas preciso marcá-los também, para não criar um loop.

Minhas tentativas iniciais não tiveram sucesso, parece que meus pacotes UDP não passaram (estou atrás de um NAT, mas não sei se é esse o problema, já que estou fazendo proxy de qualquer maneira). Gostaria de saber como funciona melhor para que eu possa depurar sozinho.

Aqui está minha tentativa:

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

#Setup a chain DIVERT to mark packets
iptables -t mangle -N DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT

#Use DIVERT to prevent existing connections going through TPROXY twice:
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A PREROUTING -p udp -m socket -j DIVERT

#Mark all other (new) packets and use TPROXY to pass into xray
iptables -t mangle -A PREROUTING -p tcp -j TPROXY --tproxy-mark 0x1/0x1 --on-port 2500
iptables -t mangle -A PREROUTING -p udp -j TPROXY --tproxy-mark 0x1/0x1 --on-port 2500

#disable rp_filter and enable ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.conf.default.rp_filter=0
sysctl -w  net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.wlp38s0.rp_filter=0

os pacotes simplesmente passam pelas minhas regras como se não existissem

iptables