Il DNS Split può risolvere un'app self-hosted che funziona solo all'interno della tua casa?

Sì, il DNS diviso può risolvere un problema interno quando il nome host pubblico dovrebbe risolversi in un indirizzo locale diverso a casa.

Un'app self-hosted può funzionare con i dati mobili perché il DNS pubblico punta all'indirizzo WAN di casa, mentre i dispositivi all'interno della LAN falliscono perché il router non può effettuare il hairpin di quella connessione attraverso la regola NAT pubblica. Il DNS diviso evita questo loop restituendo ai client di casa l'indirizzo locale del reverse-proxy o dell'app, ma funziona solo quando lo stesso nome host, certificato, percorso proxy e URL base dell'applicazione rimangono validi in entrambi i percorsi.

Verifica Prima Che Il Nome Pubblico Funzioni Da Fuori

Testa l'URL esatto dell'applicazione da dati mobili o da un'altra rete esterna. Conferma la risoluzione DNS, TLS, il routing del reverse-proxy, il login, i reindirizzamenti e la funzione dell'applicazione che attualmente fallisce all'interno della casa.

Tailscale descrive il DNS diviso come un modo per fornire ai client risposte DNS diverse a seconda del contesto invece di costringere utenti interni ed esterni a passare attraverso un unico percorso identico.

Se l'app fallisce anche esternamente, il DNS diviso non è la prima soluzione. Risolvi il DNS pubblico, il tunnel o il port forwarding, il routing del proxy, TLS o la configurazione dell'applicazione prima di creare una seconda risposta che potrebbe nascondere il problema originale.

Controlla Se Il Fallimento Interno È Causato Da Hairpin NAT

Da un client di casa, interroga il nome host pubblico e registra l'indirizzo restituito. Se si risolve nell'IP pubblico di casa, verifica se il router supporta il NAT loopback o hairpin NAT per quel servizio inoltrato.

Un thread di troubleshooting di Level1Techs consiglia un override DNS locale che punta il dominio all'indirizzo del server interno quando l'hairpin NAT è inaffidabile.

Confronta il fallimento del nome pubblico con l'accesso diretto all'indirizzo locale del reverse-proxy. Se l'accesso locale diretto raggiunge il proxy o l'app prevista, mentre l'IP pubblico fallisce solo dall'interno, il DNS diviso è una soluzione molto adatta.

Indirizza La Risposta Interna Allo Stesso Punto Logico Di Accesso

Crea un record DNS interno per il nome host pubblico esistente, ma indirizzalo all'indirizzo LAN del reverse proxy o del punto di accesso locale controllato. Evita di puntare direttamente a un backend quando gli utenti esterni normalmente passano attraverso il proxy.

Un confronto sul DNS diviso spiega che i client locali possono risolvere lo stesso dominio in un indirizzo interno privato mentre i client esterni continuano a ricevere l'indirizzo pubblico.

Mantenere entrambi i percorsi sullo stesso proxy preserva il routing basato sul nome host, le policy di accesso, gli header e i certificati. Indirizzare i client di casa bypassando il proxy può caricare la pagina ma rompere l'autenticazione, i callback, i WebSocket o i controlli di sicurezza che esistono solo al proxy.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifica Che Ogni Client Necessario Usi Il Resolver Interno

Controlla il server DNS usato da telefoni, laptop, TV, container e client VPN che dovrebbero ricevere la risposta interna. Il DNS sicuro del browser, il Private DNS mobile, un resolver VPN o un server DNS pubblico hard-coded possono bypassare il resolver di casa.

Le linee guida per il self-hosting sul DNS diviso avvertono che spesso si verificano interruzioni quando la VPN o il client continuano a usare il contesto resolver sbagliato nonostante siano sulla rete interna.

Interroga direttamente il server DNS interno, poi confronta quella risposta con la normale ricerca del client. Se il server restituisce l'indirizzo locale ma il client no, correggi la distribuzione DNS DHCP, il DNS criptato, la policy VPN o gli override client prima di modificare nuovamente il record.

Mantieni Lo Stesso Nome Host Per TLS E Callback Dell'Applicazione

Accedi all'app tramite il suo dominio normale dopo che il record interno è attivo. Non sostituirlo con un segnalibro all'IP privato, perché i certificati HTTPS e i percorsi del reverse-proxy sono comunemente legati al nome host.

Il percorso interno deve anche preservare l'URL base pubblico dell'applicazione, l'URI di redirect OAuth, l'indirizzo webhook e gli header inoltrati. Il DNS diviso cambia l'indirizzo di destinazione, non il nome host che il browser o il provider dovrebbero usare.

Se l'app reindirizza all'IP pubblico, genera un nome host interno o rifiuta l'header host, correggi le impostazioni del proxy e dell'URL dell'app. Il DNS da solo non può riparare un servizio configurato con identità incoerenti.

Mantieni Il DNS Diviso Solo Quando Entrambi I Percorsi Rimangono Prevedibili

Testa da Wi-Fi di casa, Wi-Fi ospite, VPN, dati mobili e un dispositivo che usa Private DNS. Conferma che ogni client riceve l'indirizzo previsto e raggiunge la stessa identità applicativa.

La guida ZimaSpace sul perché una private cloud funziona solo su una rete fornisce il sintomo inverso e aiuta a verificare che le due viste DNS rimangano intenzionalmente diverse.

Il DNS diviso è la soluzione giusta quando elimina un loop pubblico rotto preservando lo stesso dominio, certificato TLS, percorso proxy e comportamento dell'applicazione. Usa invece l'hairpin NAT quando il router lo gestisce in modo affidabile e mantenere due viste DNS aggiungerebbe più rischio che valore.