Comment configurer des remplacements DNS locaux pour plusieurs reverse proxies

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How to Configure Local DNS Overrides for Multiple Reverse Proxies - Zima Store Online

Créez une correspondance locale faisant autorité pour chaque nom d'application et associez-la à une seule adresse de proxy inverse par réseau client. Ne créez pas de remplacements génériques concurrents sur plusieurs serveurs DNS.

Plusieurs proxys deviennent source de confusion lorsque le même domaine public est réutilisé en interne : un ordinateur portable peut interroger le routeur, un conteneur peut interroger un résolveur local et un téléphone peut utiliser un DNS chiffré. Le résultat peut ressembler à un problème de proxy ou de certificat, alors que le client a simplement reçu la mauvaise adresse. Répertoriez les noms, les résolveurs, les écouteurs des proxys et les certificats avant d'ajouter des enregistrements.

Associez les noms aux limites des proxys

Répertoriez chaque FQDN d'application et le proxy qui termine sa connexion TLS. Utilisez des enregistrements spécifiques pour les exceptions et réservez un caractère générique à un domaine dont tout l'espace de noms appartient à un seul proxy.

Évitez d'attribuer deux enregistrements A privés au même nom, sauf si les deux proxys sont intentionnellement actifs et configurés à l'identique. Le DNS renvoie des adresses, pas l'état des services : des enregistrements round-robin ajoutés sans précaution peuvent envoyer la moitié des clients vers un proxy qui ne possède ni la route ni le certificat requis.

Séparez les noms d'administration des noms destinés aux utilisateurs. Si un nom d'hôte d'administration ne doit jamais être résolu sur un réseau invité, placez-le dans une vue ou un résolveur accessible uniquement au VLAN de confiance, plutôt que de compter sur le proxy pour le masquer ensuite.

Placez les remplacements dans le résolveur réellement utilisé par les clients

Créez la zone locale ou les remplacements d'hôtes sur le service DNS annoncé par DHCP pour ce réseau. Faites pointer chaque nom d'application vers l'adresse LAN de son proxy attitré, et non vers le conteneur de l'application ni automatiquement vers l'adresse WAN publique.

Les clients et les applications peuvent utiliser des bibliothèques et des caches de résolveur différents, c'est pourquoi le comportement du DNS peut rester invisible. Vérifiez le serveur indiqué dans la sortie de la requête au lieu de supposer que le remplacement du routeur a été consulté.

Désactivez le DNS chiffré côté client pendant le test, ou tenez-en compte. Si le client contourne délibérément le DNS local, les remplacements split-horizon ne peuvent pas l'influencer ; choisissez plutôt une politique DNS gérée, un enregistrement public associé à un routage hairpin ou un résolveur fourni par un VPN.

Faites correspondre les routes du proxy, TLS et les URL des applications

Sur chaque proxy, configurez uniquement les noms d'hôte qui lui sont attribués et vérifiez que le certificat couvre ces noms. Une réponse DNS correcte suivie du mauvais certificat prouve que le trafic a atteint un écouteur, mais pas le bon hôte virtuel.

Testez la route en amont depuis le proxy lui-même, puis testez le nom d'hôte public depuis un client. Si l'accès direct en amont fonctionne mais que le nom d'hôte renvoie un site par défaut, corrigez la correspondance d'hôte du proxy avant de modifier à nouveau le DNS.

Pour les applications hébergées sous un chemin, veillez à aligner la route du proxy et l'URL de base de l'application. Le guide ZimaSpace consacré à la suppression sécurisée de l'exposition de Jellyfin montre également pourquoi le DNS, les routes du proxy, la redirection et les ACL doivent être suivis ensemble.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

Vérifiez chaque réseau et définissez une procédure de restauration

Interrogez directement le FQDN auprès du résolveur local prévu, puis via le chemin normal du système d'exploitation. Les deux réponses doivent pointer vers le même proxy pour ce réseau, et la durée de vie (TTL) doit correspondre à la politique locale.

Ouvrez l'application depuis le LAN de confiance, le VLAN invité ou multimédia et le VPN, selon le cas. Notez l'adresse résolue, le nom du certificat, le statut HTTP et la redirection finale ; ces observations permettent de déterminer si le problème concerne le DNS, TLS, le routage du proxy ou l'application.

Supprimez les enregistrements dupliqués obsolètes uniquement après la réussite des tests sur tous les clients. Restaurez le dernier remplacement si différents clients alternent entre les proxys et cessez d'étendre le caractère générique jusqu'à ce que les journaux du résolveur indiquent quel serveur a répondu à chaque requête en échec.