Nginx : listen [::]:80 ? À quoi cela sert t-il ?

Résolu/Fermé
DoctorAngry Messages postés 158 Date d'inscription samedi 16 mars 2019 Statut Membre Dernière intervention 9 mars 2022 - 21 sept. 2021 à 22:23
DoctorAngry Messages postés 158 Date d'inscription samedi 16 mars 2019 Statut Membre Dernière intervention 9 mars 2022 - 27 sept. 2021 à 12:06
Bonsoir,

Je configure actuellement un serveur web sous Nginx (Raspbian).

Je comprends tout à fait la ligne
listen 80
.
Mais je suis tombé à plusieurs reprise sur la ligne
listen [::]:80
qui suit généralement à
listen 80
.

Pas moyen de trouver à quoi cela sert dans la documentation.
Avez-vous une idée ?

Cdt

3 réponses

barnabe0057 Messages postés 14454 Date d'inscription lundi 2 mars 2009 Statut Contributeur Dernière intervention 30 novembre 2024 4 918
Modifié le 22 sept. 2021 à 06:53
Bonjour,

C'est de l'ipv6, je suppose que ça correspond en ipv4 à 0.0.0.0:80, c'est-à-dire qu'il est en écoute sur le port 80 sur toutes les interfaces réseau présentes sur la machine.


1
mamiemando Messages postés 33432 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 16 décembre 2024 7 809
Modifié le 24 sept. 2021 à 12:04
Bonjour,

Dans ce qui suit, je distingue le serveur (au sens de la machine), e.g. la machine dont on parle, et le serveur (au sens application), e.g. ton serveur web (apache, nginx...).

Comme l'explique très bien barnabe0057,
::
correspond en IPv6 à
0.0.0.0
en IPv4. Cela signifie effectivement que le serveur (au sens application) écoute sur toutes les interfaces réseaux exposées par le système d'exploitation de ta machine.

Ce paramètre de configuration est appelé "bind address" dans certains fichier de configuration, en référence àa la primitive réseau
bind
, utilisée dans le code du programme. La fonction
bind
spécifie si le serveur (au sens application) va accepter ou rejeter une connexion en fonction de l'interface réseau qui a été sollicitée pour atteindre le serveur.

La bind-address est un paramètre qu'il est utile de préciser dans certaines situations :
  • Si tu ne veux écouter que les requête réseaux locales au serveur (au sens machine), on se restreindrait à écouter uniquement le trafic local, ce qui correspond à l'interface réseau
    127.0.0.1
    . Le serveur (au sens application) est donc inatteignable de l'extérieur. C'est typiquement comme ça qu'est configuré par défaut un serveur de base de données (e.g. mysql), car en général seul le serveur web déployé sur la même machine est supposé y accéder. Ce paramètre devrait typiquement être relâché si le serveur web et le serveur de base de données n'étaient pas co-localisés sur la même machine.
  • Parfois, on ne veux écouter que le trafic réseau qui provient d'une interface réseau réelle (e.g. celle qui correspond à un réseau local, mais pas à un réseau public).


Bref, tu peux voir ça la bind-address comme une manière complémentaire / simplifiée (par rapport à un pare-feu) de définir quel client accéder à ton serveur (au sens logiciel). À tout moment, tu peux voir avec
netstat -ntlp
les différents serveurs logiciels actifs sur ta machine, leur port d'écoute, et leur bind-address.

Si la bind-address n'est pas sans rappeler les pare-feu, on peut se demander dans quels mesures ces deux aspects sont "redondants". Les nuances expliquent pourquoi les deux existent.
  • Contrairement au pare-feu, la notion de bind-address est spécifique à une instance de serveur (au sens application). Au moment de faire le
    bind
    , le serveur sait sur quel port il doit écouter (e.g.
    80
    dans ton cas), ce qui caractérise partiellement de quels flots on parle. Plus précisément, le filtrage induit par la bind-adress revient à ne considérer que l'IP? Cela correspond à l'IP destination qu'on pourrait être amenée à définir dans une règle de pare-feu.
  • Un pare-feu (comme
    iptables
    ) est configuré pour l'ensemble du système. Les règles qu'il définit sont donc communes à toutes les applications réseaux (qu'elles soient cliente ou serveur), ce qui force au passage à en définir plusieurs et selon les flots qu'elles caractérise, à les mettre dans le bon ordre. Les règles du pare-feu se doivent donc nécessairement être plus expressives afin de caractériser n'importe quel flot. C'est pourquoi chaque règle d'un pare-feu donne l'opportunité de caractériser les différents paramètres du(des) flot(s) au(x)quel(s) elle s'applique. Cela inclue l'IP destination, mais aussi l'IP source (celle du client), les ports impliqués (source / destination), le protocole utilisé (TCP, UDP, ICMP...).
  • Enfin, le rejet éventuel n'est pas fait au même endroit et au même moment.
    iptables
    permet de filtrer le trafic au niveau du noyau (au travers de netfilter) donc au niveau du noyau. Cela signifie qu'une demande de connexion peut être rejetée par le pare-feu avant même qu'elle n'atteigne le serveur (au sens application). Si le pare-feu laisse passer la demande, celle-ci sera remontée au serveur (au sens application) par le système d'exploitation. Le serveur décide alors (en fonction de la bind-address et l'interface réseau impliquée) si la demande est acceptable.


Bonne chance
0
DoctorAngry Messages postés 158 Date d'inscription samedi 16 mars 2019 Statut Membre Dernière intervention 9 mars 2022 128
27 sept. 2021 à 12:06
Bonjour,

Je vous remercie grandement pour ces éclairages plus que complet !
C'est super de pouvoir se faire aider de temps à autre.
Merci.

Bien cordialement,
DrA
0