Come configurare il DNS split-horizon per l'accesso interno e remoto alle app

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Set Up Split-Horizon DNS for Internal and Remote App Access - Zima Store Online

Usa lo stesso hostname dell'applicazione ovunque, ma restituisci un indirizzo proxy privato ai client interni fidati e VPN, e l'endpoint pubblico o del tunnel ai client esterni. Mantieni identico il nome TLS in entrambi i percorsi.

Il DNS split-horizon è utile quando il NAT hairpin non è disponibile o quando il traffico locale deve rimanere sulla LAN. Non funziona quando i client ignorano il resolver previsto, persistono risposte obsolete o l'endpoint interno presenta un certificato diverso. Definisci le due viste, riduci i TTL prima della migrazione e verifica la risoluzione separatamente da HTTPS.

Definisci le viste interne ed esterne

Scegli un FQDN per ogni applicazione. Nel DNS pubblico, indirizzalo al proxy, al tunnel o al gateway raggiungibile dall'esterno; nel DNS interno, sovrascrivilo con l'indirizzo privato del proxy locale.

Non creare un hostname diverso riservato alla rete interna solo per evitare il lavoro sui certificati, a meno che l'applicazione supporti due URL canonici. Un unico nome mantiene coerenti segnalibri, callback e client mobili quando cambiano posizione.

Documenta quali sottoreti ricevono la vista interna. Le reti guest potrebbero aver bisogno della risposta pubblica, mentre la LAN fidata e i client VPN con accesso remoto ricevono la risposta privata tramite il resolver assegnato.

Rendi deterministica la selezione del resolver

Distribuisci il resolver interno tramite DHCP e tramite il profilo VPN. Interrogalо esplicitamente per primo, quindi esegui la query tramite il sistema operativo per individuare una cache locale o un bypass del DNS crittografato.

Le cache dei resolver e le diverse librerie DNS possono produrre risultati sorprendenti; questo catalogo delle cause comuni di errore del DNS spiega perché una modifica autorevole potrebbe non apparire immediatamente sul client.

Svuota solo le cache pertinenti dopo aver confermato che il record sia corretto alla fonte. Se un browser gestito usa un proprio resolver crittografato, applica una policy approvata oppure accetta il percorso pubblico invece di modificare ripetutamente la zona locale.

Allinea proxy, certificato e comportamento dell'applicazione

Entrambi gli endpoint devono presentare un certificato valido per l'FQDN condiviso e indirizzare quell'host alla stessa identità applicativa. Un avviso relativo al certificato significa che il DNS ha raggiunto un endpoint, ma che l'endpoint non è configurato per il nome richiesto.

Verifica i reindirizzamenti, i WebSocket, gli URL di callback e l'URL esterno dell'applicazione. Un proxy locale che reindirizza a un indirizzo IP o a un hostname diverso vanifica la progettazione basata su un unico nome.

Se l'applicazione usa un sottopercorso, mantieni sincronizzati il relativo URL di base e la route del proxy. La checklist di ZimaSpace per gli aggiornamenti del container Jellyfin aiuta a preservare le impostazioni di proxy, mount e URL prima di una modifica.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Verifica i passaggi tra accesso interno e remoto

Su Wi-Fi, registra il server DNS, l'indirizzo restituito, il certificato e il risultato dell'applicazione. Ripeti su rete cellulare con il Wi-Fi disattivato; l'indirizzo dovrebbe cambiare, mentre hostname e identità del certificato dovrebbero rimanere uguali.

Connettiti alla VPN da una rete esterna e ripeti la verifica. Se la VPN dovrebbe usare il percorso privato ma riceve la risposta pubblica, correggi l'assegnazione DNS o il routing prima di modificare le impostazioni dell'applicazione.

Infine, sposta un client tra le reti e attendi il TTL. Interrompi quando tutti e tre i percorsi sono deterministici; annulla la sovrascrittura interna se i client raggiungono il proxy sbagliato o se non puoi controllare quale resolver utilizzano.