А, ну вот наконец-то разобрались, ваш сервер стучался куда-то на UDP/123, и на него нажаловались.
Тогда да, тщательно сканировать, искать следы, которые не подчистили.
P.S. Странно, 123-ий порт - это NTP, в него IMHO стучаться - просто бессмысленно.
Так блокировали группу клиентов, или сам сервер?
Если клиентов - то как может быть "разблочен сервер, временно".
А постоянно он всегда заблочен что-ли?
И ещё, таких сканирований в сутки случается вагон и маленькая тележка.
Если этот порт у вас не открыт, на нём ничего нет - так это вообще не атака, а стук лбом в стену, не стоит обращать внимания. Конечно если их +100500 МИЛЛИОНОВ в течении 60 минут - тогда да, DDoS.
Ну и что, что чужой роутер считается своим. Трафик всё равно шёл (бы) сначала через .0.2 как default gateway. А прямое общение между .0.1 и собственной подсетью можно (было бы) блокировать firewall-ом.
Ну да ладно, другая подсеть - и проще, и безопаснее, и не поспоришь.
P.S. А 192.189.0.128/25 же!? Правда всего 126 адресов...
Александр Карабанов, в 03 часа ночи? Скоре уж это много-много-гигабайтные бэкапы канал загребают.
TheBigBear, прям вот "Roselecom"? За что-ж вы так? И кстати, а где на графике пик MAX в 100 Mbps?
On-topic: конечно справится, там же 5 гигабитных Ethernet портов. Я самолично выдавливал 1.94 гига на 2-х агрегированных портах (цифры были в iperf3). Скорее не справятся остальные роутеры/хабы, которыми будут разводиться эти 150 пользователей...
Смотрите прямо в DevTool браузера, с каким содержимым передаётся запрос. И кажется в 'body' не хватает ещё кавычек одиночных, что бы строка стала действительно строкой. Или JSON.stringify(...).
Я бы скорее верил своим глазам, чем заверениям хостера, что вам точно-точно выделен железный хост, с которого вы никуда-никуда не переезжали последнюю сотню лет... Терзайте этим вопросом техпод, однако.
Или обработчик формы их всё-таки использует, и тогда исправляйте логику в том месте, где обрабатываются статичные формы. Для статичных форм TOTAL_FORMS ведь не нужны, так?
На сколько я предугадываю вообще не показанный окончательный HTML/JS-код страницы с формами, formNum прекрасно инициируется/контролируется БЕЗ использования totalForms и этих скрытых полей. Имхо их можно просто стереть из кода...
Тоесть поля добавляются корректно, у них уникальные идентификаторы?
Тогда проверяйте в браузере, при submit-е формы эти поля передаются в запросе к серверу?
Если передаются - терзайте скрипт, принимающий данные, debug-те то, что ему прилетело в запросе...
Хммм, а у вас идентификаторы полей генерируются именно в виде "form-0-common_name" и т.д.?
Потому что скрипт нацелен именно на такие идентификаторы, именно их он будет инкрементировать.
Нужно смотреть в браузере, как поля создаются, инкрементируются их id или нет...
А у самого 10.128.0.4 дефортный шлюз случаем не 10.128.0.1 ли?
Ну и стоит проверить содержимое `ip rules`, на всякий случай.
И посмотреть tcpdump на обоих шлюзах, что-бы точно удостовериться именно в таком пути трафика.
Ну создавайте /tmp/php_12.34.56.78.lock файл, в названии которого 12.34.56.78 - это IP-адрес из $_SERVER['REMOTE_ADDR']. Есть такой файл - выдаём ошибку, нет такого файла - создаём и сразу работаем, по окончании - стираем. Всё.
P.S. И не забываем регулярно чистить директорию от старых неудачно сохранившихся файлов.
Тогда да, тщательно сканировать, искать следы, которые не подчистили.
P.S. Странно, 123-ий порт - это NTP, в него IMHO стучаться - просто бессмысленно.