Nome DNS privato o solo un IP? Decidete prima di condividerlo

Due domande si confondono quando un servizio privato viene aperto a utenti remoti. La prima è quale nome i client devono usare; la seconda è quali fonti il servizio deve ammettere. Rispondete in quest'ordine, perché un nome corretto dietro una regola di accesso sbagliata fallisce comunque, e una regola corretta dietro un nome che non si risolve non viene mai testata.

Prima condizione: quale percorso del resolver hanno i client?

Un nome privato funziona solo se il resolver del client può rispondere. Ciò significa che un client remoto autorizzato deve raggiungere un server DNS che detiene la zona, tramite il tunnel o tramite un resolver che l'organizzazione già gestisce per gli utenti remoti. Il tunnel è un trasporto, non una directory. Dà al client un percorso verso un resolver, e non gli dice quale zona interrogare.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Un resolver pubblico non imparerà una zona privata perché il portatile si è connesso a una VPN.

Il suffisso merita la stessa attenzione. Usate un sottodominio di un dominio controllato dall'organizzazione, così che proprietà e pianificazione dei certificati restino esplicite. Evitate .local: la specifica multicast DNS lega quel suffisso alla risoluzione link-local, e un tunnel instradato non riproduce quel comportamento per voi.

Seconda condizione: quale fonte riceve il servizio?

Le regole di ammissione si scrivono rispetto agli indirizzi, quindi la domanda utile è quale indirizzo il servizio vede dopo l'instradamento e la traduzione. Per un servizio di esempio su 10.20.30.40, i client dell'ufficio arrivano da 10.20.30.0/24 e i client remoti da un pool separato come 10.99.0.0/24.

Se un gateway traduce il pool remoto, il servizio vede il traduttore, e una regola scritta per 10.99.0.0/24 non corrisponderà.

Leggete questo dal lato del servizio invece che dal lato del client. Un log di ascolto o una cattura di pacchetti sull'host del servizio mostra la fonte effettivamente arrivata; l'indirizzo del client stesso è solo una supposizione su ciò che è sopravvissuto al percorso.

Terza condizione: il nome è legato a un servizio o a un host?

Un nome che punta all'indirizzo di una macchina lega ogni client a quella macchina. Un nome che punta a un bilanciatore di carico o a un indirizzo di servizio stabile sopravvive alla sostituzione dell'host dietro di esso. Scegliete deliberatamente, perché cambiarlo più tardi significa cambiare i segnalibri di ogni client e il soggetto di ogni certificato.

Per un singolo servizio interno, un record diretto di solito va bene ed è più semplice da ragionare.

Per qualsiasi cosa che sarà sostituita, ricostruita o scalata, un front end stabile vale la configurazione extra. Il test è semplice: se potete sostituire il backend senza avvisare gli utenti, il nome è legato al servizio; se non potete, è legato a un host.

Testate le due decisioni separatamente

Risolvete prima, poi connettete. Un test di risoluzione che restituisce l'indirizzo atteso dimostra il percorso del nome e non dice nulla sull'ammissione. Un test di connessione dimostra percorso e regola insieme, quindi eseguitelo solo dopo che la risoluzione è riuscita.

curl -sv --max-time 5 https://files.corp.example/health

Poi testate una fonte vietata una volta, e registrate il risultato.

Mantenete i due record separati nella vostra documentazione: il nome e la sua zona, le fonti ammesse e il proprietario della regola. Quando uno cambia, l'altro non deve.

Dove la decisione di solito va storta

Il guasto comune è un servizio pubblicato sotto un nome che si risolve solo sulla rete dell'ufficio, con una regola di ammissione che ammette solo l'intervallo dell'ufficio. Gli utenti remoti segnalano allora un servizio rotto che in realtà è due omissioni separate. Il secondo guasto comune è l'inverso: una regola di ammissione ampia aggiunta per far sparire un problema di nome lascia il servizio raggiungibile da fonti che nessuno intendeva. Entrambe sono omissioni di configurazione, e dalla sedia dell'utente sembrano uguali.

Nessuno dei due errori è visibile da un solo test riuscito. Per questo le due decisioni meritano record separati e test separati, anche quando la stessa persona prende entrambe.

Scrivete entrambe prima che il servizio vada in produzione, perché il prossimo cambiamento sarà più facile da ragionare. Il record è breve: una riga per il nome e la sua zona, una riga per le fonti ammesse e il proprietario della regola.