Yunohost derrière un reverse-proxy

Discuss Advanced use case
1

Mon serveur YunoHost

Matériel: Serveur perso
Version de YunoHost: 4.1.6
J’ai accès à mon serveur : En SSH / Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Yunohost derrière un reverse-proxy

J’ai décidé récemment de mettre Yunohost derrière un reverse proxy nginx (sous OPNSense), mais je n’arrive malheureusement pas à le faire marcher. La redirection du reverse proxy à yunohost marche bien je recois bien les logs cependant la redirection jusqu’à /yunohost/sso me donne l’erreur “The page isn’t redirecting properly”. De plus l’adresse ip dans les logs et celle du reverse proxy et non celle de la personne allant sur le site. Est ce que le problème vient de là car la requête ne renvoie pas la réponse à la bonne ip ?

Dans la conf Nginx j’ai bien les headers de set :

 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Y-a-t’il une modification à faire côté yunohost ?

Pour la configuration Nginx sous OPNsens j’ai suivi ce tuto.

EDIT :
J’ai l’impression d’avoir une boucle dans les logs (environ 50 requêtes de ce type à chaque requête) :

10.10.150.1 - - [26/Jan/2021:18:44:20 +0100] "GET /yunohost/sso/?r=base64 HTTP/1.0" 301 178 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
10.10.150.1 - - [26/Jan/2021:18:44:20 +0100] "GET /yunohost/sso/?r=base64 HTTP/1.0" 301 178 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
10.10.150.1 - - [26/Jan/2021:18:44:20 +0100] "GET /yunohost/sso/?r=base64  HTTP/1.0" 301 178 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
10.10.150.1 - - [26/Jan/2021:18:44:20 +0100] "GET /yunohost/sso/?r=base64  HTTP/1.0" 301 178 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
10.10.150.1 - - [26/Jan/2021:18:44:20 +0100] "GET /yunohost/sso/?r=base64  HTTP/1.0" 301 178 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
10.10.150.1 - - [26/Jan/2021:18:44:20 +0100] "GET /yunohost/sso/?r=base64  HTTP/1.0" 301 178 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
10.10.150.1 - - [26/Jan/2021:18:44:20 +0100] "GET /yunohost/sso/?r=base64  HTTP/1.0" 301 178 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"

10.10.150.1 est celle de mon opnsense

Merci à vous.

2

C’est sans doute lié au fait que Yunohost a tendance à rediriger en https lorsqu’il recoit une requête en http … Du coup si ton reverse proxy se passe en HTTP en interne, il va sans cesse vouloir rediriger vers du https … À ce jour il n’y a pas de solution simple à part desactiver les redirections http->https dans chaque conf nginx d’apps …

c.f. Auto-redirect to HTTPS should be managed domain-wide or system-wide, not in each app conf · Issue #1024 · YunoHost/issues · GitHub

3

(Par contre ça ne résoudra pas le problème d’IP locale dans les logs, c’est un soucis indépendant mais qui peut poser d’autre problème, par exemple fail2ban qui va finir par bannir l’IP locale si il détecte une tentative de brute force …)

4

J’ai déjà essayé de modifier le https en http dans les confs + reload/restart de nginx sans succès. Et de toute façon la prochaine étape quand celle-ci marchera sera de mettre du https sur le serveur yunohost aussi . ^^

5

Mouarf il faut ptete aussi forcer “portal_scheme” à “http” dans la conf ssowat…

6

Oublie j’ai trouvé !!! Bon enfaite je me suis dis que si c’était bien ça le problème autant tout laisser en https. Dans l’interface OPNSense j’ai passé le port à 443, utilisation de TLS, non vérification du certif et ca passe.

Il me reste tout de même mon problème de log si jamais tu as une idée ?

Merci en tout cas.

7

Je viens aussi de remarquer que j’obtient une 404 quand je me rend sur “/.well-known/acme-challenge/xxxxxxxxxxxxxxxxxxxxxxxxxxxx”, c’est étrange car le fichier de conf est bon et le fichier est bien dans le dossier sous /tmp.

8

Bonsoir,

Le problème des logs persiste même après le changement dans OPNSense ?

Et pour l’erreur 404 il faudrait faire un test de renouvellement du certificat en ligne de commande pour voir si let’s encrypt y arrive ou pas.

Amicalement,
Gaëtan.

9

Oui l’IP est toujours celle d’OPNSense.

Pour la 404 j’ai pas précisé mais j’avais testé d’ajouter le certifs “sudo yunohost domain cert-install domain.tld --no-checks” juste avant. L’erreur que j’obtient c’est une 403 :

{u'status': 403, u'type': u'urn:ietf:params:acme:error:unauthorized', u'detail': u'Invalid response from http://domain.tld/.well-known/acme-challenge/89zeFI9kTFiVRmenpmEzQExF9SFdRGHJsJzRk2WpGu0 [x.x.x.x]: "<?xml version=\\"1.0\\" encoding=\\"iso-8859-1\\"?>\\n<!DOCTYPE html PUBLIC \\"-//W3C//DTD XHTML 1.0 Transitional//EN\\"\\n         \\"http://www."'}, u'type': u'http-01'}
10

Re,

Pour le reverse-proxy une inspiration à suivre :

LibreSignage/reverse_proxy.rst at master · eerotal/LibreSignage · GitHub

Qui de mémoire m’a permis d’avoir mon adresse ip publique bien transmise entre un nginx en reverse proxy et Libre Signage dans un docker.

À tester,

Amicalement,
Gaëtan.

11

Voilà ma conf qui me semble bonne d’après ton lien la seule différence c’est Host $host
à la place de Host $http_host

location  / {
    BasicRule wl:19;
    DeniedUrl "/waf_denied.html";
    autoindex off;
    http2_push_preload off;
    proxy_set_header Host $host;
    proxy_set_header X-TLS-Cipher $ssl_cipher;
    proxy_set_header X-TLS-Protocol $ssl_protocol;
    proxy_set_header X-TLS-SNI-Host $ssl_server_name;
    # proxy headers for backend server
    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;
    proxy_set_header X-TLS-Client-Intercepted $tls_intercepted;
    proxy_ignore_client_abort off;
    proxy_request_buffering on;
    proxy_max_temp_file_size 1024m;
    proxy_buffering on;
    proxy_pass https://x.x.x.x;
    proxy_ssl_server_name off;
    proxy_ssl_protocols TLSv1.2 TLSv1.3;
    proxy_ssl_trusted_certificate /etc/ssl/cert.pem;
    proxy_ssl_verify off;
    proxy_ssl_verify_depth 1;
    proxy_store off;
    proxy_hide_header X-Powered-By;
}
12

Autre problème dont je m’appercois c’est ce message, lorsque je fais un diagnostique DNS. Un autre fait étrange tous mes service web sont marqués hors ligne alors que bien accesible via le port 443.

13

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.