Come configurare override DNS locali per più proxy inversi

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 Configure Local DNS Overrides for Multiple Reverse Proxies - Zima Store Online

Crea una mappatura locale autorevole per ogni nome di applicazione e indirizzala a un solo indirizzo di reverse proxy per ogni rete client. Non creare override wildcard in conflitto su più server DNS.

Più proxy diventano fonte di confusione quando lo stesso dominio pubblico viene riutilizzato internamente: un laptop può interrogare il router, un container può interrogare un resolver locale e un telefono può usare DNS crittografato. Il risultato può sembrare un problema del proxy o del certificato, anche se il client ha semplicemente ricevuto l'indirizzo errato. Elenca i nomi, i resolver, i listener dei proxy e i certificati prima di aggiungere record.

Assegna i nomi ai confini dei proxy

Elenca ogni FQDN dell'applicazione e il proxy che termina la relativa connessione TLS. Usa record specifici per le eccezioni e riserva un wildcard solo a un dominio il cui intero spazio dei nomi appartiene a un unico proxy.

Evita di assegnare allo stesso nome due record A privati, a meno che entrambi i proxy siano intenzionalmente attivi e configurati in modo identico. Il DNS restituisce indirizzi, non lo stato dei servizi, quindi i record round-robin aggiunti con leggerezza possono indirizzare metà dei client verso un proxy privo della route o del certificato necessari.

Mantieni separati i nomi di gestione da quelli rivolti agli utenti. Se un hostname amministrativo non deve mai essere risolto su una rete guest, inseriscilo in una view o in un resolver disponibile solo per la VLAN affidabile, invece di affidarti al proxy per nasconderlo in seguito.

Inserisci gli override nel resolver effettivamente usato dai client

Crea la zona locale o gli override degli host sul servizio DNS pubblicizzato dal DHCP per quella rete. Indirizza ogni nome dell'applicazione all'indirizzo LAN del proxy che lo gestisce, non al container dell'applicazione e non automaticamente all'indirizzo WAN pubblico.

Client e applicazioni possono usare librerie e cache del resolver diverse, motivo per cui il comportamento del DNS può rimanere nascosto. Verifica il server mostrato nell'output della query invece di presumere che sia stato consultato l'override del router.

Disabilita o considera il DNS crittografato lato client durante il test. Se il client bypassa deliberatamente il DNS locale, gli override split-horizon non possono influenzarlo; scegli invece una policy DNS gestita, un record pubblico con routing hairpin o un resolver fornito dalla VPN.

Allinea le route del proxy, TLS e gli URL dell'applicazione

Su ogni proxy, configura solo gli hostname assegnati a quel proxy e verifica che il certificato copra tali nomi. Una risposta DNS corretta seguita dal certificato errato dimostra che il traffico ha raggiunto un listener, ma non il virtual host previsto.

Testa la route upstream direttamente dal proxy, quindi testa l'hostname pubblico da un client. Se l'accesso diretto all'upstream funziona ma l'hostname restituisce un sito predefinito, correggi la corrispondenza dell'host nel proxy prima di modificare nuovamente il DNS.

Per le applicazioni ospitate sotto un percorso, mantieni allineati la route del proxy e l'URL di base dell'applicazione. La guida di ZimaSpace su come rimuovere in sicurezza l'esposizione di Jellyfin mostra anche perché DNS, route del proxy, forwarding e ACL devono essere tracciati insieme.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Verifica ogni rete e definisci il rollback

Interroga direttamente l'FQDN tramite il resolver locale previsto, quindi interrogarlo attraverso il percorso normale del sistema operativo. Entrambe le risposte dovrebbero puntare allo stesso proxy per quella rete e il TTL dovrebbe corrispondere alla policy locale.

Apri l'applicazione dalla LAN affidabile, dalla VLAN guest o media e dalla VPN, se applicabile. Registra l'indirizzo risolto, il nome del certificato, lo stato HTTP e il reindirizzamento finale; queste osservazioni permettono di stabilire se il problema riguarda il DNS, TLS, il routing del proxy o l'applicazione.

Rimuovi i record duplicati obsoleti solo dopo che tutti i client hanno superato i test. Esegui il rollback dell'override più recente se client diversi alternano tra i proxy e interrompi l'espansione del wildcard finché i log del resolver non dimostrano quale server ha risposto a ogni richiesta non riuscita.