(13: Berechtigung verweigert) beim Verbinden mit upstream: [nginx]

Question

Ich arbeite daran, ein Django-Projekt mit Nginx und Gunicorn zu konfigurieren.

Beim Zugriff auf meinen Port gunicorn mysite.wsgi:application --bind=127.0.0.1:8001 im Nginx-Server erhalte ich den folgenden Fehler in meiner Fehlerprotokolldatei;

2014/05/30 11:59:42 [crit] 4075#0: *6 connect() zu 127.0.0.1:8001 fehlgeschlagen (13: Keine Berechtigung) beim Verbinden mit dem Upstream, Client: 127.0.0.1, Server: localhost, Anfrage: "GET / HTTP/1.1", Upstream: "http://127.0.0.1:8001/", Host: "localhost:8080"

Unten steht der Inhalt meiner nginx.conf-Datei;

server {
    listen 8080;
    server_name localhost;
    access_log  /var/log/nginx/example.log;
    error_log /var/log/nginx/example.error.log;

    location / {
        proxy_pass http://127.0.0.1:8001;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;
    }
}

Auf der HTML-Seite erhalte ich 502 Bad Gateway.

Welchen Fehler mache ich?

Answer 1

Haftungsausschluss

Stellen Sie sicher, dass es keine Sicherheitsimplikationen für Ihren Anwendungsfall gibt, bevor Sie dies ausführen.

Antwort

Ich hatte ein ähnliches Problem mit der Einrichtung von Fedora 20, Nginx, Node.js und Ghost (Blog). Es stellte sich heraus, dass mein Problem auf SELinux zurückzuführen war.

Dies sollte das Problem lösen:

setsebool -P httpd_can_network_connect 1

Details

I habe nach Fehlern in den SELinux-Protokollen gesucht:

sudo cat /var/log/audit/audit.log | grep nginx | grep denied

Und festgestellt, dass das Ausführen der folgenden Befehle mein Problem behoben hat:

sudo cat /var/log/audit/audit.log | grep nginx | grep denied | audit2allow -M mynginx
sudo semodule -i mynginx.pp

Option #2 (wahrscheinlich sicherer)

setsebool -P httpd_can_network_relay 1

https://security.stackexchange.com/questions/152358/difference-between-selinux-booleans-httpd-can-network-relay-and-httpd-can-net

Referenzen

http://blog.frag-gustav.de/2013/07/21/nginx-selinux-me-mad/
https://wiki.gentoo.org/wiki/SELinux/Tutorials/Where_to_find_SELinux_permission_denial_details
http://wiki.gentoo.org/wiki/SELinux/Tutorials/Managing_network_port_labels

Answer 2

Ich bin auch auf dieses Problem gestoßen. Eine weitere Lösung besteht darin, den SELinux-Booleschen Wert für httpd-Netzwerkverbindungen auf on zu schalten (Nginx verwendet das httpd-Label).

setsebool httpd_can_network_connect on

Um die Änderung dauerhaft zu machen, verwenden Sie die -P-Flagge.

setsebool httpd_can_network_connect on -P

Sie können eine Liste aller verfügbaren SELinux-Booleschen für httpd anzeigen, indem Sie

getsebool -a | grep httpd

Answer 3

Ich habe mein Problem gelöst, indem ich mein Nginx als den Benutzer ausgeführt habe, mit dem ich mich gerade angemeldet habe, mulagala.

Standardmäßig ist der Benutzer als nginx im obersten Abschnitt der Datei nginx.conf wie unten angegeben definiert;

user nginx; # Standard Nginx Benutzer

Ändern Sie nginx in den Namen Ihres aktuellen Benutzers - hier, mulagala.

user mulagala; # Benutzerdefinierter Nginx Benutzer (als Benutzername des aktuell angemeldeten Benutzers)

Dies könnte jedoch das eigentliche Problem nicht lösen und möglicherweise zufällige Nebenwirkung(en) haben.

Für eine effektive Lösung verweisen Sie bitte auf Joseph Barbere's Lösung.

Answer 4

Ich hatte ein ähnliches Problem mit Centos 7. Als ich versuchte, die von Sorin vorgeschlagene Lösung anzuwenden, begann ich, im Kreis zu laufen. Zuerst hatte ich eine Berechtigung {write} verweigert. Dann, als ich das gelöst hatte, hatte ich eine Berechtigung {connectto} verweigert. Dann wieder zurück zur Berechtigung {write} verweigert.

Nach der Antwort von @Sid oben, die besagt, dass man die Flags mit getsebool -a | grep httpd überprüfen und umschalten sollte, fand ich heraus, dass zusätzlich zu httpd_can_network_connect auch http_anon_write ausgeschaltet war, was zu einer Schreibberechtigung verweigert und einer Verbindungsverweigerung {connectto} führte.

type=AVC msg=audit(1501830505.174:799183): avc:  
denied  { write } for  pid=12144 comm="nginx" name="myroject.sock" 
dev="dm-2" ino=134718735 scontext=system_u:system_r:httpd_t:s0 
tcontext=system_u:object_r:default_t:s0 tclass=sock_file

Die Ausgabe wird erhalten, indem man sudo cat /var/log/audit/audit.log | grep nginx | grep denied wie oben erklärt verwendet.

Also habe ich sie nacheinander gelöst, indem ich die Flags jeweils umgeschaltet habe.

setsebool httpd_can_network_connect on -P

Dann habe ich die von @sorin und @Joseph oben angegebenen Befehle ausgeführt

sudo cat /var/log/audit/audit.log | grep nginx | grep denied | 
audit2allow -M mynginx
sudo semodule -i mynginx.pp

Im Grunde genommen können Sie die Berechtigungen überprüfen, die mit setsebool festgelegt sind, und sie mit dem Fehler korrelieren, der beim Greppen von audit.log nginx, denied erhalten wurde.

Answer 5

Wenn der Fehler "502 Bad Gateway" auftritt, wenn die API-URL für das API-Gateway-Proxy-Pass auf Nginx auf CentOS aufgerufen wird, führen Sie den folgenden Befehl aus, um das Problem zu lösen

sudo setsebool -P httpd_can_network_connect 1