Il tunnel è attivo, quindi perché il nome privato fallisce ancora?

Tutto nella connessione sembra corretto: il tunnel è attivo e la console mostra l'endpoint privato, ma ogni richiesta fallisce nella risoluzione dei nomi. La mossa naturale è incolpare il tunnel, che di solito risulta innocente. La query viene inviata a un server che non sa nulla della zona privata. Nessun cambiamento di routing modificherà quella risposta, perché il problema è chi è stato interrogato.

Quale resolver ha raggiunto la query?

Trovate il resolver associato a ciascun collegamento prima ancora di guardare il tunnel. Linux espone i server per collegamento tramite il comando di stato del resolver, e macOS mostra i resolver con ambito nel dump della configurazione DNS. Se la risposta arriva ancora dal router di casa, il collegamento del tunnel non è mai stato consultato.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Qui si confondono due fasi: un server che spinge un indirizzo di resolver e un client che lo installa sul collegamento attivo. Un profilo può contenere l'opzione e un log può mostrare che arriva, mentre il sistema operativo continua a usare il vecchio server. Confrontate il log con ciò che riporta il collegamento e fidatevi del collegamento.

Usate un indirizzo a cui la rete cloud risponde davvero

Le reti cloud di solito rispondono ai nomi privati tramite un indirizzo riservato spostato di due dalla base dell'intervallo, quindi una rete che inizia da 10.0.0.0 risponde su 10.0.0.2. Alcuni provider pubblicano anche un resolver locale al collegamento che funziona senza conoscere l'intervallo, il che aiuta quando la rete è stata costruita da qualcun altro. Interrogate direttamente l'indirizzo candidato prima di spingerlo a chiunque. Un indirizzo che non è un resolver sembra esattamente un drop del firewall, perché la query semplicemente non riceve mai risposta.

Se la query diretta risponde dall'interno della rete ma non attraverso il tunnel, il resolver va bene e il percorso tra i due punti no. Quel risultato sposta l'indagine su rotte, inoltro e regole di accesso invece che sul profilo del client.

Un tunnel non trasporta lo spazio dei nomi

I pacchetti passano; i nomi no. A ciascun lato va detto quale spazio dei nomi appartiene all'altro, e questo è un oggetto separato posseduto da chi detiene la zona. La forma abituale è un inoltro per un solo spazio dei nomi, puntato a un resolver raggiungibile attraverso il tunnel.

In pratica ogni direzione ha bisogno della propria regola, perché il lato che possiede la zona deve trasmettere la query. Entrambe le direzioni richiedono che l'origine della query sia instradata e consentita, e il lato che risponde deve restituire le risposte attraverso il tunnel invece che verso internet. Mantenete l'inoltro stretto, così che solo lo spazio dei nomi privato dipenda dal collegamento. Inviare ogni query attraverso di esso trasforma una piccola dipendenza in un'interruzione totale nel momento in cui il tunnel cade.

Percorrete i confini in ordine

Provate il resolver installato sul collegamento attivo, poi una query diretta a quel resolver, poi la stessa query dal lato remoto e infine l'applicazione che usa lo stesso nome. Ogni passo isola un confine, così un guasto dice dove guardare invece di ricominciare l'indagine. Una risposta che funziona mentre l'applicazione fallisce indica la fiducia nel certificato o una policy API invece del DNS. Quei guasti sono reali e nessun cambio di resolver li riparerà.

Annotate quale passo ha fallito. Quella singola riga è ciò che serve alla persona successiva, e registrarla richiede dieci secondi.

Tenete la catena dove la persona successiva può trovarla

Registrate il resolver spinto, la regola di inoltro, l'origine delle query consentita e l'endpoint che risponde in un unico posto. Quando il nome privato fallisce di nuovo, il registro mostra se il tunnel si è spostato, se l'indirizzo del resolver è cambiato o se una regola è stata ristretta. Senza di esso ogni incidente parte da zero e finisce con le stesse tre supposizioni.

Tenete il registro abbastanza breve da restare accurato: quattro righe, una data e il nome di chi possiede ogni parte. Un registro scaduto è peggio di nessuno, perché sembra autorevole mentre è sbagliato.