10
votes

Serveur derrière le proxy inverse nginx ignore le chemin relatif dans l'URL

Mon titre n'est pas le meilleur, ma connaissance de WebStuff est assez basique, désolé.

Ce que je veux atteindre h1>

J'ai une boîte fanbox forte> exécutant nginx sur Archlinux que j'utilise comme point d'entrée principal sur mon réseau local à part Internet (à savoir le travail où je ne peux que vous rendre au port 80 et 443) via l'installation de proxy inverse à l'aide d'un nom de domaine changeant sur lequel je n'ai aucun contrôle et que nous appellera home.net strong> pour l'instant. p>

fanbox forte> a ses ports 80 et 443 mappés sur home.net strong>, que une partie était facile. p>

J'ai 2 serveurs Web derrière le pare-feu, web1.lan strong>, web2.lan strong>, web2ilo.lan forte >. Ces deux disposent de diverses applications (qui peuvent avoir le même nom sur différentes machines) qui peuvent être directement accessibles sur le réseau local via des URL standard (les noms sont donnés en tant qu'ex exemples, je n'ai aucun contrôle sur le contenu): P>

   server {
      listen       443 ssl;
      server_name  localhost;

      # SSL stuff left out for clarity 

      location / {
          root   /usr/share/nginx/html;
          index  index.html index.htm;
      }

      location /web1/ {
              proxy_set_header Host $host;
              proxy_redirect off;
              proxy_pass https://web1.lan/;
      }


      location /web2/ {
              proxy_set_header Host $host;
              proxy_redirect off;
              proxy_pass https://web2.lan/;
      }

      location /web2ilo/ {
              proxy_set_header Host $host;
              proxy_redirect off;
              proxy_pass https://web2ilo.lan/;
      }

  }


2 commentaires

Vous désactivez explicitement la réécriture de l'URL avec proxy_redirect off et attendez-vous à fonctionner. Drôle.


J'ai suivi des exemples que j'ai trouvés Googling ... J'ai essayé plusieurs paramètres pour cette option, mais je ne peux guère remarquer une différence. Je suppose donc que toute mon approche est totalement tort. Pas drôle non.


3 Réponses :


1
votes

Vous voudrez peut-être envisager l'utilisation de paramètres proxy_redirect code> pour que Nginx sache qu'il doit modifier les en-têtes de réponse du serveur "Backend" (emplacement et rafraîchissement) aux URL frontal appropriées. Vous pouvez utiliser le paramètre par défaut code> pour permettre à NGinx de calculer les valeurs appropriées à partir de votre adresse Emplacement code> et proxy_pass code> directives ou spécifie explicitement les mappages comme ci-dessous. :

location /phpAdmin/ {
     proxy_set_header Host $host;
     proxy_redirect off;
     proxy_pass https://web1.lan/phpAdmin/;
}         


2 commentaires

Point 1: J'ai essayé les deux mais pas assez pour remarquer une différence. Je vais lire les tests Doc et exécuter des tests.


Point 2: Cela semble bien mais il ne couvre pas un cas particulier que je n'ai pas mentionné dans ma question ... Je ne pensais pas que ce serait nécessaire. Je vais éditerai.



0
votes

Je n'ai pas trouvé de réponse à ma question et j'ai décidé d'essayer une approche différente:

  • j'ai maintenant conteneurisé la plupart de mes serveurs
  • J'utilise trafiquier ( https://containo.us/trafik/ ) comme ma "fanbox" (= proxy inverse) car il couvre mes besoins, mais résout également de manière assez facile les certificats SSL.

    Merci tout pour vos suggestions.


2 commentaires

Comment avez-vous réussi à cela à Tradefik 2.0? Avec stripprefix Je ne pouvais pas obtenir ça. Trafik n'a pas respecté le chemin relatif.


@IVangonzAlerz Les réponses dans les commentaires sont limitées à 512 caractères, donc j'ajoute une nouvelle réponse. Voir ci-dessous.



1
votes

Voici un exemple testé.

dans mon docker-compose.yml J'utilise l'image de démonstration whoami à tester: xxx

Dans ma configuration, j'ai mon https redirige: xxx


0 commentaires