Il server web serve casualmente vhosts diversi


9

Abbiamo nginx in esecuzione su Ubuntu Trusty. Serve diversi siti Web su HTTPS, in esecuzione su un indirizzo IP.

Casualmente, anche se sembra leggermente correlato al carico di lavoro, a volte le singole richieste vengono visualizzate nel vhost errato. Questo porta a richieste di lustrum.thalia.nuessere servite da thalia.nue viceversa. Questo dà quindi brutte pagine di errore quando gli utenti finiscono improvvisamente su un sito Web diverso. Quando si preme F5, gli utenti finiscono di nuovo sul target originale.

Non sembra correlato al browser o al sistema operativo. È stato confermato che si verifica su Firefox (Linux, Windows, Mac), Edge (Windows) e Chrome (Linux, Windows, Android) e Safari (iOS).

Il problema sembra verificarsi più frequentemente quando il sistema viene caricato, suggerendo una sorta di condizione di gara.

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;
        }
}

Come puoi vedere, stiamo eseguendo diversi pool PHP5-FPM per questi due domini. Questi pool vengono sottoposti a chroot in cartelle diverse ed eseguiti come utenti diversi. Per il resto, la configurazione di PHP-FPM è abbastanza standard.

Abbiamo provato sia nginx 1.4.6-ubuntu3 che nginx 1.8.0-1 + fidato.

Log telemetria

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"

In questa riga puoi vedere che la richiesta per la pagina /committeesviene reindirizzata all'improvviso wp-admin. Sembra che la richiesta sia /committeesstata gestita dal thalia-lustrumpool PHP-fpm ...

File di zona DNS

Non vediamo come questo possa eventualmente essere rilevante, ma ...

;; 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

1
Per favore controlla le tue impostazioni DNS per i domini.
Diamante

1
@bangal sono un record A e un record CNAME, che indicano lo stesso IP. Non vedo come questo sia collegato, però; questi si risolvono bene e sembra improbabile che un problema DNS si manifesti in modo incoerente.
Joost,

2
@ThomWiggers, puoi aggiungere al tuo file di registro il contenuto dell'intestazione Host:http e dell'agente utente? Vedi qui per come: serverfault.com/questions/636790/… . In realtà ho provato a fare alcune richieste ai tuoi siti web ma non sono riuscito a riprodurre il tuo problema. Quale client stai usando per riprodurre questo?
Fredi,

3
Il fatto è che ho appena ricevuto "Contenuto di terze parti non installato" o qualcosa del genere perché ci stai lavorando o sono finito in un altro pool PHP o qualcosa del genere (attivando lo stesso bug)? Ho anche avuto un breve errore su config.phpnon trovato.
Halfgaar,

2
@kasperd serverfault.com/questions/737349/… . Sembra influenzare solo gli script PHP.
Thom Wiggers,

Risposte:


4

Dopo ore di debug di questo problema, siamo finalmente riusciti a rintracciarlo alla causa. Sembra che la causa non lo sia nginx, ma PHP-fpm. Stiamo eseguendo la php5-fpmversione 5.5.9-1ubuntu4.14. Sembra che quando si biforcano nuovi lavoratori, a volte qualcosa va storto e gli operai eseguono (in parte?) Il codice di diversi lavoratori.

La nostra soluzione era copiare /etc/php5/fpm/php5-fpm.confsu diverse copie con le proprie pool.dcartelle, quindi copiarle /etc/init.d/php5-fpmper avviarle con il nuovo file di configurazione (creando anche i file /etc/init/). Ciò significa che ora abbiamo un php5-fpmgestore dei processi per pool. Avere chroot e socket separati non sembra mantenere le cose abbastanza separate.


Si noti che al momento non è chiaro se si tratta di un problema nella nostra configurazione o in (questa versione di) php5-fpm, sebbene quest'ultimo non sembri probabile data la mancanza di report simili. Se finiamo per trovare il motivo per cui si verifica questo problema, questa risposta verrà aggiornata.
Joost,

1

Sto affrontando lo stesso problema ma su Debian con Apache2.4.25 e PHP7.1-FPM. Ecco un modo per separare i processi https://ma.ttias.be/a-better-way-to-run-php-fpm/

Per quelli come me che potrebbero trovare questa soluzione troppo pesante per i piccoli siti Web, aggiungere php_admin_value[opcache.revalidate_freq] = 0alla fine del file di configurazione del pool php-fpm. Tuttavia, ciò potrebbe avere un grave impatto sulle prestazioni ...

Ecco la segnalazione ufficiale dei bug: https://bugs.php.net/bug.php?id=67141


0

Nginx supporta SNI? È possibile eseguire nginx -V e dovrebbe essere abilitato qualcosa come il supporto TLS SNI. In caso contrario, potrebbe essere il motivo per cui il nome host viene inviato dopo l'handshake e suppongo che tu abbia un certificato con caratteri jolly per * .thalia.nu


Ovviamente, senza SNI questo andrebbe storto al 100% delle volte anziché molto occasionalmente. (e ho anche controllato questo, è sicuramente abilitato)
Thom Wiggers,

FWIW, tieni presente che non forniamo un certificato con caratteri jolly, ma utilizziamo certificati individuali per i sottodomini separati. Questo è incluso nella configurazione elencata nella domanda.
Joost

.. anche se il certificato lustrum.thalia.nu è valido anche per Thalia.nu
Thom Wiggers,

Puoi provare ad aggiungere il parametro includeSubDomains in questo modo? add_header Sicurezza di trasporto rigorosa "max-age = 63072000; includeSubDomains; precarico";
Mugurel,

@ThomWiggers Se il certificato è valido per più domini è possibile supportare più domini su un singolo IP senza la necessità di SNI.
Kasperd,

-1

Sembra che il certificato non sia corretto: firefox mi sta dicendo che è stato rilasciato per www.thalia.nu, non thalia.nu.

Questo è IMHO che sta causando problemi. Prova con un altro certificato o prova ad attivare le connessioni HTTP senza SSL.


Non possiamo riprodurlo. Il certificato è stato pubblicato su www.thalia.nue thalia.nuinclude entrambi i domini, con e senza www. Quale versione di Firefox stai usando e su quale piattaforma?
Joost
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.