La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: Darkjeje le 02 janvier 2021 à 16:42:49
-
Bonjour à tous,
J'ai mis en place un reverse proxy pour mes différents sous-domaine via nginX.
Tout fonctionne en IPv4, mais je n'arrive pas à comprendre pourquoi cela ne fonctionne pas en IPv6.
Je pense qu'il y a soit une erreur de construction du fichier, soit une erreur de frappe quelque part, et j'imagine que votre regarde plus pro m'aidera beaucoup.
J'ai donc 4 fichiers virtualhost nginX, avec la même construction que voici.
Sauriez-vous me dire ce qui fait que je me connecte seulement en IPv4 ?
server {
listen 80;
listen [::]:80;
server_name MON_NOM_DE_DOMAINE;
#Redirige toutes les requêtes http vers https
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name MON_NOM_DE_DOMAINE;
location /.well-known { alias /var/www/letsencrypt/MON_NOM_DE_DOMAINE;}
location / {
include proxy_params;
proxy_pass https://192.168.1.9:8443/;}
ssl_certificate /etc/letsencrypt/live/MON_NOM_DE_DOMAINE/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/MON_NOM_DE_DOMAINE/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
server {
listen [::]:443 ssl http2;
server_name MON_NOM_DE_DOMAINE;
location /.well-known { alias /var/www/letsencrypt/MON_NOM_DE_DOMAINE;}
location / {
include proxy_params;
proxy_pass https://[fe80::ba27:ebff:fe71:a4fc]:8443;}
ssl_certificate /etc/letsencrypt/live/MON_NOM_DE_DOMAINE/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/MON_NOM_DE_DOMAINE/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
Je vous en remercie par avance !
Jérémy
-
listen [::]:443 ssl http2;
-
listen [::]:443 ssl http2;
Je l'ai fait en créant une 3ème partie Serveur{} (80 IPv4 + IPv6 / 443 IPv4 / 443 IPv6), car au début je n'avais que deux serveurs (80 IPv4 + IPv6 et 443 IPv4 + IPv6) et cela ne fonctionnait pas.
Donc je pensais qu'en en créant un spécifique IPv4 avec un proxy_pass en 192.168.1.x et un autre spécifique IPv6 avec un proxy_pass en [fe80:...] cela fonctionnerait, mais hélas non.
-
Ah j'avais pas vu qu'il y'avait une suite.
Ton souci vient a mon avis d'un problème de compréhension d'IPv6.
proxy_pass https://[fe80::ba27:ebff:fe71:a4fc]:8443;}
Tu utilises une FE80, appelée Link Local.
Comme son nom l'indique, c'est un range local au lien.
Or, tu ne spécifie pas le lien.
Donc impossible de savoir de quelle interface tu parles.
Avis perso : Les FE80 c'est une saleté a manipuler pour un humain, vive les GUA, tout le monde en a, ça coute pas cher, ça pose moins de problèmes.
-
Je plussois, les adresses link local c’est pas vraiment pratique pour exposer des services, ni particulièrement prévu pour ça d’ailleurs.
-
Ah j'avais pas vu qu'il y'avait une suite.
Ton souci vient a mon avis d'un problème de compréhension d'IPv6.
Tu utilises une FE80, appelée Link Local.
Comme son nom l'indique, c'est un range local au lien.
Or, tu ne spécifie pas le lien.
Donc impossible de savoir de quelle interface tu parles.
Avis perso : Les FE80 c'est une saleté a manipuler pour un humain, vive les GUA, tout le monde en a, ça coute pas cher, ça pose moins de problèmes.
C'est sûr que je suis pas un pro d'IPv6 :(
J'ai essayé aussi en mettant l'adresse IP de mon Raspberry en [2a01:e34...] qui est l'IPv6 public ou GUA si j'ai bien compris, mais cela ne fonctionne pas non plus.
Qu'est-ce qu'un lien en IPv6 ?
-
C'est une interface.
Si ça ne marche pas en v6 alors que ça marche avec un CURL, le souci est effectivement dans la conf d'nginx.
Cela dit, je ne vois pas l'intérêt d'avoir une conf de reverse proxy différente en v4 et en v6, tu peux simplement utiliser la même pour les 2...
-
C'est une interface.
Si ça ne marche pas en v6 alors que ça marche avec un CURL, le souci est effectivement dans la conf d'nginx.
Cela dit, je ne vois pas l'intérêt d'avoir une conf de reverse proxy différente en v4 et en v6, tu peux simplement utiliser la même pour les 2...
Personnellement je veux juste que ça fonctionne.
Mon but est d'avoir un reverse proxy qui fonctionne en IPv4 et en IPv6 sur les 4 sous-domaines.
J'ai créé une interface spéciale IPv6 car dans celle qui fait IPv4 + IPv6, je ne sais pas quoi mettre comme adresse IP pour le proxy_pass https://
J'avais 192.168.1.x, raison pour laquelle je me suis dit, c'est normal que cela ne fonctionne qu'en IPv4...
-
Je comprends pas trop pourquoi tu te prends la tête, il te suffit de faire ça :
server {
listen 80;
listen [::]:80;
server_name MON_NOM_DE_DOMAINE;
#Redirige toutes les requêtes http vers https
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name MON_NOM_DE_DOMAINE;
location /.well-known { alias /var/www/letsencrypt/MON_NOM_DE_DOMAINE;}
location / {
include proxy_params;
proxy_pass https://192.168.1.9:8443/;}
ssl_certificate /etc/letsencrypt/live/MON_NOM_DE_DOMAINE/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/MON_NOM_DE_DOMAINE/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
-
Je comprends pas trop pourquoi tu te prends la tête, il te suffit de faire ça :
server {
listen 80;
listen [::]:80;
server_name MON_NOM_DE_DOMAINE;
#Redirige toutes les requêtes http vers https
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name MON_NOM_DE_DOMAINE;
location /.well-known { alias /var/www/letsencrypt/MON_NOM_DE_DOMAINE;}
location / {
include proxy_params;
proxy_pass https://192.168.1.9:8443/;}
ssl_certificate /etc/letsencrypt/live/MON_NOM_DE_DOMAINE/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/MON_NOM_DE_DOMAINE/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
Je te remercie Hugues, malheureusement je reste en IPv4, du moins d'après le script que j'avais créé pour détecter le protocole utilisé.
Le problème vient peut-être de là, car j'avais fait un truc ultra basique.
Je détectais en php l'IP utilisée pour ce connecter à mon site web, et si elle dépassait 15 caractères, alors je considérais que c'était une IPv6, et sinon une IPv4.
Là vue que j'ai "proxy_pass https://192.168.1.9:8443/;}" forcément il détecte une IPv4. Idem si je mets localhost à la place de 192.168.1.9.
J'ai désactiver IPv4 sur mon ordinateur, je conserve bien une adresse IPv6 (vérifié avec http://ip.lafibre.info/), mais je n'ai plus accès à mon site web. Donc IPv6 ne fonctionne pas.
Si je mets mon adresse IPv6 public dans le proxy pass, je me connecte bien en IPv6, même si je n'ai pas de connectivité IPv6 sur le terminal utilisé.
Il ne semble donc pas y avoir d'inconvénient à mettre mon adresse IPv6 public dans mon proxy pass...
Qu'en penses-tu ? Niveau sécurité pas de risque non plus d'obtenir mon adresse IPv6 public ?
Autre chose. J'ai remarqué un comportement étrange.
Depuis des semaines je n'arrivais pas à installer une application sur mon QNAP depuis un fichier .qpkg téléchargé sur mon PC.
Il m'a fallu du temps pour comprendre que le reverse proxy en était peut-être la cause (le du fichier depuis l'app center via chrome ne s'uplodait pas).
Je me suis connecté à mon NAS via chrome depuis son adresse IPv4 et non via mon reverse proxy et son nom de domaine, et là le fichier s'est uploadé sans soucis.
Quelqu'un verrai une explication à cela ?
Une histoire de buffer ou autre paramètre du reverse proxy ?
-
Je détectais en php l'IP utilisée pour ce connecter à mon site web, et si elle dépassait 15 caractères, alors je considérais que c'était une IPv6, et sinon une IPv4.
Le mieux ça reste d'identifier les séparateurs entre les digits.
des points en IPv4 et des : en IPv6 ;)
Ton script récupère quelle ip ? avec quelle "fonction PHP" ?
L'IP de ton proxy ou celle du périphérique ?
-
Le mieux ça reste d'identifier les séparateurs entre les digits.
des points en IPv4 et des : en IPv6 ;)
Ton script récupère quelle ip ? avec quelle "fonction PHP" ?
L'IP de ton proxy ou celle du périphérique ?
Merci pour le tuyau, j'étais vraiment allé au plus basique.
L'IP est récupérée par le script suivant $_SERVER['REMOTE_ADDR'].
Comme cela fonctionnait, je n'ai pas cherché mieux, et n'avais pas prévu le changement induit par le reverse proxy.
-
Il faudrait que tu affiches cette IP pour voir si c'est celle du proxy ou celle du client.
Si c'est celle du proxy, il faudrait modifier le proxy pour qu'il ajoute une entête de ce style
$_SERVER['HTTP_X_FORWARDED_FOR']
avec l'IP du client.
-
Il faudrait que tu affiches cette IP pour voir si c'est celle du proxy ou celle du client.
Si c'est celle du proxy, il faudrait modifier le proxy pour qu'il ajoute une entête de ce style
$_SERVER['HTTP_X_FORWARDED_FOR']
avec l'IP du client.
C'est en effet celle du proxy (qui est aussi la même que celle du reverse proxy, les deux étant sur le raspberry).
Avec $_SERVER['HTTP_X_FORWARDED_FOR'] j'obtiens l'adresse IP de ma freebox, donc du routeur quand je test depuis mon PC en local, et l'adresse IP public depuis mon smartphone en 4G.
Merci pour le tuyau ;)
Par contre l'adresse IP affichée par mon smartphone est celle en IPv4 et non en IPv6, alors que le site http://ip.lafibre.info/ m'indique que mon smartphone utilise le protocole IPv6 par défaut.
J'avance, mais ce n'est pas encore cela...
-
Je détectais en php l'IP utilisée pour ce connecter à mon site web, et si elle dépassait 15 caractères, alors je considérais que c'était une IPv6, et sinon une IPv4.
Là vue que j'ai "proxy_pass https://192.168.1.9:8443/;}" forcément il détecte une IPv4. Idem si je mets localhost à la place de 192.168.1.9.
Pas exactement le meilleur moyen de detecter, surtout quand tu es derriere un proxy. Regarde les autres messages avec HTTP_X_FORWARDED_FOR
J'ai désactiver IPv4 sur mon ordinateur, je conserve bien une adresse IPv6 (vérifié avec http://ip.lafibre.info/), mais je n'ai plus accès à mon site web. Donc IPv6 ne fonctionne pas.
Est-ce que ton site web publie dans DNS une adresse IPv4 ET une adresse IPv6 ?
Si ce n'est pas le cas, et que tu publies uniquement une IPv4 (ou alors l'IPv6 ne commence pas par 20 - au pif c'est une link-local comme dans ta tentative de config), c'est ZERO chances qu'il y a une connexion en IPv6 qui sera initie.
Si je mets mon adresse IPv6 public dans le proxy pass, je me connecte bien en IPv6, même si je n'ai pas de connectivité IPv6 sur le terminal utilisé.
Si tu n'as pas d'IPv6 sur un terminal, tu ne peux pas te connecter en IPv6 depuis ce terminal. OK, il y a le XLAT464, mais ca c'est des choses ou des equipements reseaux intermediaries (qui ont des adresses IPv6) interviennent.
Pareil, si tu n'as pas d'IPv4, tu ne peux pas te connecter en IPv4 (modulo NAT64+DNS64 quelque-part). Si tu n'as pas d'IPv4 et tu DOIS te connecter sur une IPv4 (au pif par-ce que l'adresse IPv6 du service en question n'existe pas ou n'est pas renseignee nulle-part), c'est l'echec direct.
Il ne semble donc pas y avoir d'inconvénient à mettre mon adresse IPv6 public dans mon proxy pass...
Non. Il y a 2 connexions, et il n'est pas necessaires que les deux soient via le meme protocole:
* client -> reverseProxy
* reverseProxy -> varis serveur
Sur la deuxieme connexion, l'adresse client est toujours celle du reverse proxy, il faut donc utiliser HTTP_X_FORWARDED_FOR pour transmettre l'IP (v4, v6, ??? IPX ???) du vrai client au serveur.