El servidor web sirve aleatoriamente diferentes vhosts

9

Tenemos nginx ejecutándose en Ubuntu Trusty. Sirve a varios sitios web a través de https, ejecutándose en una dirección IP.

Aleatoriamente, aunque parece estar ligeramente relacionado con la carga de trabajo, a veces las solicitudes individuales aparecen en el vhost incorrecto. Esto lleva a solicitudes de lustrum.thalia.nuser atendido por thalia.nuy viceversa. Esto genera páginas de error desagradables ya que los usuarios de repente terminan en un sitio web diferente. Cuando presiona F5, los usuarios terminan nuevamente en el objetivo original.

No parece estar relacionado con el navegador o el sistema operativo. Se ha confirmado que ocurre en Firefox (Linux, Windows, Mac), Edge (Windows) y Chrome (Linux, Windows, Android) y Safari (iOS).

El problema parece ocurrir con más frecuencia cuando el sistema se pone bajo carga, lo que sugiere algún tipo de condición de carrera.

lustrum.thalia.nu

server {
        server_name lustrum.thalia.nu;

        listen 443 ssl;

        ssl on;
        ssl_certificate /etc/nginx/certs/lustrum.thalia.nu.crt;
        ssl_certificate_key /etc/nginx/certs/lustrum.thalia.nu.key;

        add_header Strict-Transport-Security "max-age=63072000; preload";

        root /var/www/thalia-lustrum/public_html;

        location / {
                index index.php;
                try_files $uri $uri/ /index.php?$args;
        }

        # Add trailing slash to */wp-admin requests.
        rewrite /wp-admin$ $scheme://$host$uri/ permanent;

        # Pass all .php files onto a php-fpm/php-fcgi server.
        location ~ [^/]\.php(/|$) {
                include         /etc/nginx/fastcgi_params;

                fastcgi_split_path_info ^(.+?\.php)(/.*)$;

                if (!-f $document_root$fastcgi_script_name) {
                        return 404;
                }

                fastcgi_pass    unix:/var/run/php5-fpm-thalia-lustrum.sock;
                fastcgi_index   index.php;
                fastcgi_param   SCRIPT_FILENAME  /public_html$fastcgi_script_name;
        }
}

thalia.nu

server {
        server_name thalia.nu;    
        listen 443 ssl;

        ssl on;
        ssl_certificate /etc/nginx/certs/www.thalia.nu.crt;
        ssl_certificate_key /etc/nginx/certs/www.thalia.nu.key;

        add_header Strict-Transport-Security "max-age=63072000; preload";

        root /var/www/thalia/public_html;

        location / {
                try_files $uri $uri/ /index.php/$request_uri;
                index index.php index.html index.htm;
        }

        location ~ \.php($|/) {
                include         /etc/nginx/fastcgi_params;
                set  $script     $uri;
                set  $path_info  "";
                if ($uri ~ "^(.+\.php)(/.+)") {
                                set  $script     $1;
                                set  $path_info  $2;
                }
                fastcgi_read_timeout    120;
                fastcgi_pass    unix:/var/run/php5-fpm-thalia-www.sock;
                fastcgi_index   index.php;
                fastcgi_param   SCRIPT_FILENAME  /public_html$fastcgi_script_name;
        }
}

Como puede ver, estamos ejecutando diferentes grupos PHP5-FPM para estos dos dominios. Estos grupos se agrupan en diferentes carpetas y se ejecutan como diferentes usuarios. La configuración de PHP-FPM es, por lo demás, bastante estándar.

Hemos probado nginx 1.4.6-ubuntu3 y nginx 1.8.0-1 + trusty.

Telemetría de registro

266.266.266.266 - - [25/Nov/2015:09:24:40 +0100] "GET /committees/175 HTTP/1.1" 302 5 "https://thalia.nu/committees" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0" Host: "thalia.nu" Location: "https://thalia.nu/index.php//committees/wp-admin/setup-config.php"

En esta línea puede ver que la solicitud de la página de /committeesrepente se redirige a wp-admin. Esto parece que la solicitud de /committeesfue manejada por el grupo thalia-lustrumPHP-fpm ...

Archivo de zona DNS

No vemos cómo esto puede ser relevante, pero ...

;; MX Records
thalia.nu.    300    IN    MX    20    relay.transip.nl.
thalia.nu.    300    IN    MX    10    ivo.thalia.nu.

;; TXT Records
thalia.nu.    300    IN    TXT    "v=spf1 a mx a:mulgore.hexon-is.nl a:moonray.hexon-is.nl a:fred.thalia.nu a:ivo.thalia.nu ~all"

;; SPF Records (Sender Policy Framework)
thalia.nu.    300    IN    SPF    "v=spf1 a mx a:mulgore.hexon-is.nl a:moonray.hexon-is.nl a:fred.thalia.nu a:ivo.thalia.nu ~all"

;; CNAME Records
lustrum.thalia.nu.    300    IN    CNAME    thalia.nu.

;; A Records (IPv4 addresses)
thalia.nu.    300    IN    A    131.174.31.8
www.thalia.nu.    300    IN    A    131.174.31.8
ivo.thalia.nu.    300    IN    A    131.174.31.8
nginx ssl virtualhost php-fpm tls Thom Wiggers
fuente
1
Plesse verifique su configuración de DNS para los dominios.
Diamante
1
@bangal son una A y un registro CNAME, que apuntan a la misma IP. Sin embargo, no veo cómo se relaciona esto; estos se resuelven bien, y parece poco probable que un problema de DNS se manifieste de manera tan inconsistente.
Joost
2
@ThomWiggers, ¿puede agregar a su archivo de registro el contenido del Host:encabezado http y el agente de usuario? Vea aquí cómo: serverfault.com/questions/636790/… . En realidad intenté hacer algunas solicitudes a sus sitios web pero no pude reproducir su problema. ¿Qué cliente estás usando para reproducir esto?
Fredi
3
¿Es el hecho de que acabo de recibir "Contenido de terceros no instalado" o algo porque estás trabajando en él, o acabé en otro grupo de PHP o algo así (desencadenando el mismo error)? También recibí un breve error sobre config.phpno encontrado.
Halfgaar
2
@kasperd serverfault.com/questions/737349/… . Parece que solo afecta a los scripts PHP.
Thom Wiggers

Respuestas:

4

Después de horas de depuración de este problema, finalmente hemos podido rastrearlo hasta la causa. Parece que la causa no lo es nginx, pero PHP-fpm. Estamos ejecutando la php5-fpmversión 5.5.9-1ubuntu4.14. Parece que cuando se bifurcan nuevos trabajadores, a veces algo sale mal y los trabajadores corren (¿parte?) Del código de diferentes trabajadores.

Nuestra solución fue copiar /etc/php5/fpm/php5-fpm.confen diferentes copias con sus propias pool.dcarpetas, luego copiar /etc/init.d/php5-fpmpara iniciar con el nuevo archivo de configuración (también creando archivos /etc/init/). Esto significa que ahora tenemos un php5-fpmadministrador de procesos por grupo. Tener chroots y zócalos separados no parece mantener las cosas lo suficientemente separadas.

Thom Wiggers
fuente
Tenga en cuenta que actualmente no está claro si este es un problema en nuestra configuración o en (esta versión de) php5-fpm, aunque esto último no parece probable dada la falta de informes similares. Si terminamos encontrando la razón por la cual ocurre este problema, esta respuesta se actualizará.
Joost
1

Estoy enfrentando el mismo problema pero en Debian con Apache2.4.25 y PHP7.1-FPM. Aquí hay una manera de separar procesos https://ma.ttias.be/a-better-way-to-run-php-fpm/

Para aquellos como yo que podrían encontrar esta solución demasiado pesada para sitios web pequeños, agregue php_admin_value[opcache.revalidate_freq] = 0al final del archivo de configuración del grupo php-fpm. Sin embargo, eso puede tener un grave impacto en las actuaciones ...

Aquí está el informe oficial de errores: https://bugs.php.net/bug.php?id=67141

Nic0tiN
fuente
0

¿Nginx es compatible con SNI? Puede ejecutar nginx -V y debería ver algo como el soporte SNI TLS habilitado. Si no lo hace, puede ser por eso porque el nombre de host se envía después del apretón de manos y supongo que tiene un certificado comodín para * .thalia.nu

Mugurel
fuente
Por supuesto que sí, sin SNI esto saldría mal el 100% del tiempo en lugar de muy ocasionalmente. (y también he comprobado esto, definitivamente está habilitado)
Thom Wiggers
FWIW, tenga en cuenta que no servimos un certificado comodín, sino que utilizamos certificados individuales para los subdominios separados. Esto se incluye en la configuración enumerada en la pregunta.
Joost
..aunque el certificado lustrum.thalia.nu también es válido para Thalia.nu
Thom Wiggers el
¿Puedes intentar agregar el parámetro includeSubDomains como este? add_header Strict-Transport-Security "max-age = 63072000; includeSubDomains; preload";
Mugurel
@ThomWiggers Si el certificado es válido para múltiples dominios, es posible admitir múltiples dominios en una sola IP sin la necesidad de SNI.
kasperd
-1

Parece que el certificado no es correcto: firefox me dice que se emite para www.thalia.nu, no thalia.nu.

Esto es en mi humilde opinión lo que está causando problemas. Intente con otro certificado o intente activar las conexiones HTTP sin SSL.

Xavier Nicollet
fuente
No podemos reproducir eso. El certificado se sirve en www.thalia.nue thalia.nuincluye ambos dominios, con y sin www. ¿Qué versión de Firefox estás usando y en qué plataforma?
Joost