Esamina il DNS dove si verifica la ricerca non riuscita. Il fatto che il portatile risolva un nome non dimostra che Squid, o un proxy padre che effettua la connessione successiva, possa risolverlo.

Leggi il log della cache dell’istanza che presenta il problema e controlla le impostazioni del resolver del server. Una verifica complementare a livello di host è:

getent ahosts target.example

Usa la destinazione reale. getent utilizza il meccanismo di risoluzione dell’host; il resolver interno o la cache di Squid possono essere diversi. Esamina le voci esplicite dns_nameservers e hosts_file prima di supporre che coincidano.

In Squid 6.13, un elenco esplicito di nameserver contiene indirizzi IP:

dns_nameservers 192.0.2.53

Sostituisci questo indirizzo di documentazione con un resolver approvato e raggiungibile dal server Squid. I nomi privati possono richiedere il resolver dell’organizzazione; un resolver pubblico estraneo può non includerli nella propria vista DNS.

Un alias nel file hosts del portatile non accompagna una richiesta per nome host inviata tramite proxy. Sulla macchina che esegue la ricerca, esamina l’impostazione hosts_file della versione di Squid installata e considera, se pertinente, il resolver di un padre. Mantieni il nome host usato per l’identità TLS coerente con il servizio.

Dopo una singola modifica controllata della configurazione, verificane la sintassi e ricarica l’istanza prevista, ripeti la stessa richiesta ed esamina le relative evidenze. Le risposte positive e negative in cache possono influire sulle prove ripetute. Una ricerca riuscita seguita da un timeout di connessione indica un successivo errore di instradamento o autorizzazione; non continuare a modificare il DNS per risolverlo. Mantieni invariati DNS del client, instradamento del padre e protocollo proxy mentre valuti la modifica del server.

Articoli correlati