☰

Ruta estática a través del firewall nftables

tag-icon • tag-icon firewall nat centos8 nftables static-routes
Ruta estática a través del firewall nftables

Tengo una puerta de enlace "X" con 2 NIC

enp0s3 (192.168.0.100) conectado a 192.168.0.0/24 (supongamos que se trata de una red WAN)

enp0s8 (172.16.0.1) conectado a 172.16.0.0/24 (presumiblemente una red LAN)

He creado una conexión NAT usando nftables para permitir que los hosts en la LAN (172.16.0.0/24) naveguen por Internet a través de la puerta de enlace "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
  }
}

Ahora, necesito un host (192.168.0.101) que es una computadora portátil de la WAN (red 192.168.0.0/24) para acceder a los hosts en la LAN (red 172.16.0.0/24) a través de la puerta de enlace "X". es decir, necesito configurar una ruta estática desde este host (192.168.0.101) en la WAN a la LAN (red 172.16.0.0/24).

Esta es la ruta estática que estoy intentando agregar en la computadora portátil que está en la red 192.168.0.0/24 a través de su interfaz wlo1.

ip route add 172.16.0.0/24 via 192.168.0.100 dev wlo1

Las reglas en el firewall de la puerta de enlace impiden que estos paquetes ingresen a la red 172.16.0.0/24.

¿Cómo permito esto en mi puerta de enlace?

Sé que las reglas del firewall descartan los paquetes porque

probando con

ping 172.16.0.2

desde 192.168.0.101 mientras se ejecuta

tcpdump -lnni any src 192.168.0.101

desde la puerta de enlace "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

Respuesta1

Sudoslos conjuntos de reglas tienen un defecto:

flush ruleset

Si ambos se ejecutan en secuencia, solo flush rulesetquedará el último.

Cada uno flush rulesetdebe cambiarse a respectivamente:

table inet filter
delete table inet filter

y:

table ip nat
delete table ip nat

para obtener cada vez una definición de tabla idempotente que no fallará en el primer uso ni se duplicará ni afectará elotromesa.

Ahora sobre la pregunta, es tan simple como insertar una regla de avance para permitir esto en el lugar correcto: antes de la regla de caída, entonces cualquiera de:

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

si no:

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

Probar,

o directamente editando el conjunto de reglas en el lugar correcto para conservarlo:

...
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 la regla se le puede agregar opcionalmente un iifname enp0s3(=> iifname enp0s3 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept) para mayor seguridad.

El tráfico de retorno ya lo maneja la regla con estado ( ... ct state related, established ...).

información relacionada