Comment résoudre les problèmes d’une application distante qui fonctionne avec l’adresse IP, mais pas avec le domaine

Si une application fonctionne avec une adresse IP mais pas avec un domaine, le serveur est accessible et l’échec se situe généralement au niveau du DNS, du routage basé sur le nom d’hôte, du TLS ou des redirections.

L’accès à distance par IP prouve qu’un chemin réseau atteint le serveur domestique, mais une requête vers un domaine apporte des informations d’identité supplémentaires via le DNS, le nom du serveur TLS, l’en-tête HTTP Host et l’URL publique configurée de l’application. Le diagnostic le plus rapide consiste à conserver le même client, le même port et le même serveur tout en vérifiant chaque couche d’identité dans l’ordre, plutôt que de modifier simultanément le proxy inverse, le certificat et les enregistrements DNS.

Confirmer que le test par IP atteint le service prévu

Notez l’adresse IP, le port, le protocole et la réponse exacte qui fonctionnent à distance. Vérifiez si l’adresse IP ouvre la véritable application, une page par défaut du proxy inverse, une interface de connexion du routeur ou un autre service partageant la même adresse publique.

Un guide sur les proxys inverses dans un homelab explique qu’un proxy peut héberger plusieurs applications sur une même adresse, car il examine l’en-tête Host demandé avant de choisir le service en amont.

Si l’adresse IP n’atteint qu’un site par défaut, cela prouve que le proxy est accessible, mais pas que la route vers l’application cible fonctionne. Conservez un marqueur de réponse connu, comme un titre de page ou un en-tête, afin que les tests ultérieurs identifient le bon hôte virtuel.

Comparer le DNS public avec l’adresse IP fonctionnelle

Interrogez le domaine via un serveur de noms faisant autorité et au moins un résolveur récursif externe. Notez chaque réponse A et AAAA, le TTL et la présence éventuelle d’un CNAME pointant vers un autre nom d’hôte.

Les recommandations en matière d’auto-hébergement indiquent que les réponses mises en cache peuvent rester valides jusqu’à l’expiration de l’ancien TTL. Ainsi, après la correction de l’enregistrement faisant autorité, certains clients peuvent encore utiliser une ancienne destination DNS.

Si l’enregistrement A diffère de l’adresse IP fonctionnelle, corrigez l’enregistrement ou le programme de mise à jour DDNS. Si A est correct, mais que AAAA pointe vers un chemin IPv6 inaccessible, testez séparément chaque famille d’adresses et supprimez ou réparez l’enregistrement défectueux.

Se connecter à l’adresse IP fonctionnelle tout en conservant le domaine

Utilisez un client capable de se connecter à l’adresse IP connue comme fonctionnelle tout en envoyant le domaine dans l’en-tête HTTP Host et comme nom de serveur TLS. Cela modifie la destination sans supprimer l’identité attendue par le proxy et le certificat.

Server Fault explique qu’un proxy inverse HTTP peut utiliser l’en-tête Host pour sélectionner une route, de la même manière que les hôtes virtuels basés sur le nom.

Si la requête avec le domaine conservé fonctionne, le DNS est la couche défaillante. Si elle atteint le proxy, mais renvoie le mauvais site ou une erreur 404, examinez la correspondance des hôtes virtuels et la priorité des routes ; si le TLS échoue avant HTTP, examinez le SNI et la sélection du certificat.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifier le SNI TLS et l’identité du certificat

Comparez le certificat renvoyé pour le domaine avec celui renvoyé pour l’adresse IP seule. Notez les noms du sujet, l’autorité émettrice, la date d’expiration et le fait éventuel que le proxy présente un certificat par défaut.

Le SNI transporte le nom d’hôte dans le ClientHello TLS avant la requête HTTP chiffrée, ce qui permet au proxy de sélectionner l’hôte virtuel sécurisé. Une requête utilisant uniquement une adresse IP peut donc ne pas fournir le nom d’hôte utilisé lors de la sélection TLS, même si elle atteint le même écouteur.

Corrigez le certificat du domaine et la route SNI au lieu d’attendre un certificat pour une adresse IP privée ou dynamique. Si un CDN ou un proxy TCP se trouve en amont, confirmez qu’il transmet ou termine le SNI pour le nom d’hôte prévu.

Vérifier que les DNS internes et externes n’empruntent pas des chemins différents

Comparez le résultat du domaine via le réseau mobile, un résolveur public et le réseau local domestique. Un DNS partagé peut intentionnellement renvoyer une adresse de proxy privée à domicile et une adresse publique à distance, mais les deux réponses doivent atteindre la même route logique du nom d’hôte.

Une discussion sur un homelab sur Level1Techs montre que l’accès local à un proxy inverse peut nécessiter sa propre conception DNS lorsque le DNS public et le routage domestique empruntent des chemins internes et externes différents.

Si un seul résolveur renvoie la mauvaise adresse, corrigez cette vue DNS. Si l’adresse publique fonctionne par IP, mais que le domaine échoue partout, concentrez-vous sur Host, le SNI, le certificat et l’identité de l’application plutôt que sur le DNS partagé.

Vérifier les URL canoniques et les redirections avant de déclarer le DNS corrigé

Examinez chaque redirection une fois que le domaine atteint l’application. Le proxy inverse ou l’application peut rediriger les clients vers un nom d’hôte interne, un ancien domaine, un schéma incorrect, un port privé ou une ancienne URL de rappel.

L’article de ZimaSpace consacré à la question de savoir si un DNS partagé peut résoudre un échec limité au réseau interne traite du cas connexe où le nom d’hôte est correct, mais où la route varie selon l’emplacement.

Le problème n’est résolu que lorsque le DNS faisant autorité renvoie l’adresse prévue, que le domaine sélectionne le bon certificat et la bonne route du proxy, que les redirections conservent le nom d’hôte public et que le flux de travail distant complet fonctionne sans remplacer le domaine par l’adresse IP.