Qu’est-ce qui fait que le DNS local renvoie la bonne adresse IP, mais le mauvais service ?

Le DNS local peut renvoyer l’adresse IP correcte du NAS tout en ouvrant le mauvais service lorsque le proxy inverse partagé dirige le nom d’hôte vers un autre hôte virtuel.

Sur un serveur domestique ZimaSpace, plusieurs applications peuvent partager une seule adresse LAN derrière Nginx, Traefik, Caddy ou un autre proxy inverse. Le DNS ne fait que sélectionner l’adresse IP de destination. Le navigateur envoie toujours un nom d’hôte via SNI TLS et l’en-tête HTTP Host, puis le proxy détermine quel conteneur reçoit la requête.

Vérifier que la réponse du DNS fractionné est bien celle attendue

Comparez l’enregistrement local avec l’enregistrement public et confirmez que les deux noms d’hôte sont censés aboutir au même proxy inverse.

Un article ciblé sur le DNS fractionné dans un homelab, disponible sur le DNS fractionné peut fournir un chemin privé, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Conservez le nom d’hôte du navigateur inchangé tout en ne modifiant que l’adresse renvoyée par le DNS interne.

Vérifier que le proxy effectue le routage par nom d’hôte

Envoyez des requêtes avec le nom d’hôte attendu et comparez-les avec un accès direct par IP au même NAS.

Un guide ciblé sur les proxys inverses dans un homelab, disponible sur l’en-tête Host sélectionne le serveur principal, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Si l’adresse IP directe ouvre une application par défaut tandis que le nom d’hôte ouvre la bonne application, le DNS n’est pas en cause : le routage par hôte virtuel fonctionne comme prévu.

Vérifier si l’en-tête Host est réécrit

Examinez les en-têtes Host et forwarded-host au niveau du proxy et du serveur principal.

Un article ciblé sur la sécurité et le protocole HTTP, disponible sur les modifications de l’en-tête Host peuvent changer le routage, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Corrigez uniquement la couche qui réécrit le nom d’hôte. N’ajoutez pas d’enregistrements DNS en double pour compenser une erreur de routage HTTP.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifier le SNI TLS avant le routage HTTP

Plusieurs applications HTTPS sur une même IP doivent tout de même présenter le nom d’hôte nécessaire pour sélectionner le certificat et l’hôte virtuel appropriés.

Un guide pratique ciblé sur le SNI, disponible sur le SNI sélectionne un site HTTPS parmi plusieurs sur une même IP, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Comparez le nom du certificat et la route du serveur principal. Un certificat correspondant à une autre application indique que la sélection a échoué avant que la requête n’atteigne le service prévu.

Examiner l’hôte virtuel par défaut

Si aucune règle de nom d’hôte ne correspond, de nombreux proxys renvoient un serveur par défaut qui peut appartenir à une autre application.

Un article ciblé de dépannage de Nginx, disponible sur un nom d’hôte sans correspondance peut atteindre le serveur par défaut, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Créez des règles explicites pour les noms d’hôte ainsi qu’une réponse par défaut neutre, plutôt que de laisser une application devenir la destination fourre-tout de chaque domaine inconnu.

Séparer le routage DNS du routage du proxy

Considérez le DNS comme le mécanisme de sélection de l’adresse et le proxy inverse comme celui de sélection de l’application.

Un article ciblé expliquant la différence entre DNS et proxy inverse, disponible sur le DNS et les proxys inverses résolvent des problèmes de routage distincts, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Refaites le test avec le nom d’hôte exact de l’application depuis un client du réseau local. Le résultat correct doit présenter le certificat attendu, la route du proxy et le serveur principal approprié, sans utiliser de favoris fondés sur l’adresse IP directe.

Retester le chemin exact vers le serveur domestique

Après avoir modifié une seule variable, répétez le même parcours NAS ou auto-hébergé depuis le même client au lieu de passer à un autre test susceptible d’emprunter un chemin différent.

Le guide ZimaSpace associé, disponible sur le chemin réseau domestique associé, aide à maintenir la vérification finale liée au même environnement auto-hébergé.

La correction n’est terminée que lorsque le symptôme initial reste résolu après une reconnexion, un redémarrage du service et un second transfert ou une seconde requête contrôlée.