Przekaż proxy Nginx do zwrotnego serwera proxy

Sep 11 2020

Jestem całkiem nowy w nginx i utknąłem przy obecnej konfiguracji.

Sprawdziłem również ssl - nginx przekierowuje , nginx jako proxy dla aplikacji internetowej , nginx proxy_pass , nginx proxy rewrite i inny post związany z moim pytaniem .

Przejrzałem też kilka innych postów, które w tej chwili mi nie pomogły. Nie przeczytałem wszystkich z około 21500 postów na ten temat nginxi proxy.

Nie udało się również Google skierować mnie do rozwiązania.

Bieżąca konfiguracja to:

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

To jest stara konfiguracja witryny. Zasadniczo potrzebujemy przeprojektowania CMS. Ale rozrósł się z wieloma zależnościami i samodzielnie napisanymi modułami przez co najmniej dwóch programistów (którzy nigdy się nie spotkali). Odpowiednia wymiana zajmie zaledwie rok. W konfiguracji Apache jest też trochę dziwnych rzeczy, więc nie możemy w tej chwili uniknąć używania Apache.

Niestety potrzebujemy przeprojektowania optycznego tak szybko, jak to możliwe.

Dlatego wpadliśmy na pomysł, aby użyć Diazo / XSLT w Nginx do przeprojektowania starej strony internetowej i pokazania naszym asesorom niektórych wyników.

Dlatego próbuję następującej konfiguracji:

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

Oto mój xslt_for_oldsiteplik konfiguracyjny (kontrola pamięci podręcznej wyłączona tylko do debugowania):

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

Jeśli uruchomię przeglądarkę, aby się z nią połączyć http://oldsite.foo wtedy ładuje się:

  • 1 dokument HTML ze starej strony
  • 3 pliki CSS ze starej strony
  • 9 plików JS z oldsite
  • 10 plików graficznych ze starej strony

Ale jeśli użyję przeglądarki, aby uzyskać https://newsite.foo wtedy ładuje się:

  • 1 dokument HTML z newsite
  • tylko 5 plików graficznych ze starej strony (bezpośrednie żądanie z mojej przeglądarki)
  • brakuje wszystkiego innego

Podczas gdy dokument HTML otrzymane z wget https://newsite.foo -o index.htmlma wszystkie łącza do zmodyfikowanych https://newsite.foo(prawidłowo wymianie http://oldsite.fooz https://newsite.foo) pokazuje browser wszystkie linki niezmodyfikowanej: http://oldsite.foozamiast https://newsite.foo.

Otrzymuję następujący nagłówek serwera z 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

I bawił się add_header, proxy_set_headera proxy_redirect. Ja też próbowałem

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

ale żadna z moich zmian nie zmieniła zachowania nginx, do którego przekierowuje żądania GET http://oldsite.foo i pokazuje odpowiedzi tak, jakby pochodziły z https://newsite.foo .

Nie mam odpowiedzi na te pytania:

  • Dlaczego moja przeglądarka ciągle się łączy z http://oldsite.foo? Powinien połączyć się zhttps://newsite.foo .
  • Dlaczego linki w kodzie HTML są różne w wersji z wgetmojej przeglądarki i w mojej przeglądarce?
  • Dlaczego ponad połowa witryny nie dociera do przeglądarki https://newsite.foo?
  • Jak mogę to naprawić?

Czy jest ktoś, kto wskaże mi właściwy kierunek?

Z góry dziękuję. Przynajmniej dziękuję za przeczytanie mojego postu.

Z poważaniem.

Odpowiedzi

choogeoh Sep 15 2020 at 13:11

W międzyczasie znalazłem rozwiązanie.

Apache wysłał dane spakowane gzipem, a sub_filter nie mógł ich obsłużyć (zobacz oficjalną dokumentację: sub_filter ).

Rzeczywiście, próbowałem tego uniknąć, używając, proxy_set_header Accept-Encoding "";ale to nie zadziałało. Powodem jest to, że ta część musi być umieszczona w kontekście lokalizacji .

Stąd prawidłowa konfiguracja dla Ubuntu 20.04 LTS, Nginx 1.14.0 w momencie pisania (2020-09-15) to:

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

Podziękowania dla adrianTNT, który wskazał mi kluczową część (zobacz brakujący szczegół ).