У нас есть сервер OpenBSD, используемый в качестве брандмауэра с использованием известного pf. Брандмауэр подключен к Интернету с одной стороны и к локальной сети с другой. мы испытываем сбой соединения из-за того, что pf достигает максимального количества состояний (которое составляет 20000), это происходит менее чем за час, затем думает, что возвращается в нормальное состояние. Есть ли способ определения хостов, открывающих эти состояния. Помогает ли увеличение количества состояний в pf.conf?
большое спасибо
Здесь вы можете сделать несколько вещей.
Чтобы увидеть, какие хосты отвечают за большое количество записей в таблице состояний, вы можете сделать pfctl -vs state.
Чтобы добавить больше записей в таблицу состояний, вы можете сделать то, что вы предложили (set limit states на большее число), но если есть основная проблема, вы, вероятно, не захотите этого делать.
Вы также можете рассмотреть возможность настройки значений тайм-аута состояния (set timeout), возможно, используя адаптивные тайм-ауты, чтобы быстрее избавиться от старых / устаревших состояний.
Увидеть справочная страница для pf.conf и справочная страница для pfctl Чтобы получить больше информации
[Ссылка: Достижение предела таблицы состояний PF]
Таблицы состояний PF устанавливают лимит разрешенных соединений и, таким образом, ограничивают количество новый соединения, которые принимает брандмауэр. У вас может быть доступная избыточная пропускная способность, но если в таблицах состояний нет свободной емкости, то ваш брандмауэр становится узким местом.
Настроенные ограничения для информации о состоянии доступны через "pfctl"
# pfctl -sm
states hard limit 10000 src-nodes hard limit 10000 frags hard limit 5000 tables hard limit 1000 table-entries hard limit 200000
Вышеупомянутые ограничения предварительно устанавливают выделенную память для определенных структур, так что они всегда доступны, а также ограничивают рост упомянутых структур данных. Если трафик вашего брандмауэра превышает указанные выше параметры, производительность будет снижена.
Теперь важно отслеживать влияние вашего трафика на счетчики для вышеуказанных лимитов. Общий вывод «-s info *» дает нам подсказки, где дальше исследовать потенциальные узкие места в нашем брандмауэре.
# pfctl -si
Status: Enabled for XXXXXXXXXXXXXXXX Debug: Urgent State Table Total Rate current entries 34 searches 96379206 15.2/s inserts 726196 0.1/s removals 726162 0.1/s
На указанном выше шлюзе, подключенном к двум редко используемым ноутбукам, текущие записи очень низкий по сравнению с жесткий лимит 10000 выше. Очевидно, что текущие записи будет изменяться из-за использования, а на более загруженном шлюзе может значительно изменяться.
[Ссылка: Достижение предела таблицы состояний PF, Достигнут жесткий предел открытого состояния BSD]
Важный счетчик, за которым нужно следить pfctl -si это "объем памяти"счетчик. Те же сведения можно получить через systat pf
Из активного шлюза, связывающего наши 6 сайтов, мы получаем следующее при стандартной установке, никаких изменений в таблицах состояний.
# pfctl -si | grep memory
memory 209230 0.1/s
Счетчик показывает, как часто PF отказывает хотя бы в одном из «пула (9)». Чем выше число, тем выше частота случаев, когда пакеты, поступающие на межсетевой экран, скорее всего, были отброшены из-за одного из аппаратных ограничений.
В нашем примере выше показано, что ограничение памяти было в 209230 раз больше. ударить.
Следующий обзор - проверка распределения памяти ядра с помощью "vmstat". Чтобы сузить наш поиск до эффектов в таблице состояний pf, мы проверяем запись на pfstatepl.
Ниже мы берем строки с состоянием или Fail (чтобы мы могли получить заголовки столбцов)
# vmstat -m | grep -E "state|Fail"
Name Size Requests Fail InUse Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle pfstatepl 296 213123877 209235 5075 1050 0 1050 1050 0 2308 526 pfstatekeypl pfstateitempl
pfstatepl это метка памяти, выделенной для struct pf_state (/usr/src/sys/net/pf_ioctl.c) Сбои действительно кажутся значительными.
pfctl -vvsi | перегрузка grep