У меня есть три сервера Apache 2.4.6 с балансировкой нагрузки, работающих на свежих установках CentOS 7. Балансировщик нагрузки — Barracuda 340. Я знаю, что он старый, но он более чем способен обрабатывать трафик, и все работает отлично с фактическим сайтом, который они размещают. Все серверы NAT за брандмауэром и не имеют публичных IP-адресов. Однако ровно каждые тридцать секунд я вижу одни и те же 3 ошибки SSL в своих журналах Apache. В следующих журналах sub.example.com представляет собой поддомен, который отличается от того, который фактически размещается на рассматриваемых серверах. А 10.0.0.123 — это IP-адрес балансировщика нагрузки во внутренней сети.
[Fri May 01 06:28:37.315078 2015] [ssl:info] [pid 13873] [client 10.0.0.123:37617] AH01964: Connection to child 5 established (server sub.example.com:443)
[Fri May 01 06:28:37.315175 2015] [ssl:debug] [pid 13873] ssl_engine_io.c(1201): (70014)End of file found: [client 10.0.0.123:37617] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[Fri May 01 06:28:37.315183 2015] [ssl:info] [pid 13873] [client 10.0.0.123:37617] AH01998: Connection closed to child 5 with abortive shutdown (server sub.example.com:443)
Если бы у меня возникли проблемы с установлением соединения с сайтом, на котором я размещаюсь, у меня было бы что-то, на что можно было бы опереться, но сам сайт работает отлично. Я просто не хочу, чтобы мои журналы ошибок были заполнены мусором. Любая помощь будет оценена по достоинству.
решение1
В следующих журналах sub.example.com представляет собой поддомен, который отличается от того, который фактически размещен на рассматриваемых серверах.
[Fri May 01 06:28:37.315175 2015] [ssl:debug] [pid 13873] ssl_engine_io.c(1201): (70014)End of file found: [client 10.0.0.123:37617] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
Проверьте, разрешается ли sub.example.com в тот же IP-адрес, что и example.com (или хотя бы один из IP-адресов балансировщика нагрузки). Если это так, то кто-то может попытаться получить доступ к неправильному сайту, но остановиться во время SSL-рукопожатия, потому что сертификат не соответствует URL-адресу, к которому был получен доступ. Поскольку сообщение повторяется каждые 30 секунд, это может быть своего рода автоматизмом, который мог работать в прошлом и, возможно, перестал работать после изменений на вашем сайте. Он также мог перестать работать после изменений на стороне клиентов, потому что несколько языков сценариев и инструментов теперь проверяют сертификат по умолчанию, а раньше не проверяли.
Чтобы определить происхождение клиента, вам, вероятно, придется заглянуть в файлы журналов или сделать захват пакетов в стратегических местах, чтобы узнать IP-адрес клиента. Если у вас есть доступ к настройкам DNS, вы также можете просто указать sub.example.com в никуда.
решение2
Похоже, что балансировщик нагрузки проверяет активные порты... но не доводит их до конца, как ожидает Apache... не о чем беспокоиться...
Может быть, вы можете изменить механизм проверки LB, чтобы получить какой-то реальный URL?