Ich habe drei lastausgeglichene Apache 2.4.6-Server, die auf Neuinstallationen von CentOS 7 laufen. Der Load Balancer ist ein Barracuda 340. Ich weiß, er ist alt, aber er ist mehr als in der Lage, den Datenverkehr zu bewältigen, und mit der eigentlichen Site, die sie hosten, funktioniert alles prima. Alle Server sind hinter einer Firewall NATed und haben keine öffentlichen IP-Adressen. Allerdings sehe ich genau alle dreißig Sekunden dieselben 3 SSL-Fehler in meinen Apache-Protokollen. In den folgenden Protokollen stellt sub.example.com eine Subdomäne dar, die sich von der unterscheidet, die tatsächlich von den betreffenden Servern gehostet wird. Und 10.0.0.123 ist die IP-Adresse des Load Balancers im internen Netzwerk.
[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)
Wenn ich tatsächlich Probleme hätte, die Verbindung mit der gehosteten Site herzustellen, hätte ich etwas, womit ich weitermachen könnte, aber die eigentliche Site funktioniert einwandfrei. Ich möchte nur nicht, dass meine Fehlerprotokolle mit Müll gefüllt werden. Jede Hilfe ist sehr willkommen.
Antwort1
In den folgenden Protokollen stellt sub.example.com eine Subdomäne dar, die sich von der unterscheidet, die tatsächlich von den betreffenden Servern gehostet wird.
[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?!]
Überprüfen Sie, ob sub.example.com dieselbe IP-Adresse wie example.com hat (oder zumindest eine der IPs des Load Balancers). Wenn dies der Fall ist, versucht jemand möglicherweise, auf die falsche Site zuzugreifen, bricht aber während des SSL-Handshakes ab, weil das Zertifikat nicht mit der aufgerufenen URL übereinstimmt. Da die Meldung alle 30 Sekunden wiederholt wird, handelt es sich möglicherweise um eine Art Automatismus, der in der Vergangenheit möglicherweise funktioniert hat und nach Änderungen an Ihrer Site möglicherweise nicht mehr funktioniert. Es funktioniert möglicherweise auch nach Änderungen auf der Clientseite nicht mehr, da mehrere Skriptsprachen und Tools das Zertifikat jetzt standardmäßig überprüfen und dies in der Vergangenheit nicht getan haben.
Um den Ursprung des Clients zu ermitteln, müssen Sie wahrscheinlich in Protokolldateien nachsehen oder an strategischen Stellen Paketaufzeichnungen durchführen, um die IP des Clients herauszufinden. Wenn Sie Zugriff auf die DNS-Einstellungen haben, können Sie sub.example.com auch einfach ins Nirgendwo verweisen lassen.
Antwort2
Hört sich an, als ob der Load Balancer nach aktiven Ports sucht, aber nicht bis zum Ende verhandelt, wie Apache es erwarten würde. Kein Grund zur Sorge.
Vielleicht können Sie den Prüfmechanismus auf dem LB ändern, um eine echte URL abzurufen?