1 votes

Pourquoi un proxy inversé ne peut-il pas se désigner lui-même ?

Lorsque je configure mon proxy inverse pour qu'il fasse suivre son propre port 80 vers son propre port 8080, j'obtiens l'avertissement suivant

2016/03/28 22:05:59 [alert] 4193#0: 512 worker_connections are not enough

qui est vraisemblablement le résultat d'une boucle infinie.

Dans la réponse acceptée pour Nginx Config : Reverse Proxy frontal vers un autre port L'utilisateur a écrit : "Je suppose que nginx n'est pas le serveur qui écoute sur le port 5010 ainsi que sur le port 80, n'est-ce pas ? Est-ce parce que les proxys inversés ne peuvent pas se rediriger vers eux-mêmes ? Ou y a-t-il une autre raison pour laquelle cette boucle infinie se produit, et ce commentaire était juste un faux-fuyant ?

Voici mon nginx.conf. Je reçois l'avertissement lorsque je vais sur router.example.com. Lorsque je supprime ce qui se trouve entre #### BEGIN BAD LINES #### cela fonctionne bien.

user    root;
worker_processes    1;
worker_cpu_affinity 0101;
master_process  off;
worker_priority 10;
error_log   /tmp/var/log/nginx/error.log;
pid /tmp/var/run/nginx.pid;
worker_rlimit_nofile    8192;
events {
    worker_connections  512;
}
http {
    log_format   main '$remote_addr - $remote_user [$time_local]  $status '
    '"$request" $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for"';

    # Because end of http://nginx.org/en/docs/http/server_names.html
    server_names_hash_bucket_size  64; 

    # From NixCraft
    # http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html

    # Host required
    server {
        listen      80 default_server;
        server_name "";
        return      444;
    }

  #### BEGIN BAD LINES ####
    ## Start router proxy ##
    server {
        listen       80;
        server_name  router.example.com
                     tomatopaste.example.com;
        access_log  /var/log/nginx/log/router.example.access.log  main;
        error_log  /var/log/nginx/log/router.example.error.log;

        ## send request back to apache1 ##
        location / {
            proxy_pass  http://192.168.1.1:8080/;
            proxy_redirect default;
            proxy_buffering off;
            proxy_set_header        Host            $host;
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
    ## End ##
  #### END BAD LINES ####

    ## Start primary proxy ##
    server {
        listen       80;
        server_name  jira.example.com
                     confluence.example.com
                     stash.example.com
                     cacti.example.com;
        access_log  /var/log/nginx/log/lamp.example.access.log  main;
        error_log  /var/log/nginx/log/lamp.example.error.log;

        ## send request back to apache1 ##
        location / {
             proxy_pass  http://192.168.1.99/;
             proxy_redirect default;
             proxy_buffering off;
             proxy_set_header        Host            $host;
             proxy_set_header        X-Real-IP       $remote_addr;
             proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
    ## End ##

    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

    # Websockets
    server {
        listen 8686;
        server_name other.example.com;
        location / {
            proxy_pass http://192.168.1.99:8686;
            proxy_redirect default;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        }
    } 
}

1 votes

Nginx n'a aucun problème à se servir de son propre proxy. Je ne vois pas où il écoute sur 8080 cependant.

4 votes

Petit détail : le nom de domaine officiel à utiliser dans les exemples et pour cacher votre vrai nom de domaine est le suivant exemple.com plutôt que sample.com. Les autres noms de domaine ont tendance à être détenus par des personnes déjà ( sample.com est une propriété ).

0 votes

@Olathe Whoops. Merci de m'avoir prévenu. Je devais être plus fatigué que je ne le pensais hier soir en l'écrivant. C'est corrigé !

1voto

Castaglia Points 3139

Je pense que la question n'est pas tant "Pourquoi un proxy inverse ne peut-il pas pointer vers lui-même ? ne devrait pas un point de proxy inverse à lui-même ?". Comme les commentateurs l'ont souligné, nginx , httpd et d'autres logiciels proxy peut être configurés pour que les connexions soient renvoyées par proxy vers eux-mêmes ; rien dans le logiciel ou la configuration empêche ceci.

Cependant, comme vous le supposez, le problème est celui des ressources. Un reverse proxy HTTP, configuré pour renvoyer les requêtes vers lui-même (soit directement, soit indirectement via un autre proxy, tel que httpd ) doit maintenir un certain état pour cette requête (afin de renvoyer la réponse à l'appelant). Si la demande passe simplement par les mêmes mandataires de manière répétée (en raison de la configuration), une certaine limite d'état/ressource est finalement atteinte, par exemple :

512 worker_connections are not enough

et le transfert de la demande se termine. Ainsi, la réponse à la question "Pourquoi ne devrait pas un proxy inverse se pointe lui-même ?" est : "Le proxy inverse finit par manquer de ressources et est incapable de traiter correctement la demande." Plus le nombre de reverse proxies dans la chaîne augmente, plus la probabilité d'une configuration par inadvertance conduisant à une boucle/un cycle augmente, et plus le nombre de proxies dans la boucle augmente, plus il peut être difficile de détecter qu'une telle boucle se produit. (Peut-être que des applications comme httpd y nginx peut examiner des en-têtes comme X-Forwarded-For en supposant que la valeur de l'en-tête est fiable, pour détecter de telles boucles, c'est-à-dire pour voir si le proxy lui-même apparaît déjà dans cette chaîne de transmission).

Dans votre cas particulier, pour prouver empiriquement qu'il s'agit bien d'une boucle infinie de transfert, il faudrait mettre en corrélation les données de la httpd les entrées du journal avec l'option nginx Je soupçonne qu'en procédant de la sorte, nous verrions effectivement le cycle dans le graphique du proxing inverse.

J'espère que cela vous aidera !

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X