☰

Статический маршрут через брандмауэр nftables

tag-icon • tag-icon firewall nat centos8 nftables static-routes
Статический маршрут через брандмауэр nftables

У меня есть шлюз "X" с 2 сетевыми картами

enp0s3 (192.168.0.100) подключен к 192.168.0.0/24 (предположим, что это сеть WAN)

enp0s8 (172.16.0.1) подключен к 172.16.0.0/24 (предположительно, локальная сеть)

Я создал NAT-соединение с помощью nftables, чтобы разрешить хостам в локальной сети (172.16.0.0/24) выходить в Интернет через шлюз «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
  }
}

Теперь мне нужен хост (192.168.0.101), который является ноутбуком из WAN (сеть 192.168.0.0/24), для доступа к хостам в LAN (сеть 172.16.0.0/24) через шлюз «X». Т.е. мне нужно настроить статический маршрут от этого хоста (192.168.0.101) в WAN к LAN (сеть 172.16.0.0/24).

Это статический маршрут, который я пытаюсь добавить на ноутбук, который находится в сети 192.168.0.0/24 через интерфейс wlo1.

ip route add 172.16.0.0/24 via 192.168.0.100 dev wlo1

Правила межсетевого экрана шлюза блокируют вход этих пакетов в сеть 172.16.0.0/24.

Как разрешить это на моем шлюзе?

Я знаю, что пакеты отбрасываются правилами брандмауэра, потому что

тестирование с

ping 172.16.0.2

с 192.168.0.101 во время работы

tcpdump -lnni any src 192.168.0.101

из шлюза "X" отвечает

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

решение1

ТвойдваУ наборов правил есть недостаток:

flush ruleset

Если выполнить оба действия последовательно, то flush rulesetостанется только последнее.

Каждый из flush rulesetних следует изменить на:

table inet filter
delete table inet filter

и:

table ip nat
delete table ip nat

чтобы каждый раз получать идемпотентное определение таблицы, которое не даст сбой при первом использовании, не будет дублировать себя и не повлияет надругойстол.

Теперь о вопросе: это так же просто, как вставить правило пересылки, чтобы разрешить это в нужном месте: перед правилом отбрасывания, так что одно из следующего:

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

или еще:

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

тестировать,

или же напрямую, отредактировав набор правил в нужном месте, чтобы сохранить его:

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

При желании к правилу можно добавить iifname enp0s3(=> iifname enp0s3 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept) для дополнительной безопасности.

Обратный трафик уже обрабатывается правилом с отслеживанием состояния ( ... ct state related, established ...).

Связанный контент