Reverse Proxy Nginx, rediriger du https vers du http

[DT_Pool]

Bonjour à tous

Petite demande particulière car je n'arrive pas à m'en sortir : j'utilise un reverse proxy nginx (avec un fqdn public) derrière un firewall qui ne laisse passer que le https et j'aimerai rediriger des requêtes venant de l'extérieur (en https donc) vers un serveur interne qui n'accepte que le http.

J'ai déjà d'autres serveurs derrière le reverse proxy mais qui travaillent très bien en https, je fais les redirections en filtrant sur les locations.

J'ai donc mon serveur nginx qui n'écoute que sur le 443 et je crée une location correspondant à ce que je veux rediriger :
 

Citer

 

location /OPR {

                proxy_pass http://$ciblefqdn;

                proxy_redirect http://$ciblefqdn https://$RP_Public_fqdn;

}

 

Avec cette config, lorsque j'attaque l'url https://<FQDN public>/OPR, j'arrive bien sur la page d'accueil de l'appli souhaitée* mais quand je m'y connecte, le serveur cible modifie l'url de telle manière que cela devient: https://<FQDN public>:80/OPR/PasswordSettings.aspx

Et là, je me prends une erreur "délai d'attente dépassé".

Je cherche parmi les options du nginx mais je ne trouve pas mon bonheur pour le moment. Quelqu'un aurait-il une idée sur la manière de procéder ?

 

*: lorsque j'arrive sur la page de login, les images ne sont pas chargées, je suppose que là aussi, la redirection en http ne doit pas bien se faire.

[Minikea]

le problème vient de l'appli en elle même qui demande en dur le port 80.

si l'appli le permet, change son port en 443.

si elle ne le permet pas, il va falloir ruser avec iptables pour rediriger le trafic entrant sur le 80 vers le 443.

j'ai pas la formule toute faite mais je pense qu'en cherchant un peu, tu dois pouvoir adapter quelque chose facilement.

[DT_Pool]

C'est le genre de réponse que je craignais... tu t'en doutes, ce n'est pas configurable sur l'appli :(

Je vais déjà voir si j'ai le droit d'ouvrir le firewall sur le port 80 pour ensuite rediriger cela vers le 443

 

Merci en tout cas !

[L33thium]

hm le firewall ouvre déjà le port 80 sinon le serveur ne recevrais pas les requêtes à rediriger sur le port 443.
Je connais mal nginx mais il est probablement possible de faire de la réécriture d'url avec une regexp pour supprimer le ":80" de la requête.

[DT_Pool]

Bon, je viens de voir une erreur dès la première connexion à la page qui m'embête : bien que j'arrive sur la page de login, je vois dans la console du browser qu'il essaie déjà de charger des éléments sur le http certes, mais surtout avec l'adresse ip interne du serveur d'appli.

Bref, je maîtrise pas du tout le nginx et bien évidemment, pas de formations dessus, ce serait trop facile !

J'ai comme l'impression que la première requête avec le FQDN fonctionne bien mais qu'ensuite, le serveur demande à être contacté avec son adresse ip, ce que le serveur nginx ne sait pas traiter (pour le moment).

[Minikea]

j'ai eu presque une dizaine de services en reverse proxy (en test) et certain ne peuvent tout simplement pas gérer ça correctement. le dernier en date était texttop qui gère pas le reverse proxy avec un https://machin.truc/dossier/ mais qui doit fonctionner (peut-être) avec https://dossier.machin.truc/

de toute façon, j'avais en plus un problème avec websocket sur cette application, du coup j'ai lâché l'affaire.

Il y a des applications qui gèrent le reverse proxy, on peut leur fournir le dossier de base qu'elles doivent utiliser, mais si la tienne envoi en dur le port et qu'elle ne permet même pas de le changer, j'imagine même pas son degré d'aptitude à se conformer à un reverse proxy

@L33thium il a un "délai d'attente dépassé" donc le firewall doit être en drop sur le port 80. ça arrive même pas jusqu'à nginx qui, de toute façon, n'écoute pas sur le 80...

[DT_Pool]

J'avance... pas à pas...

Tout d'abord, j'ai ouvert le port 80, ça me fait une jolie erreur 404 (après avoir demandé si je faisais confiance au site ou pas)

Je ne gère pas de certificat pour le moment concernant cette redirection, je me dis que ça pourrait résoudre ce soucis de confiance (c'est le test que je vais faire là)

Concernant l'utilisation de l'adresse ip interne lors du chargement de la page d'accueil, j'ai trouvé la solution: j'ai rajouté les options autour du proxy_set_header et ça passe... presque!

Maintenant, en plus du pb de confiance vu plus haut, je vois dans la console du browser que les chargements des images sont bloqués car on veut charger une image non sécurisée dans un contexte sécurisé.

Voici à quoi ressemble mon bloc actuellement :

Citer

 

location /OPR {

                proxy_pass http://$ciblefqdn;

                proxy_redirect http://$ciblefqdn https://$RP_Public_fqdn;

                proxy_set_header Host $host;

                proxy_set_header X-Real-IP $remote_addr;

                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

 

 

[DT_Pool]

Alleluïa ! On vient de me dire qu'il y avait moyen de configurer le serveur en https !!

Je vais tenter cette manip, ce sera beeeeaaaauuucoup plus simple !

[Minikea]

en effet, ça te facilitera la vie!

[L33thium]

l'avertissement de sécurité c'est parce que des données en claires seront envoyées par la page chiffrée. typiquement le formulaire qui transmet les données POST à http://...

[DT_Pool]

Juste pour info, j'ai enfin réussi à faire ma redirection une fois l'appli passée en https (et aussi en me rendant compte qu'ils n'utilisaient pas tout le temps la même URL, des fois les caractères étaient en majuscules, d'autres fois non..., une fois les 2 écritures prises en compte, ça passe nickel ! )

Je suis en train de générer le certificat pour l'inclure dans les requêtes, ça reste un auto-signé mais ce sera mieux que rien !

[Minikea]

pourquoi ne pas utiliser un certificat letsencrypt?

[DT_Pool]

parce que je ne connaissais pas

Je ne me suis pas du tout attaqué aux certificats, je suis resté au basique de chez basique... voir même par défaut...

[DT_Pool]

Allez hop, je remonte ce sujet passionnant de ma vie pro

Depuis janvier, j'ai eu droit à une formation de 3 jours... formation qui n'a servi à rien puisque le gars nous a présenté un peu de tout et quasiment pas ce que je voulais (2h sur le reverse proxy le dernier jour alors que bon... nginx, c'est "un peu" créé pour faire du reverse proxy). Bien évidemment, aucune réponse dès que j'abordais un point trop technique...

Bref, je me suis bien démerdé jusque là, autant continuer !

Nouveau soucis : j'ai un serveur interne qui accepte le http sur le port 8090, pas de soucis maintenant je sais faire une redirection https vers http (au passage, avec un certificat letsencrypt). J'ai accès au site depuis l'extérieur sauf que... les websockets échouent. Dès que je me connecte sur ce site, je vois une jolie erreur :

app.js:740 WebSocket connection to 'wss://public_fqdn/selfcare/api/ws' failed: Error during WebSocket handshake: Unexpected response code: 404

 

Côté nginx, j'ai la config suivante pour ce serveur :

server {

listen @IP_publique:443 ssl;

        # Redirect to Selfcare
        location ^~ /selfcare/ {
                access_log      /var/log/nginx/otecs_vlan3603/selfcare_access.log main;
                error_log       /var/log/nginx/otecs_vlan3603/selfcare_error.log debug;
                proxy_redirect https://$RPpublic_name/selfcare/ http://$selfcarefqdn:8090/selfcare/;
                proxy_set_header                Host $host;
                proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header    X-Real-IP       $remote_addr;

                if ($request_uri ~* "/selfcare/(.*)") {
                        proxy_pass  http://$selfcarefqdn:8090/selfcare/$1;
                        }
                proxy_pass http://$selfcarefqdn:8090/selfcare/;

                }

        # Redirect to Selfcare
        location ^~ /selfcare/api/ws {
                access_log      /var/log/nginx/otecs_vlan3603/selfcare_api_access.log main;
                error_log       /var/log/nginx/otecs_vlan3603/selfcare_api_error.log debug;
                proxy_redirect off;
                proxy_set_header                Host $host;
                proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header    X-Real-IP       $remote_addr;

                proxy_pass http://$selfcarefqdn:8090/;

                proxy_set_header X-NginX-Proxy true;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Proxy "";
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "Upgrade";
                proxy_read_timeout 86400;
                }
}

J'ai découpé en 2, c'est pas beau je sais, mais c'est pour mieux tracer les requêtes websocket.

 

côté web browser, je vois une différence entre une connexion interne et une connexion passant par le nginx. En interne, la première connexion websocket revient avec le code 101 et un changement de protocole, là où via le nginx, la même requête revient en 200 ok.

"Normalement", nginx supporte les websocket grâce à l'ajout de :

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";

sauf que, ça marche pas chez moi, comme si la redirection foutait le bordel...

Une petite idée dans la salle ?

[DT_Pool]

Bon, vue la quantité de réaction...

J'ai fini par trouver la correction : lors de la redirection https vers http sur le port 8090, la websocket "oublie" au passage le port.

En modifiant la ligne par:

proxy_set_header                Host $host:$server_port;

ça passe nickel.

 

En fin de compte, ça me donne le bloc suivant:

 

# Redirect to selfcare http/https
        location ^~ /selfcare/ {
                access_log      /var/log/nginx/otecs_vlan3603/selfcare_access.log main;
                error_log       /var/log/nginx/otecs_vlan3603/selfcare_error.log debug;

                proxy_redirect http://$selfcarefqdn:8090/selfcare/ https://$RPpublic_name/selfcare/;

                # Header
                proxy_set_header Host $host:$server_port;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                chunked_transfer_encoding on;
                client_body_timeout 3600;

                # WebSocket support
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "Upgrade";
                proxy_read_timeout 86400;

                if ($request_uri ~* "/selfcare/(.*)") {
                        proxy_pass  http://$selfcarefqdn:8090/selfcare/$1;
                        break;
                        }
                proxy_pass http://$selfcarefqdn:8090/selfcare/;
        }