Auteur Sujet: [Livebox] Diverses questions installation serveur web maison (Lu 806 fois)

Winfried · « **Réponse #12 le:** **Aujourd'hui** à 06:53:02 »

Merci, je regarderai la prochaine fois

De fait, Nginx est configuré pour afficher le site quand il est appelé par www.acme.com… mais comme la Livebox, contrairement à la Freebox, ne gère pas le hairpin/loopback, quand on travaille sur le site en local, il faut obligatoirement l'appeler par son adresse IP :-/

De là, comment faire pour travailler sur un site web en interne, sans utiliser à chaque fois un smartphone pour regarder le site par l'extérieur ? Ajouter un nom court dans le fichier hosts du Macintosh et dans la config de Nginx comme alias du site ?

Code: [Sélectionner]

server {
	root /usr/share/nginx/acme;
	index index.html index.htm;

	#added "acme" for access from LAN
	server_name www.acme.com acme.com acme;

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/www.acme.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.acme.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
	#How to add "acme" ?
    if ($host = www.acme.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

	server_name www.acme.com acme.com;
    listen 80;
    return 404; # managed by Certbot
}

---
Edit: Je crois que j'ai trouvé. Dans Nginx, de fait je n'ai probablement pas inclus l'adresse IP locale en plus du nom de domaine (FQDN), ce qui expliquerait pourquoi le serveur ne répondait pas. Je vérifierai la prochaine fois.

Code: [Sélectionner]

server_name 192.168.1.80 www.acme.com;

robin4002 · « **Réponse #13 le:** **Aujourd'hui** à 10:23:00 »

Bonjour,

Je rejoins l'analyse des autres, que le serveur ne réponde pas en accédant directement à 192.168.1.80 n'est pas un problème de la box. Même sans ouvrir de port, en local ça devrait fonctionner si le serveur web répond bien.

Par contre avoir de l'https avec l'ip directement va forcément causer des problèmes de certificats.
Il faudrait soit rester en http en local, soit avoir du dns redirigeant le domaine vers 192.168.1.80 en local. Mais pour cela il faudrait un serveur dns en local ou override le fichier hosts, pas très pratique...

La solution la plus simple restant d'avoir du loopback, que la livebox 3 ne gère pas, comme vous l'aviez déjà remarqué.
Les livebox plus récentes gèrent le loopback, je pense que ce besoin est une bonne justification pour remplacer la livebox 3, qui est de toute façon en fin de vie

Winfried · « **Réponse #14 le:** **Aujourd'hui** à 11:02:54 »

Merci, je vais lui suggérer l'idée d'upgrader sa vieille LB Play 3.

J'ai configuré Nginx pour qu'il utilise https parce que ça devient la norme même pour un simple site documentaire statique comme ici, où l'utilisateur n'envoie aucune information sensible. Par exemple, Chrome n'affiche pas les sites web perso de Free du premier coup, faute de les avoir passés en https (2017 !).

Avant de chercher, comment configurer Nginx pour "rester en http en local" tout en utilisant https pour les acccès depuis l'extérieur via le FQDN ?

gg40530 · « **Réponse #15 le:** **Aujourd'hui** à 11:12:19 »

Pour te faciliter les choses avec un serveur web / reverse proxy en https je te conseille de regarder caddy https://caddyserver.com

Winfried · « **Réponse #16 le:** **Aujourd'hui** à 11:56:01 »

Je vais regarder, merci

Paul · « **Réponse #17 le:** **Aujourd'hui** à 14:51:28 »

Citation de: Winfried le Hier à 23:47:56

Firefox autocomplète avec "https" (donc 443) et utilise peut-être IPv6 par défaut, comme Chrome : dois-je bidouiller la section Pare-feu de la Livebox même pour les connexions internes à la Livebox ?

L'utilisation de HTTPS et la génération du protocole IP ne sont pas liées. Quand tu accèdes à un autre appareil sur même domaine de diffusion (comme ton LAN), tu ne passes même pas par le routeur. Le pare-feu de la Livebox n'intervient pas.

Firefox utilise IPv6 par défaut comme tous les navigateurs aujourd'hui, sauf quand tu utilises une adresse IPv4 littérale. Faire écouter nginx sur l'IPv6 pourrait cependant résoudre le problème de hairpin NAT, comme il n'y aurait plus de NAT sur le trajet et que l'adresse publique est la même que la privée.

Citation de: Winfried le Aujourd'hui à 06:53:02

Edit: Je crois que j'ai trouvé. Dans Nginx, de fait je n'ai probablement pas inclus l'adresse IP locale en plus du nom de domaine (FQDN), ce qui expliquerait pourquoi le serveur ne répondait pas. Je vérifierai la prochaine fois.

Code: [Sélectionner]
server_name 192.168.1.80 www.acme.com;

nginx se sert d'abord du nom de domaine qui figure dans l'en-tête HTTP qu'il reçoit pour décider du site à servir. S'il n'y a pas de nom de domaine, il répond sur l'adresse IP par le bloc server qui a default_server après le port d'écoute (listen 192.168.1.80:80 default_server). Il faudrait donc plutôt rajouter default_server à cette ligne.

Si tu comptes utiliser du HTTPS uniquement (ce qui est préférable), le nom de domaine deviendra de toutes manières nécessaire. À ce moment, fais pointer le domaine vers l'IPv6 de ton serveur et accèdes-y uniquement en IPv6 depuis le LAN, l'IPv4 restant disponible pour des visiteurs extérieurs sans IPv6.

Winfried · « **Réponse #18 le:** **Aujourd'hui** à 17:24:07 »

Merci beaucoup