☰

Rota estática via firewall nftables

tag-icon • tag-icon firewall nat centos8 nftables static-routes
Rota estática via firewall nftables

Tenho um gateway "X" com 2 NICs

enp0s3 (192.168.0.100) conectado a 192.168.0.0/24 (vamos supor que esta seja uma rede WAN)

enp0s8 (172.16.0.1) conectado a 172.16.0.0/24 (presumivelmente uma rede LAN)

Criei uma conexão NAT usando nftables para permitir que hosts na LAN (172.16.0.0/24) naveguem na Internet através do gateway "X".

/etc/nftables/nftables_firewall

flush ruleset
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state {established, related} accept
    ct state invalid drop
    iifname lo accept
    iifname enp0s8 accept
    ip protocol icmp accept
    reject
  }

  chain forward {
    type filter hook forward priority 0;
    oifname enp0s3 accept
    iifname enp0s3 ct state related, established accept
    iifname enp0s3 drop
  }

  chain output {
    type filter hook output priority 0;
  }

}

/etc/nftables/nftables_nat

flush ruleset
table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
  }

  chain postrouting {
    type nat hook postrouting priority 0;
    oifname enp0s3 masquerade
  }
}

Agora preciso de um host (192.168.0.101) que seja um laptop da WAN (rede 192.168.0.0/24) para acessar hosts na LAN (rede 172.16.0.0/24) através do gateway "X". ou seja, preciso configurar uma rota estática deste host (192.168.0.101) na WAN para a LAN (rede 172.16.0.0/24).

Esta é a rota estática que estou tentando adicionar no laptop que está na rede 192.168.0.0/24 por meio de sua interface wlo1

ip route add 172.16.0.0/24 via 192.168.0.100 dev wlo1

As regras no firewall do gateway estão bloqueando a entrada desses pacotes na rede 172.16.0.0/24.

Como faço para permitir isso no meu gateway?

Eu sei que os pacotes estão sendo descartados pelas regras do firewall porque

testando com

ping 172.16.0.2

de 192.168.0.101 durante a execução

tcpdump -lnni any src 192.168.0.101

do gateway "X" responde

11:41:53.240815 IP 192.168.0.101 > 172.16.0.2: ICMP echo request, id 8, seq 1, length 64
11:41:54.243947 IP 192.168.0.101 > 172.16.0.2: ICMP echo request, id 8, seq 2, length 64
11:41:58.247687 ARP, Request who-has 192.168.0.100 tell 192.168.0.101, length 46

Responder1

Seudoisconjuntos de regras têm uma falha:

flush ruleset

Se ambos forem executados em sequência, pois flush rulesetapenas o último permanecerá.

Cada um flush rulesetdeve ser alterado para respectivamente:

table inet filter
delete table inet filter

e:

table ip nat
delete table ip nat

para obter sempre uma definição de tabela idempotente que não falhará no primeiro uso, nem se duplicará, nem afetará ooutromesa.

Agora sobre a questão, é tão simples quanto inserir uma regra de encaminhamento para permitir isso no lugar certo: antes da regra de eliminação, então:

# nft insert rule inet filter forward index 2 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept

se não:

# nft add rule inet filter forward index 1 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept

testar,

ou então diretamente editando o conjunto de regras no lugar certo para mantê-lo:

...
iifname enp0s3 ct state related, established accept
ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept
iifname enp0s3 drop
...

A regra pode ser opcionalmente adicionada iifname enp0s3(=> iifname enp0s3 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept) para segurança extra.

O tráfego de retorno já é tratado pela regra stateful ( ... ct state related, established ...).

informação relacionada