У нас возникает проблема с отказом в подключении, когда пользователи нашего веб-сайта пытаются его открыть. Эта проблема возникает случайным образом, примерно один или два раза в месяц, и проблема продолжается несколько часов. Также, когда это происходит, почти все соединения отклоняются из-за ошибки отказа в соединении. но пока есть удачные связи.
Пока возникает эта проблема, доступно много ОЗУ (более ~ 60%) и ЦП (более ~ 70%). Также мы проверили сетевой брандмауэр, и очевидно, что трафик проходит через сетевой брандмауэр без проблем, и проблема возникает на уровне сервера. И мы даже не можем открыть веб-сайт, выполняя удаленный рабочий стол и пытаясь открыть его локально.
Мы проверили проблему исчерпания порта, и похоже, что проблема не в этом. Количество SYN-пакетов велико, но похоже на другие дни, когда все в порядке.
Это дневная сводка журнала HTTPERR:
s-reason COUNT(ALL *)
Timer_ConnectionIdle 462040
Timer_MinBytesPerSecond 27555
Request_Cancelled 1757
Timer_EntityBody 428
Forbidden 247
URL 130
Hostname 117
BadRequest 102
Connection_Dropped 96
Client_Reset 88
Connection_Dropped_List_Full 40
Verb 10
Header 7
Connection_Abandoned_By_ReqQueue 1
Любая помощь действительно приветствуется, чтобы найти причину, по которой мы получаем отказ в соединении при попытке открыть веб-сайт, размещенный на этом сервере.
Вы работаете в виртуальной среде или на физической машине? (Отредактировал, просто перечитал и увидел ESXI 6. Итак, виртуальный.)
У вас есть виртуальная машина VMware, вы используете стандартную сетевую карту для установки или конкретную сетевую карту поставщика виртуальных машин? (например: Intel против VMWare)
У нас есть аналогичная проблема, но она гораздо менее актуальна, когда возникает. (Наш раскрывается, когда автоматический скрипт запускается для проверки состояния 30 сайтов вверх / вниз, но влияет только на полдюжины LWP.)
(Извините, пока не могу использовать комментарии, у меня нет представителя)
Согласно эта ссылка TechNet Мохаммад обнаружил, что SYN Attack Protect по умолчанию включен в> = Vista. Это то, что я нашел вчера, но в отличие от того, что я читал вчера, RegEdits в Редактировать 1 очевидно, не делают его более агрессивным или активным.
Я воспользовался временным подходом к блокировке IP-адресов на брандмауэре, чтобы посмотреть, что произойдет. Лишние соединения SYN_RECEIVED разрываются, а затем, в конечном итоге, снова повышаются на другом IP (как и следовало ожидать).
Если вам не нужно читать все комментарии ниже, похоже, что это движется в направлении SYN-атаки (для нас обоих).
В настоящее время я пробую следующие изменения в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ на сервере разработки для тестирования:
SynAttackProtect: https://technet.microsoft.com/en-us/library/cc938202.aspx TcpMaxConnectResponseRetransmissions: https://technet.microsoft.com/en-us/library/cc938208.aspx TcpTimedWaitDelay: https://technet.microsoft.com/en-us/library/cc938217.aspx TcpMaxHalfOpenRetried: https://technet.microsoft.com/en-us/library/cc938213.aspx TcpMaxPortsExhausted: https://technet.microsoft.com/en-us/library/cc938214.aspx TcpTimedWaitDelay: https://technet.microsoft.com/en-us/library/cc938217.aspx
Примерно так, как описано здесь: https://alnitech.com/news/how-to-protect-your-windows-server-from-syn-flood/
Полезное примечание - некоторые варианты использования портов TCP / UDP. Особенно, если вы планируете увеличить количество портов в эфемерном диапазоне. (например: netsh int ipv4 set dynamicportrange tcp start=45536 num=20000) https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers