Passaggio del proxy Nginx al proxy inverso

Sep 11 2020

Sono abbastanza nuovo su nginx e sono bloccato con la configurazione corrente.

Ho anche controllato ssl - nginx reindirizza , nginx come proxy per app web , nginx proxy_pass , nginx proxy rewrite e un altro post relativo alla mia domanda .

Ho anche esaminato altri post che non mi hanno aiutato in questo momento. Non ho letto tutti i circa 21500 post sugli argomenti nginxe proxy.

Anche Google non è riuscito a indirizzarmi alla soluzione.

La configurazione attuale è:

[CMS (Plone in LAN)]<--->[Reverse-Proxy (Apache / http://oldsite.foo)]

Questa è la vecchia configurazione del sito. Fondamentalmente abbiamo bisogno di una riprogettazione del CMS. Ma è cresciuto con molte dipendenze e moduli autoprodotti da almeno due sviluppatori (che non si sono mai incontrati). Sarà un compito solo per un anno sostituirlo correttamente. Ci sono anche alcune cose strane nella configurazione di Apache, quindi non possiamo evitare di usare Apache al momento.

Purtroppo abbiamo bisogno di una riprogettazione ottica appena possibile.

Quindi abbiamo avuto l'idea di utilizzare Diazo / XSLT in Nginx per riprogettare il vecchio sito Web e mostrare ai nostri valutatori alcuni risultati.

Quindi provo la seguente configurazione:

[Plone]<--->[Apache]<--->[Proxy (XSLT in Nginx / https://newsite.foo)]

Ecco il mio xslt_for_oldsitefile di configurazione (Cache-Control disattivato solo per il debug):

add_header Cache-Control no-cache;

server {
  server_name newsite.foo;
  server_tokens off;

  listen b.b.b.b:80;

  return 301 https://$server_name$request_uri;

  access_log /var/log/nginx/newsite.port80.access.log;
  error_log /var/log/nginx/newsite.port80.error.log;
}

server {
  server_name newsite.foo;
  server_tokens off;

  listen b.b.b.b:443 ssl;

  access_log /var/log/nginx/newsite.port443.access.log;
  error_log /var/log/nginx/newsite.port443.error.log;

  ssl_certificate /etc/ssl/certs/nginx.crt;
  ssl_certificate_key /etc/ssl/private/nginx.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
  ssl_ciphers HIGH:!aNULL:!MD5:!ADH:!AECDH;
  ssl_session_cache shared:SSL:5m;

  proxy_http_version 1.1;

  #proxy_set_header X-Forwarded-Host $host:$server_port;
  #proxy_set_header X-Forwarded-Server $host; #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#  proxy_set_header Connection "";
#  proxy_ignore_headers Expires;

#  proxy_set_header X-Real-IP $remote_addr; # proxy_set_header X-forwarded-host $host;

  sub_filter_types *;
  sub_filter_once off;
  sub_filter "http://oldsite.foo" "https://newsite.foo";

  location / {
    proxy_pass http://oldsite.foo/;
    proxy_redirect off;
    #proxy_redirect http://oldsite.foo/ https://newsite.foo/;
    proxy_set_header Host $host;
  }
}

Se avvio il browser per connettermi a http://oldsite.foo quindi carica:

  • 1 documento HTML da oldsite
  • 3 file CSS da oldsite
  • 9 file JS da oldsite
  • 10 file grafici da oldsite

Ma se uso il mio browser per ottenere https://newsite.foo quindi carica:

  • 1 documento HTML da newsite
  • solo 5 file grafici dal vecchio sito (richiesta diretta dal mio browser)
  • manca tutto il resto

Mentre il documento HTML ricevuto con wget https://newsite.foo -o index.htmlha tutti i collegamenti modificati https://newsite.foo(sostituiti correttamente http://oldsite.foocon https://newsite.foo), il browser mostra tutti i collegamenti non modificati: http://oldsite.fooinvece di https://newsite.foo.

Ottengo la seguente intestazione del server con curl -I https://newsite.foo:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 11 Sep 2020 10:28:15 GMT
Content-Type: text/html
Connection: keep-alive
Accept-Ranges: none
Accept-Ranges: bytes
X-Varnish: 1216306480
Age: 0
Via: 1.1 varnish
Set-Cookie: I18N_LANGUAGE="de"; Path=/
Via: 1.1 oldsite.foo
Vary: Accept-Encoding
Cache-Control: no-cache

Ho giocato con i add_header, proxy_set_headere proxy_redirect. Ho provato anche io

location ~* .* {
  proxy_pass http://oldsite.foo$request_uri;
  proxy_redirect off;
  proxy_set_header Host $host;
}

ma nessuna delle mie modifiche ha cambiato il comportamento di nginx a cui reindirizza le richieste GET http://oldsite.foo e mostra le risposte come se provenissero da https://newsite.foo .

Non ho risposta a queste domande:

  • Perché il mio browser continua a connettersi a http://oldsite.foo? Dovrebbe connettersi ahttps://newsite.foo .
  • Perché i collegamenti nell'HTML sono diversi tra la versione da wgete il mio browser?
  • Perché oltre la metà del sito Web non raggiunge il browser https://newsite.foo?
  • Come posso risolvere questo problema?

C'è qualcuno là fuori che può indicarmi la giusta direzione?

Grazie in anticipo. Almeno grazie per aver letto il mio post.

I migliori saluti.

Risposte

choogeoh Sep 15 2020 at 13:11

Nel frattempo ho trovato la soluzione.

Apache ha inviato i dati compressi con gzip e sub_filter non è stato in grado di gestirli (vedere la documentazione ufficiale: sub_filter ).

In effetti ho cercato di evitarlo usando proxy_set_header Accept-Encoding "";ma non ha funzionato. Il motivo è che questa parte deve essere impostata nel contesto della posizione .

Quindi la configurazione corretta per Ubuntu 20.04 LTS, Nginx 1.14.0 al momento della stesura (2020-09-15) è:

...
server {
  server_name newsite.foo;
  server_tokens off;
  
  listen b.b.b.b:443 ssl;

  access_log /var/log/nginx/newsite.port443.access.log;
  error_log /var/log/nginx/newsite.port443.error.log;

  ssl_certificate /etc/ssl/certs/nginx.crt;
  ssl_certificate_key /etc/ssl/private/nginx.key;

  # Double check and modify this part BEFORE using in production:
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
  ssl_ciphers HIGH:!aNULL:!MD5:!ADH:!AECDH;
  ssl_session_cache shared:SSL:5m;

location / {
  proxy_http_version 1.1;
  proxy_set_header Accept-Encoding "";  # MUST be written HERE in this context!
  proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr;
  proxy_pass http://oldsite.foo;
  proxy_redirect off;
  sub_filter_types text/html text/css text/javascript;  # If unsure you may use '*'
  sub_filter_once off;
  sub_filter http://oldsite.foo https://newsite.foo;
}
...

Grazie ad adrianTNT che mi ha segnalato la parte cruciale (vedi dettaglio mancante ).