LINUX.ORG.RU

Debian 12 & nftables на неспешном устройстве. Можно ли замедлить процессы?

 ,


0

1

Здравствуйте.

Имеется:

  1. Raspberry Pi B+ 1.2
Linux rpi 6.6.51+rpt-rpi-v6 #1 Raspbian 1:6.6.51-1+rpt3 (2024-10-08) armv6l GNU/Linux
  1. USB-WiFi
Bus 001 Device 004: ID 148f:761a Ralink Technology, Corp. MT7610U ("Archer T2U" 2.4G+5G WLAN Adapter)
  1. nftables
# dpkg-query -l | grep nftables
nftables 1.0.6-2+deb12u2
# systemctl list-units --type=service --all | grep nftables
  nftables.service  loaded    active   exited  nftables
# cat /usr/lib/systemd/system/nftables.service 
[Unit]
Description=nftables
Documentation=man:nft(8) http://wiki.nftables.org
Wants=network-pre.target
Before=network-pre.target shutdown.target
Conflicts=shutdown.target
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
StandardInput=null
ProtectSystem=full
ProtectHome=true
ExecStart=/usr/sbin/nft -f /etc/nftables.conf
ExecReload=/usr/sbin/nft -f /etc/nftables.conf
ExecStop=/usr/sbin/nft flush ruleset

[Install]
WantedBy=sysinit.target

# cat /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table ip shared-wlan0 {
    chain nat_postrouting {
	type nat hook postrouting priority srcnat; policy accept;
	ip saddr 172.16.13.0/24 ip daddr != 172.16.13.0/24 masquerade
    }

    chain filter_forward {
	type filter hook forward priority filter; policy accept;
	ip daddr 172.16.13.0/24 oifname "wlan0" ct state { established, related } accept
	ip saddr 172.16.13.0/24 iifname "wlan0" accept
	iifname "wlan0" oifname "wlan0" accept
	iifname "wlan0" reject
	oifname "wlan0" reject
    }
}

Оба интерфейса (eth0 и wlan0) устройства под управлением NetworkManager. wlan0:

# cat /etc/NetworkManager/system-connections/WIFIUSBAP.nmconnection
[connection]
id=WIFIUSBAP
uuid=53641af8-1202-233d-6a69-26a7501f784f
type=wifi
interface-name=wlan0
timestamp=1739354341

[wifi]
band=a
channel=36
mode=ap
ssid=VerySlowAP

[wifi-security]
group=ccmp;
key-mgmt=wpa-psk
pairwise=ccmp;
pmf=1
psk=megasupersecretpassword

[ipv4]
address1=172.16.13.1/24
method=shared

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

При включении/перезагрузке устройства правила для nat, указанные выше для nftables в его конфигурации, отсутствуют

#nft -s list ruleset
<ПУСТО>

На сколько я догадываюсь, но могу и ошибаться, это происходит из-за того, что подключение eth0 происходит «мухой», а вот назначение адреса для интерфейса wlan0 на устройстве «Archer T2U» - это процедура неспешная.

Нет, всё работает, но по моим наблюдениям надо секунд 5-7 и адрес на интерфейс wlan0 так и назначается. Однако, сервис nftables срабатывает всегда раньше, чем wlan0 получает адрес.

Собственно, можно вручную перезапустить nftables после получения адреса wlan0 и всё будет хорошо.

И тут я впал в ступор. Не могу сообразить как бы так попроще заставить nftables срабатывать при старте операционной системы с неспешным «Archer T2U» именно после того, как именно этот «Archer T2U» получит адрес? Может быть, кто-нибудь не сочтёт за труд подсказать. Спасибо.


Я не специалист, но давай попробуем че-нить навелосипедить.

Before= shutdown.target

А это точно так должно быть?

При включении/перезагрузке устройства правила для nat, указанные выше для nftables в его конфигурации, отсутствуют

Что в логах при этом?

Видел варианты, что прописывали юниту After= и Wants= network-online.target или systemd-networkd-wait-online.service (этот вроде нужно активировать systemctl enable systemd-networkd-wait-online.service).

Насколько оно правильно или работоспособно не могу прокомментирровать.

sehellion ★★★★★
()
Ответ на: комментарий от sehellion

В юните nft всё по умолчанию. Я не трогал. Сейчас проверил: если добавить таймаут:

# cat /usr/lib/systemd/system/nftables.service 
[Unit]
Description=nftables
Documentation=man:nft(8) http://wiki.nftables.org
Wants=network-pre.target
Before=network-pre.target shutdown.target
Conflicts=shutdown.target
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
StandardInput=null
ProtectSystem=full
ProtectHome=true
ExecStart=/usr/sbin/nft -f /etc/nftables.conf
ExecReload=/usr/sbin/nft -f /etc/nftables.conf
ExecStop=/usr/sbin/nft flush ruleset
TimeoutSec=10

[Install]
WantedBy=sysinit.target

То после рестарта всё хорошо и правила nftables применяются, и существуют.

Если TimeOut в юните понизить до 3… то снова пусто - правил как бы нет (или они не применяются).

Вот где-то от 3 до 10 секунд….

systemd-networkd-wait-online.service - это «в другую сторону» У меня wlan0 - это внутренний интерфейс. Ну, как бы, он должен работать со всеми правилами (не только про nat) и без онлайна.

LaLe
() автор топика
Ответ на: комментарий от sehellion

Это, наверное, надо в юнит nft что-нибудь добавить (не знаю что) с целью усугубления журналирования.

А так… Ничего особо информативного:

# journalctl --unit=nftables -r
фев 12 22:27:18 rpi systemd[1]: Finished nftables.service - nftables.
-- Boot f82ef352181f40359a20178e3c3b5bae --
фев 12 22:27:12 rpi systemd[1]: Stopped nftables.service - nftables.
фев 12 22:27:12 rpi systemd[1]: nftables.service: Deactivated successfully.
фев 12 22:27:11 rpi systemd[1]: Stopping nftables.service - nftables...
фев 12 22:24:53 rpi systemd[1]: Finished nftables.service - nftables.
-- Boot 604ec607b5a74230aba31c516fb38c9c --
фев 12 22:24:48 rpi systemd[1]: Stopped nftables.service - nftables.
фев 12 22:24:48 rpi systemd[1]: nftables.service: Deactivated successfully.
фев 12 22:24:46 rpi systemd[1]: Stopping nftables.service - nftables...
фев 12 21:46:59 rpi systemd[1]: Finished nftables.service - nftables.
-- Boot b2daef9bc36d44bc8171abbd2a69c938 --
фев 12 21:46:53 rpi systemd[1]: Stopped nftables.service - nftables.
фев 12 21:46:53 rpi systemd[1]: nftables.service: Deactivated successfully.
фев 12 21:46:52 rpi systemd[1]: Stopping nftables.service - nftables...
фев 12 21:44:58 rpi systemd[1]: Finished nftables.service - nftables.
фев 12 21:44:57 rpi systemd[1]: Starting nftables.service - nftables...
-- Boot 22da6944e8bc41c992acc2fb996a1166 --
фев 12 21:35:35 rpi systemd[1]: Stopped nftables.service - nftables.
фев 12 21:35:35 rpi systemd[1]: nftables.service: Deactivated successfully.
фев 12 21:35:33 rpi systemd[1]: Stopping nftables.service - nftables...
фев 12 20:00:50 rpi systemd[1]: Finished nftables.service - nftables.
фев 12 20:00:49 rpi systemd[1]: Starting nftables.service - nftables...
LaLe
() автор топика
Ответ на: комментарий от anonymous

Да, я понял о чём вы кратко спрашиваете:

oot@rpi:~# systemctl status nftables
● nftables.service - nftables
     Loaded: loaded (/lib/systemd/system/nftables.service; enabled; preset: enabled)
     Active: active (exited) since Wed 2025-02-12 22:27:18 MSK; 12min ago
       Docs: man:nft(8)
             http://wiki.nftables.org
    Process: 188 ExecStart=/usr/sbin/nft -f /etc/nftables.conf (code=exited, status=0/SUCCESS)
   Main PID: 188 (code=exited, status=0/SUCCESS)
        CPU: 262ms

фев 12 22:27:18 rpi systemd[1]: Finished nftables.service - nftables.
Notice: journal has been rotated since unit was started, output may be incomplete.
LaLe
() автор топика
Ответ на: комментарий от LaLe

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

У меня nftables на bpi r3 и rpi 4b стартует до systemd-networkd и работает как ожидалось.

anonymous
()
Ответ на: комментарий от anonymous

Значит, так себе и запомню: выдумал я себе чепуху, а на самом деле всё не так, каким оно кажется.

Спасибо. Теперь буду думать, что сервис по каким-то неведомым причинам иной раз тупо не стартует. Не очевидно, что как это он не стартует (иной раз), но с пометкой в журнале, что он «финиширует/останавливается». Неожиданно как-то… Для свежего ума эти записи в журнале принять без помощников не вышло.

Но ваш опыт мне был крайне полезен - это факт.

Отмечу, пожалуй, вопрос решённым. Ибо иногда не стартующий по тем или иным причинам демон - это уже совершенно иной вопрос.

LaLe
() автор топика