ssh pfctl -f

[BlitzKrieg]

Любой может догадаться, однако ты не ответил на мои вопросы.
Вопрос простой, не нужно читать ман чтобы на него ответить. Что происходит с правилами перед перезагрузкой их из файла? Ответь на этот вопрос, сразу станет все понятно.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Saddy]

Блин еще раз тебе говорю, pfctl не очищает таблицы при загрузке правил.

[BlitzKrieg]

А что он делает?

[Saddy]

Видимо фризит модуль ядра, очищает список правил, загружает новый, запускает модуль, при этом таблицы состояний не очищаются. Если интересны подробности смотри лучше исходники.

[BlitzKrieg]

Правила после отключения если локально посмотреть были?

[Saddy]

Да, все на месте и все работает. Переподключаешься и продолжаешь дальше работать - некритичная проблема сама по себе.

[BlitzKrieg]

А кто писал, что машина пинговаться перестает и подключиться нельзя?

[Saddy]

Да, перепутал, больше года прошло. После рестарта машины правила подхватываются, это после pf -d, pf -ef работало, а если не рестартовать - висло.

[BlitzKrieg]

Висло всмысле, что после pfctl -f нельзя было подключиться? Но при этом при локальном подключении в списке правил чего было?

[Saddy]

не в курсе, сервер был удаленный

[FreeBSP]

ssh дропает соединение если не удается доставить хоть один байт
очевидно что во время перезагрузки правил, когда ПФ ничего не пускает, идет какой то вывод, который дропается файером, в результате чего и падает ssh сессия и прерывается загрузка правил.
keep-alive пакетов в ssh вроде нет и падение канала на две минуты он переживает нормально, если в это время ничего никуда не передается.

Код: Выделить всё

fbsd1# ipfw -q add 1 deny ip from any to any && sleep 120 && ipfw -q delete 1 && echo wor~k
wor~k
fbsd1#

ttyp0

Код: Выделить всё

fbsd1# kldload ipfw
# ssh упал

ttyv0

Код: Выделить всё

ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding
disabled, default to deny, logging disabled
Jul 26 17:27:03 fbsd1 sshd[78198]: fatal: Write failed: Permission denied

непосредственная причина падения ssh сессии - это невозможность вывести приглашение на удаленный ssh терминал
а появление ipfw deny all - это уже косвенная причина падения ssh сессии
фатал sshd убивает и всех его потомков, в том числе шелл, и запущенные на нем программы одной из которых может быть pfctl, убиваемый до загрузки новых правил, но после дропа старых

если на удаленной консоли

Код: Выделить всё

fbsd1# set prompt=""
kldload ipfw

то сессия не обрубается

по делу - попробуй пользовать pfctl - q

Код: Выделить всё

# pfctl -f /etc/pf.conf
No ALTQ support in kernel
ALTQ related functions disabled
# pfctl -qf /etc/pf.conf       
#  

[Saddy]

Спасибо за столь развернутый комментарий, вполне вероятно так что дело в этой особенности ssh, но есть пара моментов:
1) уже все давно неактуально, так как уже полгода как у меня нет этого сервера, да и больше никто подобные вопросы (судя по гуглению) не задает - видимо либо настраивают pf через физическую консоль, либо все-таки тут есть еще какие-то тонкости, т.к.
2) команда -f типовая, приводится во всех руководствах по pf для перегрузки правил "на лету" и самое главное - в большинстве случаев она не дисконнектит ssh. Я даже для проверки только что поднял в virtualbox фрю с pf, зашел на неё через ssh, даю pfctl -f - отрабатывает нормально (правда конфиг практически пуст), но факт что потери пакетов нет. Да и в инете было бы куча примеров если это была бы так просто локализуемая проблема

[BlitzKrieg]

Я тоже это проделал, если сделать pfctl -F state вот чего в логе Jul 26 13:53:37 ClusterN1 sshd[1069]: fatal: Write failed: Operation not permitted
вероятно при каких-то событиях или же в каких-то версиях, что-то некорректно срабатывало и сбрасывались динамические правила ( в терминологии ipfw). В таком случае помог бы nohup который я и предлагал.

[FreeBSP]

это кстати по ssh было

Код: Выделить всё

# pfctl -f /etc/pf.conf
No ALTQ support in kernel
ALTQ related functions disabled
# pfctl -qf /etc/pf.conf       
#  

[BlitzKrieg]

да кто бы спорил. речь о другом.

[animal_alpha]

я конечно понимаю что теме уже 5 лет, а последнему сообщению 2 года. Но я столкнулся с данной проблемой сейчас(FreeBSD freebsd 10.0-RELEASE FreeBSD 10.0-RELEASE #0: Wed Oct 15 19:13:53 MSK 2014 xxx@freebsd:/usr/obj/usr/src/sys/ROUTER amd64).
Проблема оказалась в опции set skip on на том интерфейса, через который сидишь по ссш.
обычно так делают на интерфейсе локалки (внутри сети хакеров нет)
вылечил так:
опцию set skip on $lan_if убрал
вместо неё влепил правила pass out on $lan_if all
pass in on $lan_if all
может кому пригодится.