Il s'agit d'une question canonique sur la connaissance du nom d'hôte et le proxy.
Je sais que certains protocoles sont compatibles avec le nom d'hôte; c'est-à-dire que lorsque je me connecte au serveur HTTP, www.example.comil sait que je veux www.example.comle service HTTP, pas celui www.example.net, même s'ils sont sur la même adresse IP. Comment puis-je faire cela pour le protocole foo ?
(Note temporaire: cette question apparaît à la suite de cette méta-discussion .)
Réponses:
Pour comprendre ce qui se passe, vous devez en savoir un peu plus sur le DNS.
Lorsqu'un client souhaite se connecter à un service sur un hôte donné, il recherche le nom d'hôte via son infrastructure DNS locale et reçoit une adresse IP en réponse. Il se connecte ensuite à cette adresse IP et demande le service de la manière prescrite par le procotol qu'il est conçu pour implémenter.
Dans certains cas, une partie de ce procotol implique un deuxième envoi du nom d'hôte recherché à l'origine, qui dans ce cas est envoyé au serveur plutôt qu'à l'infrastructure DNS. Dans le cas de HTTP, cela a été ajouté dans le cadre de HTTP / 1.1, dans la RFC 2616 ; dans le cas de HTTPS, cela a été implémenté en tant qu'indication de nom de serveur (SNI) dans la RFC 4366 ; et dans le cas de FTP, cela a été ajouté par la HOSTcommande, dans la RFC 7151 (mais voir la mise en garde plus tard). Si un tel deuxième envoi ne se produit pas, le serveur n'a aucun moyen de savoir quel nom d'hôte le client a envoyé à son DNS local afin d'obtenir l'adresse IP du serveur.
Notez que dans tous les cas, une modification du protocole était nécessaire pour effectuer ce deuxième envoi, et ainsi rendre l'interaction client-serveur sensible au nom d'hôte. Une fois le protocole modifié, le code du serveur a dû être mis à jour pour l'implémenter. Et enfin, les clients devaient être mis à jour pour parler du nouveau protocole aux serveurs. Cette dernière étape peut être particulièrement lente; dans le cas de SNI, Internet Explorer sur Windows XP ne l'a jamais implémenté, donc le protocole ne pouvait pas être utilisé tant qu'il y avait encore un nombre important d'utilisateurs IE-on-XP, et il a fallu environ dix ans pour en avoir assez mourir et / ou obtenir des mises à niveau que SNI est déployable de manière fiable.
Voilà donc ce qu'il faut pour rendre un protocole non sensible au nom d'hôte sensible au nom d'hôte. Il ne s'agit pas d' un simple paramètre d'indicateur ou d'un changement de configuration. Nous avons des réponses spécifiques au protocole qui traitent de la situation et des mesures d'atténuation possibles, pour ce protocole en particulier: pour
SSH (et donc aussi SFTP) et pour
FTP (ce qui souligne que le HOSTsupport de FTP est actuellement dans le patchy -support phase, et ne peut donc pas encore être invoqué).
La réponse courte est que si votre protocole n'implémente pas actuellement la reconnaissance du nom d'hôte, avec une bonne prise en charge parmi les clients et les serveurs, oubliez-le: ce n'est pas quelque chose que vous pouvez faire.
bazne peut être modifié que par son propriétaire et son exécuteur unique, la seule façon de le rendre sensible au nom d'hôte est de faire appel au propriétaire. Cela ne fait pas une réponse SF intéressante, et d'ailleurs n'est pas (à mon avis) sur le sujet. « Comment puis-je concevoir un protocole compatible avec le nom d'hôte » est une autre question, et ce n'est pas celle que je souhaite poser.