Reverse-Proxy: Timeouts / Funktionsfehler

greystone

greystone

Active Member
Hi,

ich habe hier einen Reverse-Proxy und ich bekomme bei manchen Anwendungen dort Timeouts und weiß nicht woran das liegen könnte. Grundsätzlich funktionieren manche Anwendungen. Andere nicht. Das war schon immer so. Bei dieser Anwendung(VMware View) habe ich nur Timeouts(ca. 120 Sekunden) und dann geht es. Eine andere Anwendung(pfSense) geht gar nicht mit dem gleichen Symptom.

Wenn ich den Reverse-Proxy weglasse und direkt ein DNAT an der Firewall zum VMWare View Server einrichte geht alles ohne Probleme.

Was könnte das sein?

Vermutung: Ich habe etwas typisches, was man beim ReverseProxy Betrieb beachten muss noch nicht kapiert, bzw. bin mir dessen nicht bewusst und dementsprechend nicht konfiguriert.

Das Setup ist:

Browser --> Internet --> Firewall --> Reverse-Proxy --> Anwendung

Reverse-Proxy ist ein nginx via Docker. Das verwendete Docker-Image ist nginx/alpine:current (gerade eben aktualisiert). Das sind die installierten nginx-Pakete unter alpine:

Code: 
nginx-1.23.2-r1 x86_64 {nginx} (2-clause BSD-like license) [installed]
nginx-module-xslt-1.23.2-r1 x86_64 {nginx-module-xslt} (2-clause BSD-like license) [installed]
nginx-module-image-filter-1.23.2-r1 x86_64 {nginx-module-image-filter} (2-clause BSD-like license) [installed]
nginx-module-njs-1.23.2.0.7.7-r1 x86_64 {nginx-module-njs} (2-clause BSD-like license) [installed]
nginx-module-geoip-1.23.2-r1 x86_64 {nginx-module-geoip} (2-clause BSD-like license) [installed]

Hier ist die NGINX-Config von nginx -T . Unwichtige Teile(Andere VHosts, mime-types) sind nicht enthalten.

https://debianforum.de/forum/pastebin/?mode=view&s=41822

Hier ist das debug log:

Code: 
2022/11/15 17:04:56 [error] 19#19: *5 upstream timed out (110: Operation timed out) while reading upstream, client: 0.0.0.174, server: view.mydomain.de, request:
"GET /portal/info.jsp?_=1668531836588 HTTP/1.1", upstream: "https://0.0.0.30:443/portal/info.jsp?_=1668531836588", host: "view.mydomain.de", referrer: "https://vie
w.mydomain.de/portal/webclient/index.html"
2022/11/15 17:06:20 [error] 19#19: *31 upstream timed out (110: Operation timed out) while reading upstream, client: 0.0.0.0.174, server: view.mydomain.de, request:
 "GET /portal/info.jsp?_=1668531920845 HTTP/1.1", upstream: "https://0.0.0.30:443/portal/info.jsp?_=1668531920845", host: "view.mydomain.de", referrer: "https://vi
ew.mydomain.de/portal/webclient/index.html"
2022/11/15 17:06:26 [info] 19#19: *96 client closed connection while waiting for request, client: 0.0.0.174, server: 0.0.0.0:443

Zu den IP-Adressen:

0.0.0.174 Das ist die maskierte statische öffentliche IP von meinem Client(Ausgehend via VPN)
0.0.0.30 Das ist die maskierte interne IP im Ziel-LAN des VMWare View Servers

Nachtrag

Ich habe jetzt nochmal mit tcpdump geschaut und ich sehe, dass der Request brav am Reverse-Proxy ankommt und vom Reverse-Proxy weitergeleitet wird. Aber das VMware View antwortet mal so überhaupt nicht. Also nicht über den Reverse-Proxy. Die Webseite wird am Client angezeigt(Browser-Cache gelöscht). Ist da im Protokoll vielleicht die echte Public IP von meinem Client drin und die Antwort geht unter Umgehung des Proxies direkt über die Firewall nach draußen?

Der tcpdump zeigt keine Pakete die als Antwort vom VMWare-Backend zurück an den Reverse-Proxy gehen. Es gehen auch keine Pakete über die Firewall vom VMWare-Backend zurück an meine Client IP.

Den NGINX-Cache habe ich mal ausgeschaltet(expire -1 ; ).
 
Last edited:
Ich habe jetzt noch ein paar Beiträge gefunden, die folgende Zusatzkonfig für NGINX erwähnen im Zusammenhang mit VMWare View:

In der "Location"

Code: 
                proxy_set_header            Host            $http_host;
                proxy_set_header            X-Real-IP       $remote_addr;
                proxy_set_header            X-Forwared-For  $proxy_add_x_forwarded_for;
                proxy_redirect              off;
                proxy_http_version          1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $http_connection;
                client_max_body_size        10m;
                client_body_buffer_size     128k;
                proxy_connect_timeout       90;
                proxy_send_timeout          90;
                proxy_read_timeout          90;
                proxy_buffer_size           16k;
                proxy_buffers               32  16k;
                proxy_busy_buffers_size     64k;

Und im VHost(="server")-Abschnitt für den speziellen VHost:

Code: 
        client_header_buffer_size   64k;

Damit ist der Timeout weg und es funktioniert sofort. Wesentlich ist die Direktive proxy_http_version. Mache ich die weg, sind die Timeouts wieder da. Nehme ich die wieder rein, funktioniert alles wieder perfekt.

Nochmal durchlesen, was das jetzt im Einzelnen alles bedeutet.

Das ist die aktuell funktionierende Vhost-Config:

Code: 
server {

        listen 80;
        server_name         view.mydomain.de;

        return 301 https://$host$request_uri;
}

server {

        listen              443 ssl;
        server_name         view.mydomain.de;

        ssl_certificate /etc/letsencrypt/live/star.mydomain.de/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/star.mydomain.de/privkey.pem;

        ssl_verify_client off;

        client_header_buffer_size   64k;

        location /  {

                proxy_set_header            Host            $http_host;
                proxy_set_header            X-Real-IP       $remote_addr;
                proxy_set_header            X-Forwared-For  $proxy_add_x_forwarded_for;
                proxy_redirect              off;
                proxy_http_version          1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $http_connection;
                client_max_body_size        10m;
                client_body_buffer_size     128k;
                proxy_connect_timeout       90;
                proxy_send_timeout          90;
                proxy_read_timeout          90;
                proxy_buffer_size           16k;
                proxy_buffers               32  16k;
                proxy_busy_buffers_size     64k;

                proxy_pass https://0.0.0.30;
        }

        include /etc/nginx/extra/options-ssl.conf;
}

Unglaublich, dass der Fehler jetzt gelöst ist. Das gammelte schon ziehmlich lange vor sich hin.
 
Last edited:
proxy_http_version defaults zu 1.0 (= HTTP/1.0) und kann daher dann kein keepalive bzw. nur wenn man explizit im header "Connection: keep-alive" shipped. Das könnte dann schon die Erklärung sein.
 
You must log in or register to reply here.
Back
Top