Webserver serve aleatoriamente diferentes vhosts

9

Temos o nginx em execução no Ubuntu Trusty. Ele serve vários sites sobre https, rodando em um endereço IP.

Aleatoriamente, embora pareça um pouco relacionado à carga de trabalho, às vezes solicitações únicas aparecem no vhost errado. Isso leva a solicitações em lustrum.thalia.nu sendo veiculado por thalia.nu e vice-versa. Isso gera páginas de erro desagradáveis, pois os usuários acabam subitamente em um site diferente. Quando você pressiona F5 , os usuários acabam voltando ao alvo original.

Não parece relacionado ao navegador ou sistema operacional. Está confirmado para acontecer no Firefox (Linux, Windows, Mac), Edge (Windows) e Chrome (Linux, Windows, Android) e Safari (iOS).

O problema parece ocorrer com mais freqüência quando o sistema é colocado sob carga, sugerindo algum tipo de condição de corrida.

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 você pode ver, estamos executando diferentes pools PHP5-FPM para esses dois domínios. Esses pools são chrootados para diferentes pastas e executados como usuários diferentes. A configuração do PHP-FPM é de outra forma bastante padrão, tanto quanto eu posso dizer.

Nós testamos o nginx 1.4.6-ubuntu3 e o nginx 1.8.0-1 + trusty.

Telemetria 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"

Nesta linha, você pode ver que a solicitação da página /committees é redirecionada repentinamente para wp-admin . Isso parece que a solicitação para /committees foi manipulada pelo pool thalia-lustrum PHP-fpm ...

arquivo de zona DNS

Não vemos como isso pode ser relevante, mas ...

;; 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
    
por Thom Wiggers 18.11.2015 / 20:31

4 respostas

4

Após horas de depuração do problema, finalmente conseguimos rastreá-lo para a causa. Parece que a causa não é nginx , mas PHP-fpm. Estamos a executar php5-fpm version 5.5.9-1ubuntu4.14 . Parece que quando se forjam novos trabalhadores, algo às vezes dá errado e os trabalhadores correm (parte?) Do código de diferentes trabalhadores.

Nossa solução foi copiar /etc/php5/fpm/php5-fpm.conf para cópias diferentes com suas próprias pastas pool.d , depois copiar /etc/init.d/php5-fpm para iniciar com o novo arquivo de configuração (também criando arquivos em /etc/init/ ). Isso significa que agora temos um gerenciador de processo php5-fpm por pool. Ter chroots e soquetes separados não parece manter as coisas separadas o suficiente.

    
por 25.11.2015 / 22:16
1

Estou enfrentando o mesmo problema, mas no Debian com Apache2.4.25 e PHP7.1-FPM. Aqui está uma maneira de separar processos link

Para aqueles que, como eu, podem achar essa solução muito pesada para sites pequenos, adicione php_admin_value[opcache.revalidate_freq] = 0 no final do arquivo de configuração do pool php-fpm. No entanto, isso pode ter um impacto sério nos desempenhos ...

Aqui está o relatório de erros oficial: link

    
por 20.10.2017 / 17:14
0

O Nginx suporta SNI? Você pode executar o nginx -V e deve ver algo como o suporte a TLS SNI ativado. Se você não, isso pode ser porque o nome do host é enviado após o handshake e eu estou supondo que você tenha um certificado curinga para * .thalia.nu

    
por 24.11.2015 / 11:58
-1

Parece que o certificado não está certo: o firefox está me dizendo que ele foi enviado para www.thalia.nu, não para thalia.nu.

Isto é IMHO o que está causando problemas. Tente com outro certificado ou tente ativar conexões HTTP sem SSL.

    
por 25.11.2015 / 20:02