rawsend: sendto: Permission denied

[ngitn]

~ [SIGINT]> sudo nfqws --methodeol --qnum=200
self-built version Jan  3 2025 18:23:19

we have 1 user defined desync profile(s) and default low priority profile 0
Running as UID=2147483647 GID=2147483647
opening library handle
unbinding existing nf_queue handler for AF_INET (if any)
binding nfnetlink_queue as nf_queue handler for AF_INET
binding this socket to queue '200'
setting copy_packet mode
initializing raw sockets bind-fix4=0 bind-fix6=0
rawsend: sendto: Permission denied
rawsend: sendto: Permission denied
rawsend: sendto: Permission denied
rawsend: sendto: Permission denied
rawsend: sendto: Permission denied
rawsend: sendto: Permission denied
rawsend: sendto: Permission denied
rawsend: sendto: Permission denied
rawsend: sendto: Permission denied
rawsend: sendto: Permission denied

[bol-van]

А подробности ? Какая система, ядро, используется ли контейнер, как настроены правила tables
Одна из возможных причин - срабатывание правила tables DROP в цепочке OUTPUT

[Gualterus]

Дополню от себя: в отличие от автора запускаю dvtws.
OS: FreeBSD 14.2-RELEASE-p1 (OPNSense 25.1).

В логе каждые 10-15 мин лаги пока не перезапустишь (monit + скрипт отслеживания лога этим занимается) и по паре десятков подобных сообщений:

<29> rawsend: sendto_divert: Permission denied
<29> reinject sendto: Permission denied

В файрволе стандартные правила блокировки входящих (хоть и простыня на 2 экрана, если нужно - скину)

rc.d скрипт:

#!/bin/sh
#
# PROVIDE: dvtws
# REQUIRE: SERVERS
# KEYWORD: shutdown

. /etc/rc.subr

name=dvtws
rcvar=dvtws_enable
pidfile=/var/run/${name}.pid
app=/usr/local/bin/${name}
app_args='--user=dvtws --port 989 --dpi-desync=fakedsplit --dpi-desync-fooling=badseq --dpi-desync-split-pos=midsld'
command="/usr/sbin/daemon"
command_args="-R 30 -S -P ${pidfile} ${app} ${app_args}"
start_precmd="dvtws_start"
stop_postcmd="dvtws_shutdown"

dvtws_start()
{
        kldload ipfw 2> /dev/null
        kldload ipdivert 2> /dev/null
        pfctl -d ; pfctl -e
        ipfw delete 989
        rule='add 989 divert 989 tcp from any to not 127.0.0.0/8,10.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16 22,80,443,2083,8443,3520,51800 out not diverted not sockarg'
        grep -F "${rule}" /usr/local/etc/ipfw.rules > /dev/null || echo "${rule}" >> /usr/local/etc/ipfw.rules
        ipfw ${rule}> /dev/null
}

dvtws_shutdown()
{
        if [ -e "${pidfile}" ]; then
                echo "Stopping ${name}."
                kill `cat "${pidfile}"`
                rm -f "${pidfile}"
        fi
        ipfw delete 989
}

load_rc_config $name
: ${dvtws_enable:="NO"}

run_rc_command $1

P.S. вроде как проблему с зацикливанием divert на pf исправили, но правило вида
pass in quick on bridge0 proto tcp from any to port { 443 } divert-to 127.0.0.1 port 989
не работает (совсем отрубает подключение), но тут вполне возможно у меня руки кривые (буду благодарен за подсказку).

[bol-van]

Очень может быть, что там какое-то переполнение буферов ipdivert, и он просто не успевает что-то сделать.
А в ядре не сильно морочились и возвращают в этом случае -EPERM
У вас мощный трафик ? Нет ли параллельно работающего pf ?
Нет ли каких-то еще правил ipfw/pf ?
Был случай, что происходили ошибки shutdown() из-за каких-то правил pf. Их убирали, и они пропадали

[Gualterus]

Благодарю за ответ.

По крайней мере dmesg никаких ошибок не выдаёт, по остальным логам тоже ничего любопытного.
Трафик обычный домашний, 24/7 разве что камера в облако пишет, да телефон что-то большому брату сливает (по стате ~600кбит/с).
Параллельно работающий pf есть (для понимания: opnsense - это форк pfsense, так что у него штатный как раз pf, но его правило не завелось, потому и добавлял в ipfw).

Все правила во вложении. Из кастомного только в ipfw.rules прописывается divert (строчка из rc.d скрипта выше), остальные правила - autogenerated.

• LAN
  

• WAN
  

ipfw.rules.txt
pf.txt

в pf.txt:

• igc0 - wan,
• bridge0 - lan,
• 172.31.10.0/24 - домашняя сеть,
• 100.80.0.0/14 - провайдерский nat

[bol-van]

Что они там нафиксили мне непонятно.
На 14.2-RELEASE точно такое же поведение.
После первого отсыла средствами dvtws бесконечная простыня в --debug процессинга одного и того же

[Gualterus]

Да нет, что-то пофиксили.

Убрал из rc.d вызов ipfw, поковырялся я всё же с pf и вышло следующее.

Код opnsense формирует список правил в файл /tmp/rules.debug, откуда потом считывает данные pf.
https://github.com/opnsense/core/blob/8524771f525ef82ec8c25dcef7df4a16a5de1441/src/etc/inc/filter.inc#L377

Вышеуказанная строка divert не работала у меня, потому, что брал правила, которые уже есть в pf (pfctl -s rule), дописывал своё правило в конец и уже потом скармливал pf. Вот только почти все автогенерённые правила - quick, то есть обработка заканчивается при первом совпадении (а обработка правил в порядке расположения в файле), то есть до divert попросту файрволл не доходил и отправлял на out уже на правиле

pass in quick on bridge0 inet from (bridge0:network) to any flags S/SA keep state

то есть Default allow LAN to any rule

Если добавить правило divert до default allow, то оно срабатывает и dvtws вполне себе работает (причём пока что сообщений в логе не увидел, хотя обычно раз в 10-15 мин появляется). Иными словами я вручную отредактировал /tmp/rules.debug следующим образом:

...
#>>>
pass in quick on bridge0 proto tcp from {(bridge0:network)} to ! $PRIVATE_NETWORKS port $OVER_TUNNEL_PORTS divert-to 127.0.0.1 port 989 
#<<<
pass in quick on bridge0 inet from {(bridge0:network)} to {any} label "e5987ddd1fc4e7790f12bf49d4e48429" # Default allow LAN to any rule
pass in quick on bridge0 inet6 from {(bridge0:network),fe80::/10} to {any} label "06350d94efd1a0834002e1267c54ad5f" # Default allow LAN IPv6 to any rule

($PRIVATE_NETWORKS и $OVER_TUNNEL_PORTS - записал через веб интерфейс)

скормил через pfctl -f /tmp/rules.debug и заулыбался.

Загвоздка тут следующая: стоит через веб морду добавить/удалить/поправить любое правило и перезагрузить файрволл - добавленная строка удалится, перезагрузить opnsense - аналогично, получить новый dhcp адрес от провайдера - всё то же (rc.newwanip дёргает перезагрузку файрволла в том числе). Надо будет подумать как заставить правило добавляться автоматом.

[bol-van]

Я не проверял на incoming. Но если сделать обработку трафика с самого хоста, получается loop
pass out on vmx0 proto tcp from any to port { 80,443 } divert-to 127.0.0.1 port 989
С ipfw такой проблемы нет

[Gualterus]

Думаю, стоит ограничить пакетами, которые летят далеко.
Запустил чистую виртуалку на ноуте с мобильным интернетом, закинул zapret, выполнил следующие строки

kldload pf
kldload ipdivert
pfctl -d
pfctl -e
pfctl -F all
echo 'table <private_nets> { 127/8, 10/8, 100.64/10, 172.16/12, 192.168/16 }
pass out quick proto tcp from any to ! <private_nets> port {80, 443} divert-to 127.0.0.1 port 989' | pfctl -f -
./zapret-v70.3/binaries/freebsd-x64/dvtws --user=nobody --dpi-desync=fakedsplit --dpi-desync-ttl=1 --dpi-desync-autottl=2 --dpi-desync-split-pos=midsld --port 989 --debug > /tmp/dvtws.log 2> /tmp/dvtws.log &

fetch https://rutracker.org/forum/index.php -o index.html

(вместо from any пробовал ещё from self, но не суть)
нужная страница (не заглушка провайдера) скачивается.

Я, правда, не могу по логу определить, что происходит зацикливание.

dvtws.log

Единственное что: уже с выключенным debug использовал виртуалку как прокси через ssh (ssh -D1234 ... + socks5 в firefox-е) и порой проскакивало reinject sendto: Message too long + браузер на speedtest.net и speed.cloudflare.com ругается SSL_ERROR_RX_RECORD_TOO_LONG