Comment configurer un DNS à horizon fractionné pour accéder aux applications en interne et à distance

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.

Utilisez le même nom d’hôte d’application partout, mais renvoyez une adresse de proxy privée aux clients internes de confiance et connectés au VPN, et le point de terminaison public ou du tunnel aux clients externes. Gardez le nom TLS identique sur les deux chemins.

Le DNS à vue séparée est utile lorsque le NAT loopback n’est pas disponible ou lorsque le trafic local doit rester sur le réseau local. Il échoue lorsque les clients contournent le résolveur prévu, que des réponses obsolètes persistent ou que le point de terminaison interne fournit un certificat différent. Définissez les deux vues, réduisez les TTL avant la migration et testez la résolution séparément du protocole HTTPS.

Définir les vues interne et externe

Choisissez un FQDN pour chaque application. Dans le DNS public, faites-le pointer vers le proxy, le tunnel ou la passerelle accessibles de l’extérieur ; dans le DNS interne, remplacez cette résolution par l’adresse privée du proxy local.

Ne créez pas un autre nom d’hôte réservé à l’interne simplement pour éviter le travail lié aux certificats, sauf si l’application prend en charge deux URL canoniques. Un nom unique permet de conserver des favoris, des rappels et des clients mobiles cohérents lors des changements de réseau.

Documentez les sous-réseaux qui reçoivent la vue interne. Les réseaux invités peuvent avoir besoin de la réponse publique, tandis que le réseau local de confiance et les clients VPN d’accès distant reçoivent la réponse privée via le résolveur qui leur est attribué.

Rendre la sélection du résolveur déterministe

Annoncez le résolveur interne via DHCP et dans le profil VPN. Interrogez-le explicitement en premier, puis effectuez une requête via le système d’exploitation afin de détecter un cache local ou un contournement du DNS chiffré.

Les caches des résolveurs et les différentes bibliothèques DNS peuvent produire des résultats surprenants ; ce catalogue des causes courantes de panne du DNS explique pourquoi une modification faisant autorité peut ne pas apparaître immédiatement chez le client.

Videz uniquement les caches concernés après avoir confirmé que l’enregistrement est correct à la source. Si un navigateur géré utilise son propre résolveur chiffré, appliquez une stratégie approuvée ou acceptez le chemin public au lieu de modifier sans cesse la zone locale.

Aligner le comportement du proxy, du certificat et de l’application

Les deux points de terminaison doivent présenter un certificat valide pour le FQDN partagé et acheminer cet hôte vers la même identité d’application. Un avertissement de certificat signifie que le DNS a atteint un point de terminaison, mais que celui-ci n’est pas configuré pour le nom demandé.

Vérifiez les redirections, les WebSockets, les URL de rappel et l’URL externe de l’application. Un proxy local qui redirige vers une adresse IP ou un autre nom d’hôte annule la conception à nom unique.

Si l’application utilise un sous-chemin, maintenez son URL de base et sa route de proxy synchronisées. La checklist ZimaSpace pour les mises à niveau des conteneurs Jellyfin aide à préserver les paramètres du proxy, des montages et des URL avant une modification.

Tester les transitions entre l’accès interne et distant

En Wi-Fi, notez le serveur DNS, l’adresse renvoyée, le certificat et le résultat de l’application. Recommencez via le réseau mobile avec le Wi-Fi désactivé ; l’adresse doit changer, tandis que le nom d’hôte et l’identité du certificat restent identiques.

Connectez le VPN depuis un réseau externe et recommencez. Si le VPN doit utiliser le chemin privé mais reçoit la réponse publique, corrigez l’attribution DNS ou le routage avant de modifier les paramètres de l’application.

Enfin, déplacez un client d’un réseau à l’autre et attendez l’expiration du TTL. Arrêtez-vous lorsque les trois chemins sont déterministes ; annulez la substitution interne si les clients atteignent le mauvais proxy ou si vous ne pouvez pas contrôler le résolveur qu’ils utilisent.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.