У меня есть три сервера 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)
Если бы у меня возникли проблемы с установлением соединения с размещаемым сайтом, мне было бы чем заняться, но реальный сайт работает отлично. Я просто не хочу, чтобы мои журналы ошибок были заполнены мусором. Любая помощь очень ценится.
Похоже, что балансировщик нагрузки проверяет активные порты ... но не ведет переговоры до конца, как ожидал бы apache ... беспокоиться не о чем ..
Может быть, вы можете изменить механизм зондирования на LB, чтобы получить реальный URL?
В следующих журналах 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 в никуда.