Фильтрация пакетов, NAT, большой обьём трафик
-
-
Добрый.
Нет. Это была ложь с вашей стороны, неуважаемый Fallen_A.
И оч. может случиться так, что на вашу просьбу помочь просто не обратят внимание. Как на "сарказм". -
Добрый.
Нет. Это была ложь с вашей стороны, неуважаемый Fallen_A.
И оч. может случиться так, что на вашу просьбу помочь просто не обратят внимание. Как на "сарказм".В чем ложь? В том, что вы даете советы зная, что ТС этого топика так не поступит? Это можно перечитать вам и понять еще раз.
Что касается моей последней темы - то вы не дали внятного ответа, а влезли все с тем же LEDE.
Так где ложь? Научитесь следить за темой разговора уже наконец.
-
Господа, давайте не будет оффтопить!
По скольку у меня интеловская сетевая I350-T4, то по подсказке Fallen_A сделал оптимизацию этой сетевой для FreeBSD, а именно:
В файл /boot/loader.conf.local
добавил следующие строкиkern.ipc.nmbclusters="1500000"
hw.igb.rxd="4096"
hw.igb.txd="4096"
net.pf.states_hashsize=2097152
net.pf.source_nodes_hashsize=2097152
hw.igb.fc_setting=0
hw.igb.rx_process_limit="-1"
hw.igb.tx_process_limit="-1"
hw.igb.num_queues="0"
hw.igb.enable_aim="1"
net.isr.dispatch="direct"
net.isr.bindthreads="0"
net.isr.maxthreads="4"и перезагрузил роутер.
После чего проблема вроде бы исчезла, по крайней мере даже при DDOS атаке от ~400 до ~800 mb нет потерь не на основном не втором канале, (проверял 3 раза, конечно это не 100% гарантия, но всё же) да канал забили, но сетевая справляется, если не будет вопросов, то топик закрою.
-
…
Что касается моей последней темы - то вы не дали внятного ответа, а влезли все с тем же LEDE.
Так где ложь? Научитесь следить за темой разговора уже наконец.А на кой ляд вы мне тогда плюс в карму за совет с LEDE добавили? Определитесь уже.
Зы. А LEDE не надо вам. Лишнее это. Поломаете еще железо. Потом "претензии" выслушивать. Забудьте.
 -
Оптимизации эти висят в оф. вики пфсенса https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards
-
Оптимизации эти висят в оф. вики пфсенса https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards
Там не всё есть…
-
добавил следующие строки
Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.
-
добавил следующие строки
Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.
Да вы правы, но я как то в это не особо верил, а когда началась очередная DDOS атака просто решил да почему бы и нет, и проверил, если честно не думал что будет такой результат, так сказать от безысходности проверил :)
-
добавил следующие строки
Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.
Да вы правы, но я как то в это не особо верил, а когда началась очередная DDOS атака просто решил да почему бы и нет, и проверил, если честно не думал что будет такой результат, так сказать от безысходности проверил :)
;)
Чтобы не редактировать /boot/loader.conf.local и иметь возможность сохранять свои настройки в бэкапе и восстанавливать\переносить их - лучше добавлять всё вSystem-Advanced-System Tunables
-
@oleg1969:
Несколько ссылок по DDOS
http://salf-net.ru/?p=494
http://pfsensesetup.com/tag/ddos/
https://ok.ru/video/782372406Я всё это читал, только на других сайтах, по поводу Snort, если бы вы прочитали всю ветку то увидели бы что у меня установлена Suricata, но при DDOS атаке она только мешает, по той простой причине что потребляет кучу ресурсов, обычной DDOS атакой на 100 mb вы запросто с помощью Сурикаты загрузите процессор роутера на 100%, и только ухудшите ситуацию, нужно чтобы у вас Суриката устанавливалась на оборудование с несколькими процессорами у которых будет несколько ядер, тогда есть шанс что она не уронит ваш роутер при DDOS.
И так же поскольку Суриката встраивается систему таким образом что весь трафик сначала идёт через неё, то мы даже не можем уменьшить трафик заблокировав скажем некоторые страны.Так же как я и писал, в теории Суриката может работать с CUDA от Nvidia, так что мы могли бы использовать мощности видеокарты для фильтрации, но проблема в том что на FreeBSD нет нормального порта CUDA, а без этого порт Сурикаты для PFsense компилируется без поддержки CUDA.
Так что при DDOS, на большинстве компов Суриката или Снорт только помеха.
-
добавил следующие строки
Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.
Да вы правы, но я как то в это не особо верил, а когда началась очередная DDOS атака просто решил да почему бы и нет, и проверил, если честно не думал что будет такой результат, так сказать от безысходности проверил :)
;)
Чтобы не редактировать /boot/loader.conf.local и иметь возможность сохранять свои настройки в бэкапе и восстанавливать\переносить их - лучше добавлять всё вSystem-Advanced-System Tunables
То есть вы хотите сказать что это полный аналог /boot/loader.conf.local ?
А перезагружать роутер всё равно нужно или нет ? -
Кстати…, возможно я не прав, но всё же не смотря на все настройки лучше на всякий случай второй и так далее каналы подключать на отдельную сетевую карту, так сказать во избежание случайностей.
-
То есть вы хотите сказать что это полный аналог /boot/loader.conf.local ?
Я вносил настройки сетевой карты именно в System Tunables
В приведенной вам ссылке
https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Adding_as_a_System_Tunable
Такой вариант и указан.А перезагружать роутер всё равно нужно или нет ?
перезагрузка не помешает.лучше на всякий случай второй и так далее каналы подключать на отдельную сетевую карту, так сказать во избежание случайностей.
В вашем случае все порты I350T4 обслуживались одним драйвером igb. Отдельная сетевая плата могла обслуживаться другим драйвером, либо не нуждающимся в тюнинге, либо требующим своих настроек. Как вариант для интел - драйвер от igb I350T4 мог бы совпасть с драйвером новой карты.
P.S.
Кстати, в пылу дискуссии все забыли, что вопрос ТС была не о защите его приложения от DDOS в чистом виде, а в обеспечении работоспособности pfSense на резервном канале при высокой нагрузке на основной. -
Там в правилах fw сперва разобраться надо https://forum.pfsense.org/index.php?topic=144597.0
-
То есть вы хотите сказать что это полный аналог /boot/loader.conf.local ?
Я вносил настройки сетевой карты именно в System Tunables
В приведенной вам ссылке
https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Adding_as_a_System_Tunable
Такой вариант и указан.А перезагружать роутер всё равно нужно или нет ?
перезагрузка не помешает.лучше на всякий случай второй и так далее каналы подключать на отдельную сетевую карту, так сказать во избежание случайностей.
В вашем случае все порты I350T4 обслуживались одним драйвером igb. Отдельная сетевая плата могла обслуживаться другим драйвером, либо не нуждающимся в тюнинге, либо требующим своих настроек. Как вариант для интел - драйвер от igb I350T4 мог бы совпасть с драйвером новой карты.
P.S.
Кстати, в пылу дискуссии все забыли, что вопрос ТС была не о защите его приложения от DDOS в чистом виде, а в обеспечении работоспособности pfSense на резервном канале при высокой нагрузке на основной.Так я и написал что практически решил проблему, хотя тестов конечно проведено маловато и требуется ещё проверять различные варианты, как то отдельные сетевые на все каналы и различные варианты тюнинга, просто для полноты картины.
-
Там в правилах fw сперва разобраться надо https://forum.pfsense.org/index.php?topic=144597.0
Вот вы мне ответьте если на меня периодически идёт DDOS атака с повторяющимся шаблоном, банально с одно и того же порта на разные порты на моём компе, не лучше ли будет её блокировать сразу во Float, чем пускать по всей цепочке прохождения трафика и ждать когда в конце этой цепочки PF дропнет ненужное сам, Drop пакета это Drop пакета, единственное что дропать лучше раньше, так чем плохи мои правила во Float которые в большинстве случаев как раз для этого и написаны (хотя конечно не все).
-
Если вы уберете все из float и развесите это на WAN, то с точки зрения затрат на фильтрацию пакетов ничего не изменится, зато картина и вам и нам станет яснее. Floating rules, да, обрабатываются первыми, но если их нет, то переход к обработке обычных правил происходит мгновенно, без потери производительности.
Фактичеки для pf нет никакой разницы, он не знает о том, что в pfSense есть какие-то floating rules -
Если вы уберете все из float и развесите это на WAN, то с точки зрения затрат на фильтрацию пакетов ничего не изменится, зато картина и вам и нам станет яснее. Floating rules, да, обрабатываются первыми, но если их нет, то переход к обработке обычных правил происходит мгновенно, без потери производительности.
Фактичеки для pf нет никакой разницы, он не знает о том, что в pfSense есть какие-то floating rulesЭто понятно, но только то вот настройки которые я предоставил мои и сделаны для меня и как мне удобней, да и вообще насколько я понял господин werter и я спорили не о непонятности правил, он это сюда вообще притащил из другой ветки, и проблема там обсуждается совсем другая и эти правила для решения той проблемы не мешают.
-
Ну, не факт, что не мешают. В то время как обычные правила понятны из скриншота, плавающие имеют столько опций, которых на скриншотах не видно, что понять ничего нельзя.
Посмотреть весь ruleset (в том числе и "магию", добавляемую pfSense) можно через 'pfctl -sn && pfctl -sr' в Diagnostics > Command Prompt
